Hi,
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?
Thanks,
Morgan R.
Sorry for the brevity, traveling abroad and only have my phone. I am
the author of the MAC code in cgran and have a paper on the work, give
it a read: Enabling MAC Protocol implementations on software-defined
radios. It gives you an idea of what all we did to gnu radio to build
Macs and what the speedups were. Basically, it becomes a fundamental
limitation of the phy and Mac, rather than loss due to the high
latencies.
On Thu, Jun 30, 2011 at 9:16 PM, Morgan R.
[email protected]wrote:
I was wondering if anyone else had had any luck building a CSMA/CA
Morgan,
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.
Tom
On Sun, Jul 3, 2011 at 8:16 AM, Tom R. [email protected]
wrote:
more collisions than I would expect.
Thanks,
of the air interface, you decision is so far in the past that it’s pretty
[email protected]
Discuss-gnuradio Info Page
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! $$). 
–Colby
On 07/01/2011 03:16 AM, Morgan R. wrote:
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?
Thanks,
Morgan R.
Hi Morgan,
we are also working on a CSMA/CA MAC here using a SDR software called
Iris (I know that’s the GNU radio list but problems are pretty much the
same in terms of timing). The implementation is still not perfect but we
got some nice results already.
May I ask you about the throughput of your system? I would really like
to compare them with our setup.
There is also another paper titled “An IEEE 802.11 MAC Software Defined
Radio Implementation for Experimental Wireless Communications and
Networking Research” which might be of interest for you.
Regards,
Andre
–
Andr Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: [email protected], Web: Group for Integrated Communication Systems | Technische Universität Ilmenau
Office: Zuse Building, room 1071
On 07/06/2011 07:33 PM, Morgan R. wrote:
I’m still working on my MAC, and there’s a lot of room for
improvement. At the moment, I get throughput of about 1kbps. What kind
of throughput are you getting?
In a setup of two nodes we have a end-to-end throughput (measured using
iperf using TCP as transport protocol) of around 150-200 kbps. But that
certainly depends on physical layer parameters as well. At the moment we
use a sampling rate of 1Mbps and Bpsk modulation.
Parameters still need to be fine-tuned (SIFS, DIFS, etc.), so there is
definitely room for improvements. What PHY are you using?
Regards,
Andre
about people who were working on it, but I don’t see any example code
Networking Research" which might be of interest for you.
Email: [email protected], Web: Group for Integrated Communication Systems | Technische Universität Ilmenau
Office: Zuse Building, room 1071
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
Andr Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: [email protected], Web: Group for Integrated Communication Systems | Technische Universität Ilmenau
Office: Zuse Building, room 1071
On 07/06/2011 07:33 PM, Morgan R. wrote:
I’m still working on my MAC, and there’s a lot of room for
improvement. At the moment, I get throughput of about 1kbps. What kind
of throughput are you getting?
In a setup of two nodes we have a end-to-end throughput (measured using
iperf using TCP as transport protocol) of around 150-200 kbps. But that
certainly depends on physical layer parameters as well. At the moment we
use a sampling rate of 1Mbps and Bpsk modulation.
Parameters still need to be fine-tuned (SIFS, DIFS, etc.), so there is
definitely room for improvements. What PHY are you using?
Regards,
Andre
about people who were working on it, but I don’t see any example code
Networking Research" which might be of interest for you.
Email: [email protected], Web: Group for Integrated Communication Systems | Technische Universität Ilmenau
Office: Zuse Building, room 1071
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
Andr Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: [email protected], Web: Group for Integrated Communication Systems | Technische Universität Ilmenau
Office: Zuse Building, room 1071
On 07/06/2011 07:33 PM, Morgan R. wrote:
I’m still working on my MAC, and there’s a lot of room for
improvement. At the moment, I get throughput of about 1kbps. What kind
of throughput are you getting?
In a setup of two nodes we have a end-to-end throughput (measured using
iperf using TCP as transport protocol) of around 150-200 kbps. But that
certainly depends on physical layer parameters as well. At the moment we
use a sampling rate of 1Mbps and Bpsk modulation.
Parameters still need to be fine-tuned (SIFS, DIFS, etc.), so there is
definitely room for improvements. What PHY are you using?
Regards,
Andre
about people who were working on it, but I don’t see any example code
Networking Research" which might be of interest for you.
Email: [email protected], Web: Group for Integrated Communication Systems | Technische Universität Ilmenau
Office: Zuse Building, room 1071
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
Andr Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: [email protected], Web: Group for Integrated Communication Systems | Technische Universität Ilmenau
Office: Zuse Building, room 1071
I’m still working on my MAC, and there’s a lot of room for
improvement. At the moment, I get throughput of about 1kbps. What kind
of throughput are you getting?
Andre and George, thanks for pointing me to those papers. I’ll look
through them and see if I can figure out any ways to improve my MAC.
Morgan
On Tue, Jul 5, 2011 at 4:30 AM, Andre P.