I'm in a team and we are supposed to be setting up a 'geolocation-based', ipv6, wifi mesh network to run on google android.
The idea is to use the geolocation (latitude, longitude, altitude) of each node to generate the IPv6 address, then use that to choose the closest node as the preferred node for routing through. Some optimisation is made through periodic 'routing load' messages.
http://www.v6pc.jp/apc/en/data/addressing.pdf
My understanding is: The main 'benefit' of doing a geolocation-based algorithm is that each network hop will step physically closer to the destination... and we assume that travelling in the most direct path to the destination, is going to give us the most optimal routing path.
BUT, my problem with this approach is that physical proximity + load does not necessarily imply good connection strength or fast routing. What if there's a thick lead wall(?) or lots of interference?
Surely proximity is a fairly useless metric for determining routes?
The primary metrics should be primarily based on performance/load, shouldn't they? Something like signal strength, demonstrated throughput, CPU usage, time connected to the network, etc. At least that was my understanding of how routing paths should be chosen.
Why is this a good idea? Is there something I'm missing?
I haven't spent a lot of time working with networks, so please put in noobman's terms.
The three main paramaters for any connection are bandwidth, latency and capacity. Bandwidth would be measured in bytes per second, latency in milliseconds, and capacity in % of bandwidth used. Those are all parameters you can determine for connections to neighboring nodes (Before you join the mesh, capacity used will likely be 0%)
You need capacity because you want to avoid congested nodes even if they would have good bandwidth and latency.