## 3 The Meshtastic Protocol  
The Meshtastic protocol [8] is a robust and efficient routing protocol specifically designed for mesh networks, with a particular focus on LoRa-based wireless communication. This protocol provides a simple yet effective mechanism for facilitating communications within a mesh network. It is, therefore, well-suited for applications requiring low-power, long-range wireless connectivity. The Meshtastic protocol is heavily influenced by the mesh routing algorithm used in RadioHead [20], a popular open-source Arduino library for various wireless modules. RadioHead operates on the LoRa physical layer, which enables long-range communication while consuming minimal power. The protocol's design is simple and aimed at minimising power consumption, which is crucial for battery-operated devices in remote or resource-constrained environments. The protocol enables the creation of self-organising mesh networks, where each device can receive and transmit messages from other network participants. Additionally, each device can act as a repeater, extending the network's diameter. This inherent capability for message relaying is a key feature of the protocol,enabling the establishment of robust and expansive mesh networks without the need for a centralised infrastructure. The Meshtastic protocol is structured into four conceptual layers, each serving a specific function in the routing process (Figure 1):  
* **Unreliable Zero-Hop Messaging** This layer is represented by a conventional non-reliable LoRa packet transmission. It provides the most basic form of message delivery within the network. In addition to the converted packet bytes, there is also a preamble sent at the start of any data packet. This preamble allows receiving radios to synchronise clocks and start framing. The protocol uses a preamble length of 16, which is longer than the minimum preamble length of 8. After the preamble comes the LoRa Physical Header, which contains information about the packet length as well as a sync word to distinguish networks (in this case, it is set to \(\mathbf{0x2B}\)). * **Reliable Single-Hop Messaging** Building upon the first layer, this layer ensures reliable LoRa packet transmission within a single hop, by extending the messaging provided by layer1 with the _WantAck_ flag in the MeshPacket protobuf. This flag holds special significance in the context of broadcast messages: in this special case, the standard ACK behaviour is intentionally restrained to avoid the saturation of the channel with ACK messages. Instead, the initial sender monitors the channel to ascertain whether at least one node is rebroadcasting the packet, adhering to a naive flooding algorithm. * **Reliable Multi-Hop Messaging** This layer enables the transmission of LoRa packets across multiple network nodes by extending the reliability to multi-hop scenarios. The protocol is mainly designed around flooding to meet our specific use case. Nevertheless, the current implementation does not incorporate optimisation strategies for flooding, except for discontinuing re-transmission once a node observes a nearby receiver acknowledging the flooded packet. Consequently, in an N-node mesh, there is potential for up to N re-transmissions of a packet. If any node within the mesh perceives a packet with a HopLimit other than zero, it will decrement that HopLimit counter and endeavour to re-transmit the packet on behalf of the original sender. To encourage distant nodes to flood the message, thereby ensuring its broader dissemination, the contention window (refer to Layer 1) for a flooding message is contingent on the signal-to-noise ratio (SNR) of the received packet. To obtain a low SNR (signal-to-noise ratio), the contention window size is small, enhancing the likelihood that nodes farther away will flood first, while closer nodes receiving this information will refrain from flooding.