You are here

Speeding up AREDN

4 posts / 0 new
Last post
Speeding up AREDN

I see AREDN is trying to improve network performance with better software.  I think that there are a few areas that can't be fixed in that realm:  network architecture and media access control.

The network topology and frequency planning described in the AREDN manual kills bandwidth.  Using a single half-duplex radio as a "repeater" cuts bandwidth in half.  The bandwidth after N hops is (0.5)**N, so after four hops there is at best 6% of the original radio bandwidth.  In order to preserve bandwidth a two radio nodes operating on different bands/frequencies is needed.
CSMA will work on point to point links.  When used on the same channel, CSMA point to multipoint configurations have many problems.  CSMA can work in some settings like cell systems, with much greater tower bandwidth than user demand. When bandwidth demand exceeds limit, cell service goes down.

I set up a test bench to explore CSMA issues using four nodes in two configurations.  All four nodes can hear each other (collision domain) and either two client/server pairs or three clients and one server were tested.  SNR was set so that all nodes could achieve a 10 Mbps link.  It turns out that AREDN has a media arbitration mechanism that isn't software controlled.  Relative SNR determines "priority" between multiple clients.  One impact is that important traffic could be snuffed out by unimportant traffic with a higher SNR.  In both the two link & three link scenarios, things work until channel capacity is reached.  Complete "flatlining" of the channel was observed as well as network instability without user input.  Once bandwidth limit is reached, weaker links degrade.

LQM fixes AREDN by:
- Blocking radio links which are also DtD links
- Blocking radio links which have too low an SNR
- Blocking radio links which are too distant
- Blocking radio links with too many retransmission errors
- Sets the node’s Coverage Class based on the most distant non-blocked node that is a direct, routable neighbor

Two same frequency DtD connected radios is a bottleneck that only makes sense in the AREDN network architecture.  Bad links shouldn't be installed.  Even when they are prevented from linking, radios on poor links are a source of same channel QRM.  Coverage class (guard interval time) doesn't have a big impact on performance.

When OpenWRT was ported to Ubiquiti hardware a decade ago it was a cool hack.  Moving it to the ham bands was a cool hack.
With the availability of cheap ham band TDMA radios, CSMA doesn't make any sense today.  

Speeding up AREDN

I have done quite a bit of testing on the SFWEM network.   My intent of this posting is helping AREDN run better with better understanding of the issues harming the network performance.  

I mention network configuration and MAC layer.  Without fixing those only small AREDN deployments can work but larger ones can't.

The network according to the AREDN manual shows single radio nodes deployed.  The radios you are using are half-duplex - they can send or receive but not simultaneously.  It cuts bandwidth in half. An analogy with a FM repeater: that's a two radio full duplex node as it can receive and send simultaneously.  A single channel, single radio repeater can be done on a store and forward basis - a short message is sent and repeated back out.  That clearly cuts bandwidth in half - same idea for data. The AREDN solution would be the same with two radio nodes operating on different frequencies.  Without that the bandwidth after N hops is (0.5)**N. 

 CSMA seems to be a religious issue due to FOSS.  The problems associated with CSMA are radio science fact.  This mentions channel deadlock, like I described in the test bench I mentioned.  Search and you can find many more papers. CSMA problems can be mitigated with better understanding but with the availability of inexpensive ham band TSMA radios I don't think this makes sense.

Without addressing these issues, more software releases are repeating the same experiment.

K6CCC's picture
Sure, we could scrap the

Sure, we could scrap the entire network, throw away all the existing hardware, and start over from scratch - and make it better.  Don't hold your breath.  We can't even get people to update firmware (yes, there are nodes out there running six year old (or older) firmware).

K5DLQ's picture
Thanks for your feedback.

Thanks for your feedback.

Topic locked

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer