diff --git a/docs/about/overview/mesh-alg.mdx b/docs/about/overview/mesh-alg.mdx index d4de8c35..c9bb1e02 100644 --- a/docs/about/overview/mesh-alg.mdx +++ b/docs/about/overview/mesh-alg.mdx @@ -4,14 +4,14 @@ title: Mesh Broadcast Algorithm slug: /overview/mesh-algo sidebar_label: Mesh Algorithm sidebar_position: 2 -description: "Discover the Meshtastic Mesh Broadcast Algorithm: a simple, yet effective routing protocol designed for off-grid communication using LoRa technology." +description: "Discover the Meshtastic Mesh Broadcast Algorithm: an effective routing protocol designed for off-grid communication using LoRa technology." --- import ReactPlayer from "react-player"; ## Current Algorithm -The routing protocol for Meshtastic is really quite simple (and sub-optimal). If you want to test its theoretical performance, you can have a look at the [simulator](https://github.com/GUVWAF/Meshtasticator). The protocol is heavily influenced by the mesh routing algorithm used in [RadioHead](https://www.airspayce.com/mikem/arduino/RadioHead) (which was used in very early versions of this project). It has four conceptual layers. +The routing protocol for Meshtastic is designed to support all kinds of different use-cases. Most importantly, it does not assume merely static nodes. If you want to test its theoretical performance, you can have a look at the [simulator](https://github.com/GUVWAF/Meshtasticator). The protocol is heavily influenced by the mesh routing algorithm used in [RadioHead](https://www.airspayce.com/mikem/arduino/RadioHead) (which was used in very early versions of this project). It has four conceptual layers and (since version 2.6) uses a different approach for broadcasts and direct messages.
), meaning that every node rebroadcasts a packet it receives, up till a certain hop limit. However, an important difference in Meshtastic is that before rebroadcasting, a node listens a short while to see if no other node already rebroadcasted it. If so, it will not rebroadcast. "Managed Flooding" is therefore a better term. The principle is as follows. If any mesh node sees a packet with a HopLimit other than zero, it will decrement that HopLimit and attempt to rebroadcast on behalf of the original sending node. In order to promote letting nodes that are further away flood the message, such that the message eventually reaches farther, the contention window (see Layer 1) for a flooding message depends on the Signal-to-Noise Ratio (SNR) of the received packet. The CW size is small for a low SNR, such that nodes that are further away are more likely to flood first and closer nodes that hear this will refrain from flooding. An exception to this rule is for the `ROUTER` and `REPEATER` roles, that have a higher priority to rebroadcast and will do so even if they hear another node rebroadcasting. @@ -101,6 +103,13 @@ Since node 1 heard the rebroadcast by 2, it will not rebroadcast again. Node 3 h ![Mesh algorithm example](/img/SNR_based_flooding.webp) +## Direct messages using Next-Hop routing + +Since version 2.6, Meshtastic uses a different approach for direct messages. Initially, the managed flooding approach as mentioned before is used to reach the destination. +We'll then keep track of the node(s) that are trying to relay the packet for us. If upon a successful delivery, a response comes back (e.g., a NodeInfo response, acknowledgment or traceroute) and the node that relays this towards you was also (one of) the node(s) that relayed the original packet, it will be denoted as next-hop from now on. This means that instead of letting all nodes try to relay the packet, only the node for which the next-hop byte matches will. Note that this is determined per hop, so if there is an asymmetric link or a node on older firmware in between, managed flooding will be used on this hop. When a node moves, or RF conditions change, it might be the next-hop is not valid anymore. Therefore, a node will always fall back to managed flooding at the last retransmission attempt if it doesn't hear its next-hop relay. +The procedure is visualized in the following diagram: +![Next-Hop Routing procedure](/img/NextHopRouting.svg) + ### Regular Broadcast Intervals Without additional modules configured, nodes will produce three different types of regularly intervaled traffic as part of the mesh: diff --git a/static/img/NextHopRouting.svg b/static/img/NextHopRouting.svg new file mode 100644 index 00000000..25f6cf97 --- /dev/null +++ b/static/img/NextHopRouting.svg @@ -0,0 +1,4 @@ + + + +
A
A
B
B
E
E
D
D
C
C
1. Initial transmission from A to D via managed flooding
1. Initial transmission from A to D via managed...
A
A
B
B
E
E
D
D
C
C
2. Acknowledgement or response from D to A
2. Acknowledgement or response from D to A
Relayers: B, E
Relayers: B, E
Next hop: D
Next hop: D
Next hop: B
Next hop: B
A
A
B
B
E
E
D
D
C
C
3. Subsequent transmission from A to D
3. Subsequent transmission from A to D
Next hop: B
Next hop: B
Next hop: D
Next hop: D
If no response: retry
If no response:... \ No newline at end of file