# Wireless Mesh Networking: An IoT-Oriented Perspective Survey on Relevant Technologies
## 6 LoRa Mesh Networking
Three types of packets have been defined, as shown in Figure 8: (i) Route REQUest (RREQ) packet; (ii) Route REPly (RREP) packet; and (iii) Route ERRor (RERR) packet. The additional overhead in the packet is due to RREQ and RREP packets and is equal to 44 bytes; this amount of bytes depends on the number of traversed gateways, since RREQ and RREP are added for each gateway the packet goes through. Routing thus implies a significant increase of control overhead, since the standard LoRaWAN header adds 13 bytes. This amount is, however, balanced by the fact that LoRa-based networks will have a small number of hops, due to long-range hops. The proposed protocol has been investigated both in laboratory and through on-field experiments, evaluating the construction time of the route, which is shown in Figure 9. It is interesting to remark that the construction time is a linearly increasing function of the number of hops. Figure 7: LoRaWAN network topology. (**a**) Star of star topology in LoRaWAN network; (**b**) Mesh topology in LoRaWAN network. In [76], the authors state that, in order to increase the performance of LoRa networks, a good strategy can be the adoption of mesh networking approach, without increasing the number of gateways, which are expensive and require high computational power. The proposed design takes a different approach by building a wireless mesh network system based on LoRa PHY rather than LoRaWAN, allowing all LoRa devices to act as data routers. Their work is based on the principle that a generic node \(n\) can listen for a beacon or overhear a data packet from a nearby GW. In the network-join phase, the end-node chooses a parent node, namely the GW or another end-node, which it sends a JOIN request to according to some metric (e.g., link quality based on RSS indicator of received packets). When a data packet arrives, there are three scenarios: (i) if the incoming packet destination is \(n\), then \(n\) will process the packet; (ii) if the destination is not \(n\) itself but the packet destination is a parent or a child of \(n\), then it will help to relay it to the destination; (iii) otherwise, it will drop the packet. Figure 8: Route REQUest (RREQ), Route REPly (RREP) and Route ERRor (RERR) packet format. Figure 9: Measured construction time [75]. The system in [76] has been tested in a Campus-scale experiment in which 19 LoRa motes were deployed, considering both single- and multi-hop scenarios. The performance results, in terms of PDR, are shown in Figure 10. Some nodes, as highlighted in Figure 10, benefit from the multi-hop environment, i.e., the mesh network can significantly increase the PDR without installing additional GWs. In [77], a solution compatible with LoRaWAN specifications is provided, limiting to the uplink multi-hop case. The network, depicted in Figure 11, is composed by end-nodes, which are called Leaf Nodes (LNs) and are energy-constrained, and intermediate nodes, which are called Routing Nodes (RNs) and are not energy-constrained. The proposed protocol is based on a simplified version of Destination-Sequenced Distance Vector (DSDV) and is built on top of a standard LoRaWAN packet. Thus, end-to-end security and interoperability with LoRaWAN gateways is preserved. Basically, LNs send a LoRaWAN packet to the closest relay node, appending a routing overhead to it. The overhead is then dropped by the relay node and only the LoRaWAN packet is received by the gateway. The possible packets, shown in Figure 12, correspond to the following ones:  
* full dumps packets, containing route informations (such as next-hop and rate/link metric)--dumps are transmitted after receiving a beacon;
* data packets, containing the actual data to be sent. In the performance evaluation carried out in [77], both PDR and throughput are investigated. In the single-hop scenario, the measured PDR was 99.4%, with a throughput \(T=35.39\) b/s; in a two-hop scenario, without routing, but using a simple forwarder, the performance is characterized by \(T=34.73\) b/s and \(PDR=97.6\%\).