## 3 Nodes' Configuration and Transmission Protocol
In particular, we have implemented an architecture composed of 2 Sensor Nodes and one Gateway Node arranged in a chain fashion: such a configuration allows to set up a a multi-hop connection between one Sensor Node (from here on called the End Node-EN) and the Gateway (GW), exploiting the second Sensor Node as the intermediate hop (from here on called the Intermediate Node-IN). The hardware architecture of the nodes is the same as the one adopted for the LoRa transmission range tests, for both the Sensor Nodes and the GW. Regarding the software, the IN node has been provided with an ad-hoc firmware aimed at realizing the routing functionality that is not available in the standard LoRa protocol. In particular, we have implemented the receiving and transmitting functionalities in the same IN node, whereas standard LoRa nodes are configured to exclusively transmit or receive packets. To further elaborate, both nodes are kept active for a limited span of time after which they go back into sleeping mode for a fixed amount of time. Conversely, the GW is kept always active since in the final configuration it is expected to be powered by the electricity grid. Duty-cycling is implemented exploiting the internal clock of the microcontrollers. More specifically, the EN node is activated every \(T_{EN}\) seconds to transmit a single packet. As for the IN node, it is activated every \(T_{IN}\) seconds and, upon activating, it goes into listen mode for a fixed period: if it receives a packet, it forwards it to the GW and then it goes back into sleeping mode. In the case of ideal internal clocks, the sleeping period \(T_{IN}\) of the  
Figure 5: Distribution of the clock error. IN could be calculated so that the IN node wakes up at the exact time the EN node transmits its packet, i.e., since the IN node goes to sleep \(T_{onAir}\) seconds later than the EN node, we have \(T_{IN}=T_{EN}-T_{onAir}\). However, owing to synchronization errors, the IN node should wake-up in advance in order to prevent situations in which the EN node transmits while the IN node is still sleeping. Accordingly, we have set \(T_{IN}=T_{EN}-4\) s, i.e., with a time advance of nearly 2 s with respect to the ideal case. We have then collected results for three different \(T_{EN}\) values, i.e., \(T_{EN}=120\) s, \(T_{EN}=300\) s and \(T_{EN}=600\) s. In all situations, we have transmitted 100 packets and we have measured the number of packets received by the GW. The results are shown in Table 2.  
It is worth noting that in the considered setting, \(T_{EN}=120\) s is the maximum allowable sleeping period to prevent synchronization loss between the nodes. With such a relatively low sleeping period the IN node would consume nearly 4 mAh every hour, with 30-40 days of battery duration, that is definitely unsustainable in the scenario at hand. Of course, in the presence of a longer network with more than one packet to be delivered towards the GW, the situation will only get worse. In order to increase the sleeping periods up to 1 h, that is acceptable for the Bottini monitoring system, it is necessary to devise an ad-hoc synchronization and data transmission protocol, that is the subject of the next Sections.