I've noticed in conversations about AREDN that people feel OLSR is getting a little long in the tooth and that a switch to something more modern would be a good idea. Obviously this is a difficult technical and human challenge as no one wants to relearn everything and no one wants to destroy what's been built so far. Given this, here's my proposal on how this could be done without disrupting what currently exists. Would really appreciate feedback.
https://docs.google.com/document/d/1X3PJ822G84wNuCtw_fhv8CoC1V_pUou-44QUkXWGbDI/edit?usp=sharing
You are here
Transitioning AREDN to a more modern mesh technology
Tue, 10/05/2021 - 13:24
#1
KN6PLV
Transitioning AREDN to a more modern mesh technology
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Orv W6BI
It is important to have the interoperability phases for AREDN in general, and I am happy to see your plan and tryout whatever it produces.
However, for users within "islands" of connectivity, where we can control the firmware on all devices in the local mesh, it would be nice to jump straight to Phase 2: BATMAN only and work on optimizing isolated BATMAN only meshes, and discovering what new applications are enabled by BATMAN.
Simultaneously, users that must exist within legacy OLSR meshes can work on interoperability.
While interoperability baby steps are being taken, it isn't terribly important to know the exact end goal, provided you know the general direction. As interoperability approaches maturity, the fine details of the next phase matter greatly. It would be nice if those details are already known by that time.
Working both ends toward the middle completely avoids an intermediate evolutionary stage, replacing it with a reconciliation stage. Trading a process full of unknowns for knowns. Also it lessens the chance that new applications are hamstrung by legacy vestiges. We can take advantage of the current sparse nature of AREDN networks in rural areas rather than bemoan it.
The obvious disadvantage is that it requires double the development effort immediately. Developers in existing built up areas will need to be focused on interoperability while isolated developers would be charged with advancing the state of the art. Are there enough devs for the project to survive the split?
One thing I would like to see for the BATMAM only network (ironically) is interoperability with non-AREDN nodes. For example I have an AREDN GL-AR300M16-ext in a mobile setup which I will use on negative channels when searching for new nodes. When I get within my home geofence, it should automatically change to channel 11, remove encryption restrictions, and mesh with my non-AREDN GL-AR300M with stock firmware and BATMAN package to extend my home WiFi out into the yard around the driveway. That would allow sharing storage on my mobile rig with the home network without requiring additional radios. I could upload to the vehicle a new batch of songs, the following day's itinerary, or any number of things that should only be transferred over a non ham, trusted network.
Edit: How to schedule a recurring contact? "Same Bat time, same Bat channel."
Anything you can do to find volunteer programmers with the right skills will be greatly appreciated.
Anything on AREDN's Supported Devices Matrix that's not flagged as not for new deployments would be fine for testing. The first two 802.11ac devices being targeted for support by AREDN are the Nanobeam 5ac Gen2 and the Nanostation 5ac, if you're in a buying mood. Beyond that, don't know.
Orv W6BI