You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reduce wasted bandwidth by ensuring that packets propagate in the right direction
I had a look at the routing protocol, and I was wondering if it could be made less bandwidth hungry by taking advantage of the physical topology of the mesh.
My idea would be for nodes to only rebroadcast packets if the signal goes "in the right direction". To do this, I am proposing a protocol optimization where a sender could specify the location of their intended receiver, and also include their own location. Upon receiving such a packet, nodes could infer if they are between the sender and the receiver, and avoid rebroadcasting a packet if they do not find themselves in a position to help. If they are "on the path" (e.g. they can see somebody closer to the destination) they would rebroadcast the packet and update the sender location of the packet.
To ensure backwards compatibility, in the absence of a specified destination location, the regular flooding algorithm would keep being executed.
Provided that nodes start caching the locations of other nodes, this could lead to improvements in bandwidth utilization since we would avoid broadcasting packets in parts of the mesh that are further and further from the destination.
Most LoRa devices include a GPS or can statically obtain a GPS location from their owner, so I believe this improvement is very feasible
Privacy concerns
I am anticipating that some people will find this improvement privacy invading, therefore I think that such an optimization could be an option that the owner can decide to enable or not. I should however be noted that:
It is already very easy for the authority to triangulate the location of a meshtastic device, so I do not think it makes anyone more stealthy to disable sharing their GPS coordinates
A lot of meshtastic device owner already happily put their devices on public maps, so I don't think the community would oppose the change.
The text was updated successfully, but these errors were encountered:
Using location-based routing decisions would only work on the premise of having:
Accurate and up-to-date positions, which is not guaranteed even from nodes with GPS.
Assumes no present line-of-sight obstructions in range to the target node.
These two conditions are frequently not satisfied, so this would be a very problematic implementation in terms of reliable packet delivery. We have an alternative routing protocol being developed for the next major version of Meshtastic that seems promising: #2856
Platform
NRF52, ESP32
Description
Reduce wasted bandwidth by ensuring that packets propagate in the right direction
I had a look at the routing protocol, and I was wondering if it could be made less bandwidth hungry by taking advantage of the physical topology of the mesh.
My idea would be for nodes to only rebroadcast packets if the signal goes "in the right direction". To do this, I am proposing a protocol optimization where a sender could specify the location of their intended receiver, and also include their own location. Upon receiving such a packet, nodes could infer if they are between the sender and the receiver, and avoid rebroadcasting a packet if they do not find themselves in a position to help. If they are "on the path" (e.g. they can see somebody closer to the destination) they would rebroadcast the packet and update the sender location of the packet.
To ensure backwards compatibility, in the absence of a specified destination location, the regular flooding algorithm would keep being executed.
Provided that nodes start caching the locations of other nodes, this could lead to improvements in bandwidth utilization since we would avoid broadcasting packets in parts of the mesh that are further and further from the destination.
Note that this idea is not new, since wikipedia mentions it as a possible improvement in the section "Selective flooding" https://en.wikipedia.org/wiki/Flooding_(computer_networking)
Feasibility
Most LoRa devices include a GPS or can statically obtain a GPS location from their owner, so I believe this improvement is very feasible
Privacy concerns
I am anticipating that some people will find this improvement privacy invading, therefore I think that such an optimization could be an option that the owner can decide to enable or not. I should however be noted that:
The text was updated successfully, but these errors were encountered: