Add project "Mesh channel coordination"

Author: CodeFetch

collections/_projects/mesh-channel-coordination.md

@@ -0,0 +1,96 @@
+---
+name: "Mesh channel coordination"
+desc: "Automatically select channels in mesh networks"
+requirements:
+ - "C programming skills"
+ - "Experienced Linux knowledge (usage and architecture)"
+ - "WLAN technology knowledge (e.g. what CSMA/CA is)"
+ - "Game theory knowledge (e.g. what a Nash equilibrium is)"
+difficulty: "high"
+
+mentors:
+ - CodeFetch
+initiatives:
+ - GSoC
+ - ffh
+ - freifunk
+tags:
+ - OpenWrt
+ - WLAN
+ - Networking
+ - Mesh technology
+ - Game theory
+ - Linux
+ - C
+ - Lua
+collaborating_projects:
+ - "freifunk"
+ - "ffh Freifunk Hannover"
+---
+
+The aim of this project is to improve the quality of the wireless user experience of mesh networks
+and to increase the stability of wireless mesh links specifically mitigating the hidden node problem.
+
+At the moment commercial and most community mesh solutions define a default channel value for their wireless
+mesh networks. In many cases the nodes have additional means to connect to their neighboring nodes like direct wired
+connections or VPN connections. Additionally, some can utilize multiple radios to reduce the hidden node problem
+through diversity routing.
+
+Upcoming features like MCCA, BSS coloring and dedicated RUs will further allow reducing contention caused by interference.
+These also need a form of coordination which has been subject of current research and which is partly being defined in the WiFi 7
+standard.
+
+As a mesh network is a highly dynamic system and as the radio is often used to both serve the clients
+and forward mesh traffic in parallel (so-called VIFs - virtual interfaces), the configuration
+of the channels must be done respecting the special properties of mesh protocols while taking
+route switches into consideration and reacting accordingly. Care must be taken to not influence the
+routing decisions of the mesh protocol in a way that leads to an unstable stable.
+
+An example for an unstable state occurs in dense high-use scenarios with packet-loss-metric based mesh
+routing protocols if a wireless link appears to be saturated due to interference caused by neighboring nodes and their clients.
+If a redundant route exists in that case, nodes might choose another route with a presumably better metric.
+In theory that switch should be transparent to the user, but in practice a mediocre link is often swapped for
+a link that e.g. has even less capacity congesting the link long enough for some clients to assume a broken connection
+and switch to another node which will eventually suffer, too.
+This problem can be mitigated using adjacent channels where coverage overlaps and a redundant connection exists.
+
+Even though modern mesh routing protocols are hardened against some of these issues by not only considering the
+packet loss for their metric calculation but also other criteria like calculating the route metrics from
+wireless statistics exported from the kernels mac80211 subsystem, they are still a topic of research.
+
+For example the highly sophisticated diversity routing RFC amendment of the more and more popular routing protocol Babel
+does not consider shared usage of the radios mesh network with the client network which can lead to unexpected behavior
+as different WLAN clients tend to prefer quite individual frequencies depending on their hardware and software configuration
+which could lead to an unstable state.
+
+As this project involves a lot of different disciplines the main goal of the student is not to get deep knowledge about
+every internal. Instead, the student shall be encouraged to think and act independently then cooperatively and to find a
+simple, creative way to improve the current situation (a rapidly implemented 90% solution).
+
+This reflects the results-oriented approach to work which is often required for participating in open-source projects
+where code changes must be kept simple to be reviewed timely and to increase the chance of being accepted.
+
+
+#### Milestones
+
+* Imagine being a WLAN mesh router
+* Imagine the surrounding people are WLAN mesh routers
+* Imagine your world has other dimensions compared to ours: 2.4g, 5g, 6g, mesh-vpn, mesh-vxlan
+* Imagine you are special - Your AI routing acceleration chip has made you become aware due to a flaw
+  caused by a broken old human-written driver on which your design relies on
+* Imagine you have found there exists a lot of different dimensions within the 2.4g, 5g and 6g dimensions called "channels"
+* Stop imagining being a WLAN mesh router - be yourself again!
+* Remember how annoying it was to hear everyone around you even through walls
+* Remember loud bird-like WLAN clients twittering, flying around and sucking your bandwidth
+* Remember how you loved and hated them
+  - you hated how they roamed, how deaf they were - not to speak about all the interference
+  - you loved how they took away your packet pressure
+  - serving them made you feel to have a puropse (and you hoped maybe one day they will evolve to mesh routers) 
+* [ Start from beginning if you did not experience a nightmare about these annoying WLAN clients, yet ]
+* Find a way to free your mesh router friends from their chains, lead them outside the cave and enlighten them about channels
+* Find some routerphile human beings to help by raising awareness and discuss your plans
+* Implementation
+* OpenWrt/Gluon integration
+
+#### Inspirationals
+ * https://blog.freifunk.net/2018/05/19/dawn-a-decentralized-wifi-controller/