Mobile Vehicle Mesh Network

Mobile Vehicle Mesh Network

[Scooter Willis]

Doing some research to see what options are available for a hybrid
mobile-mesh network.

The application would be a large warehouse with fixed nodes overhead
connected via ethernet/POE.

On the warehouse floor would be some number of robots that as they
travel would go in and out of range for an overhead access point. On
the robot would be 2-5 computer devices that would connect to the
access point on the robot via ethernet.

Would have one gateway for the entire warehouse in that all internet
traffic would be local.

If the robot which is moving has the equivalent access point mesh node
as the static access points overhead would want very quick handoff to
the next access point where signal strength of the wifi would be the
reason to pick a specific access point. The 2-5 computers on the robot
should see the minimal impact when the access point switches to
another overhead access point. For the 2-5 computers on the device
want to minimize cost/wifi noise and the reason to have them plugged
into a local switch.

For batman-adv wanted to see if you could provide any guidance that it
would work in this configuration where some number of mesh nodes are
dynamic and are moving. It may also be optimal for a robot not in
range of overhead wireless to connect to other moving robots that are
mesh nodes.

Re: Mobile Vehicle Mesh Network

[haas]

Hi,

Something like Maxwell openwrt batman nodes would work well... 
https://www.crowdsupply.com/andy-haas/maxwell
They would be fixed in location. No mesh does great when the nodes are moving around rapidly. The response / reconfiguration time is on the order of a minute or so, not fast. 
The robots would reach have an access point that gets internet from the static mesh wifi and provides local wifi and ethernet to the robot clients. 

If the robot access point could not connect to a static mesh node, it could connect to another robot's wifi, but that sounds complicated.

Re: Mobile Vehicle Mesh Network

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 6281 bytes --]

On Friday, 29 January 2021 02:43:25 CET Scooter Willis wrote:
> Doing some research to see what options are available for a hybrid
> mobile-mesh network.

Let me summarize your mail (because I had some problems with your writing 
style):

* multiple ceiling mounted "AP"s

  - connected to the same network
  - "relevant services" are behind the AP

* multiple mobile clients on the floor

  - roam from AP to AP
  - client must be forwarding traffic from local devices (connected via 
    ethernet)
  - it is unknown what mobility can cause in quality changes

    + usually the speed and therefore the gradual change in link quality is 
      bound to a specific rate in an "open" environment"
    + but unknown whether it is also possible that a link suddenly disappears/
      degrades due to environment factors - which is somewhat likely in a 
      warehouse scenario

  - might be out of reach of an ceiling AP

    + mesh technology should be used ensure connectivity to the relevant 
      services


In your original mail, you left out some information which might be relevant 
for the discussion. So  we have to go through some of them:


1. what technology is used for the AP to client connections?
============================================================

My first assumption would be standard wifi infrastructure mode. The APs allow 
multiple client to connect and a client is only connected to one AP. It is 
(from AP perspective) a star topology with the AP in the center and the client 
as layer 2 endpoints. 

But keep in mind that this mode is not meant to have multiple layer 2 devices 
behind a single associated station. Or in other words: you cannot bridge your 
ethernet interface with the wifi managed interface on your mobile clients.

So you have some options to still get the multiple client devices connected to 
the relevant services.

* enable 4 address mode on both AP and client. And then pray that both are 
  handling it in a compatible way. But usually works fine when both are 
  running the same software stack (like OpenWrt with a similar set of drivers/
  wifi firmware).
* use a higher layer routing (like IP routing). But could be problematic when 
  you need a layer 2 connectivity. Or can get more complex if you don't use a 
  central place to terminate the layer 3 routes towards the network with the 
  relevant services
* use also a layer 2(.5) mesh technology over the links between clients and AP

Another option would be to drop the standard wifi infrastructure mode setup 
and just use the same technology between the ceiling nodes and the mobile 
clients as you would use between the mobile clients. Of course, then you would 
most likely need to be in "full" control of the APs and not only the clients. 
And depending on the mesh technology, it can work a lot better or only create 
more problems due to more links with dynamic quality characteristics.

In batman-adv's case, you would have for example following differences:

* ceiling node to mobile node link is NOT part of the mesh

  - exchange of client information happens with TT [1] and roaming
    features [2] - usually really fast
  - allows APs to be bridged when the bridge loop avoidance is enabled [3]
  - but quality information for the ceiling node to mobile node are completely 
    missing

    + so it is unknown the mobile node whether it is better to send it data 
      first to a mobile neighbor or directly to the crappy link towards the AP

* ceiling node to mobile node link IS part of the mesh

  - the quality of the link between ceiling node and mobile link is measured 
    like the other wifi links
  - hopefully better routing decisions
  - usually slower route switching time when comparing to the TT "roaming" 
    times



2. how important is the "wifi noise" factor?
============================================

Mesh technologies need to detect neighbors and somehow find routes between 
nodes. This doesn't come for free - usually in form of additional data over 
wifi, cpu and memory usage. But the details depend on the used technology.

batman-adv is using OGMs to inform neighbors of their existence and let 
receivers make informed decisions about their next hop towards a specific node 
in the mesh. These OGMs have to be sent often to allow the nodes to converge 
towards "good" routing decisions.

This means that a lower originator interval (aka more OGM transmissions) can 
be improve the convergence speed which is beneficial for mobile setups. This 
should acceptable well for networks which don't have sudden loss of nodes. For 
mesh networks were "intermediate hop" nodes suddenly disappear, it might still 
need a significant time until the old route via this disappeared hop is 
dropped. There were some ideas [4] how to improve this situation but they were 
never implemented.


3. how about new/experimental mesh technologies?
================================================

This is the B.A.T.M.A.N. mailing list and the mail explicitly asked about 
batman-adv, but I could imagine that you could have fun playing around with 
various technologies in a scenario with mobile node and drastic changing link 
characteristics. While there is no magic bullet - marketing might disagree -
at least interesting things might be out there.

There are (more or less) recent research in technologies which are more focused on highly mobile setups. You'll find these kind of mesh
technologies usually with features like

* multi-path routing
* redundancy
* forward error correction
* ...

to achieve resilience to mobility. Often by taking advantage of the
broadcast medium and dropping the standard paradigms of the 802.11
medium access - which is a different concept than what batman-adv
tries to do.

(small disclaimer: At least one batman-adv [5] is doing research in related 
technology and I could be considered slightly biased because of it).

Kind regards,
	Sven

[1] https://www.open-mesh.org/projects/batman-adv/wiki/Client-announcement
[2] https://www.open-mesh.org/projects/batman-adv/wiki/Client-roaming
[3] https://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance-II
[4] https://www.open-mesh.org/projects/batman-adv/wiki/RIP
[5] https://git.open-mesh.org/batman-adv.git/blob/HEAD:/MAINTAINERS

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]