Gluon: Auto-Channel Selection

[lemoer]

Gluon Auto-Channel Selection

The scope of this is, to automatically distribute nodes across wifi channels. The aim is to automatically enhance performance in installations where all nodes are normally connected via wired mesh. E.g. a large house where there "Hausverkabelung" is used to connect all routers via wired mesh.

Switching channels is not trivial, as it interferes with the capability to mesh with other nodes. While it would be possible to turn off wifi meshing completely in this scenario, it is nice to have a fallback to wifi meshing. As of now, even if wired mesh is turned off for all nodes, the channel planning has to be done manually. So if we device that the fallback is not necessary, it would still be nice to have auto channel selection.

Algorithm Idea

• A node has two modes:
  1. Wifi-Mesh-Mode
  2. Low-Interference-Mode
• Mode Definition:
  • In Wifi-Mesh-Mode:
    • The node always uses wifi channel 1 in this mode.
    • Wifi-Meshing is activated.
  • In Low-Interference-Mode:
    • The node uses a best-fit channel in this mode.
    • Wifi-Meshing is deactivated.
• Mode Transition:
  • In Low-Interference-Mode:
    • If a node observes any other node in its wifi scan (see below), to which it does not have a link via it's wired mesh* capabilities:
      • Switch to Wifi-Mesh-Mode.
    • Otherwise:
      • Stay in Low-Interference-Mode.
  • In Wifi-Mesh-Mode:
    • If all nodes in the mesh are still reachable via wired mesh*, when Wifi-Meshing is turned off:
      • Switch to Low-Interference-Mode.
    • Otherwise:
      • Stay in Low-Interference-Mode.
• Wifi Scanning for Potential Neighbours (in Low-Interference-Mode):
  • As potential neighbors might currently be in the Low-Interference-Mode, we can not scan for their mesh announcement.
  • Therefore we need to scan (on all channels) for their client wifi.
  • From the found client wifi ssids/bssids/essids, we need to figure out from the batman tables, whether we already have a wired link to them.
    • TODO: is this possible? (Check if we can find the mac address of the scan in batctl tg, if so good. If not, see what we can do here.)

* "wired mesh" includes mesh via vpn.

Theoretical Problems (?)

• What if the wired mesh is really bad, while the wifi mesh is good?
  • 🠒 Is this really an issue? I don't think so?
  • If we still think this is an issue, we could define, that wired mesh links with a TQ < X are not considered as connections. X could be very high, I guess. Because wired mesh should always have very low packet loss. But there is also the artificial hop penalty. So let's see.
• Do mixed paths make problems?
  • Links like: wired <-> wifi <-> wired <-> wifi <-> wified ?
  • 🠒 I don't think this is an issue. Every node should be able to make his decisions individually. I think this should converge to a reasonable global state.

Open Questions

• Can we figure out whether we know a node just by scanning for its client wifi? (see above)
  • Yes. All mac addresses are only differing in the last 3 bits. See here.. The bssid has the last bits as 3 or 7. The corresponding node can be found in the batctl o table by nulling the last 3 bits.
• Does a node lose its clients when, when the node performs a channel switch?
• We need to find a decentralized algorithm to find a best-fit channel with least interference. Is there something?
• TODO: Can we use DAWN? Can we maybe extend it? Can we profit from its infrastructure?
• What happens if a node observes another node from another domain?
• How do we handle nodes with multiple radios?

Steps/Work Packages

1. Think about open the questions/experiment.
2. Implement a respondd provider, which announces seen neighboring freifunk client ssids.
3. Implement the channel selection algorithm.
4. Evaluate the results.

[CodeFetch]

Something like that was the plan if the student would not be able to distribute the mesh channels properly. It's possible to make these approaches compatible, but let's better talk in Mumble.

[lemoer]

To dig deeper into the whole problem:

For a Graph based approach to the full problem, see: https://link.springer.com/chapter/10.1007/978-3-540-89183-3_7

Some information about the paper:

• It handles multiple channels/frequencies.
• There is a central coordinator role.
  • It must know the routes and the average amount of data per flow.
• The paper contains a section about "Classification of Channel Assignment Schemes". This is interesting to get an overview.
• Mathematical Model. They rely on two graphs:
  • They use a connectivity graph (who sees whom)
  • They also use a conflict graph (which edges from the connectivity graph interfere which whose edges - edges of one graph are the nodes of the other graph).
• The paper references other algorithms: "CCA" and "CLICA"

[lemoer]

A command to find other AP STAs with hannover.freifunk.net:

iw client0 scan | awk '/^BSS/ { sub(/\(on/, "", $2); BSS=$2 } /hannover.freifunk.net/ { print BSS }'

[lemoer]

With signal strength:
iw client0 scan | awk '/^BSS/ { sub(/\(on/, "", $2); BSS=$2 } /hannover.freifunk.net/ { print BSS " " SIGNAL } /signal/ { SIGNAL=$2 }'

(be aware this counts on the fact that "signal: " is before "SSID" in the output of iw)

[lemoer]

Sometimes the output doesn't seem to be so stable here...

[lemoer]

Haven't checked this, but this might be related: https://chaos.expert/genofire/wifictld