# Performance Evaluation of a Mesh-Topology LoRa Network
## 5 Proposed Approach: LoRaMesh
### LoRa-Mesh MAC
#### 5.1.1 Real-Time Clock (RTC) Synchronisation in the Network  
The LoRa mesh network topology requires strict transmission and reception scheduling to minimise the guard time required before each reception window is opened. This minimises the time each repeating node spends in standby mode, waiting for a child node to transmit, and minimises packet collisions due to timing issues. To achieve these stringent timing requirements, a network synchronisation method is proposed. Out-of-band time synchronisation is a technique where timing information is disseminated on a channel other than what is used for data traffic. Common technologies employed in IoT technologies include using a Global Navigation Satellite System (GNSS) (e.g., GPS, BDS, Galileo, ect. ), radio-controlled clocks (e.g., DCF77), or an FM radio data broadcasting systems (e.g., FM-RDS) [29]. Each of these technologies comes with its drawbacks, such as coverage and availability, and most importantly, requires specialised electronic components to be added to the bill of material. Power consumption is also a major factor to consider when using GNSS as a synchronisation system, as most applications keep the receiver off until a position/timing update is required to minimise idle power consumption. When attempting to acquire and lock onto the satellite signal, the navigation message data rate is low (50 bits/s), hence the receiver must be powered on for several seconds to receive the broadcast data (typically 28 s or longer), which can have a significant impact on power-constrained LPWAN devices. Due to the above-mentioned drawbacks, we propose the use of an in-band time synchronisation technique in this study. The LoRa Alliance have also proposed an in-band timing synchro  
Figure 2: Real-Time Clock (RTC) synchronisation and up-link messages overview. nisation method for single-hop nodes in [30], where timing information is requested by nodes from the gateway in a periodic method. We propose the use of a simple, periodic, flooding-based, beacon frame timing dissemination. The gateway is responsible for the initialisation of the beacon frame flooding; therefore, it requires access to accurate timing information. Possible sources include an IP-based network or a GNSS radio receiver. The gateway should capture the current time-stamp immediately before transmitting the timing beacon frame. Emphasis should be placed on the gateway's firmware to minimise the processing delay between the time capture and the beacon transmission. A new timing synchronisation update is initialised by a gateway transmitting a single beacon timing frame. This single beacon frame, transmitted by the gateway, is received by all the nodes in the network which are assigned to the first hop. These nodes then retransmit the beacon frame based on whether or not they have any child nodes assigned to them (it is assumed that the routing structure of the network is known at this point, and this topic will be discussed further in Section 5.2). This prevents unnecessary re-transmission of the beacon frame if no child nodes are assigned to the node, thereby reducing the power consumption of the timing synchronisation update and minimising the risk of collisions between re-transmitted beacon frames. Nodes in the next hop then re-transmit the beacon frame based on the same criteria. The re-transmission of the beacon frame by the routing nodes is continued until all the nodes have re-transmitted the packet to their assigned child nodes, or the network's max number of hops (a network configuration parameter) has been reached. In networks with a high node density, the re-transmission of these beacon frames can potentially lead to packet collisions, which could lead to nodes not receiving the beacon frames.