## 6 Simulations and Experiments
### Experimental Results in a Real Environment  
To perform such experiments in the real world, the Meshtastic firmware of the devices must be slightly modified, and proper devices (compatible with the modified firmware) must be selected. To implement the model, you need to create a module for Meshtastic, or a subset of _SinglePortModule_. This way, the created module will automatically reload incoming packets from the network. These are forwarded to a certain port for listening \begin{table}
\begin{tabular}{l c} \hline \hline
**Setting** & **Value** \\ \hline \multicolumn{3}{c}{Parameters of the reputation model} \\ \hline
**Number of malicious nodes** & 1 \\
**Hop limit** & 5 \\ \(\alpha\) & 0.5 \\ \hline \multicolumn{3}{c}{Other parameters} \\ \hline
**Number of nodes** & 10 \\
**Pathloss model** & Suburban macro-cell 1 \\
**Max restrasmission** & 3 \\
**Frequency (Mhz)** & EU 868 \\
**Bandwidth (kHz)** & 240 \\
**Coding rate** & 4/8 \\
**Spreading factor** & 7 \\
**Data rate (kbps)** & 10.94 \\
**Simulation time (h)** & 48 \\
**Interval time (h)** & 1 \\ \hline \hline \end{tabular}  
* \({}^{\dagger}\) Specified by the 3 rd Generation Partnership Project (3 GPP) [27].  
\end{table} 
Table 1: Simulation configuration. Figure 5: Results of malicious node detection based on reputation score in the Meshtasticator simulator after 48 h (simulated). (it is not true that they have relevance to the classic network ports); in our case, our port was defined as \"REPUTATION_APP\", for which the port number was 256. The firmware was also forced to receive messages to simulate the architecture shown in Figure 2 because during the tests, the nodes were too close to not see each other, so all the nodes in the network (except for the border ones) ignored direct messages from nodes outside the network. As Table 2 shows, to test our model in real devices, we used boards based on ESP32 microcontrollers, manufactured by Espressif Systems, a Chinese company based in Shanghai. The same has been used in related research for privacy preservation in IoT networks [28; 29]. The used boards were the TIGO (or Lilygo) LoRa V2.1_1.6.1 equipped with ESP32 dual-core 32-bit microprocessors, 4 MB of flash memory, Wi-Fi and Bluetooth Low Energy, a 0.96 OLED display, an SX1276 868 MHz LoRa module and SMA LoRa antenna with 2 dbi of antenna gain; a Heltec Wireless Stick, also equipped with an ESP32 dual-core 32-bit microprocessor, 8 MB of flash memory, Wi-Fi and Bluetooth Low Energy, an SX1276 868 MHz LoRa module and a LoRa antenna with 1 dbi of antenna gain; and finally, a new Arduino Nano ESP32 equipped with an ESP32-S3 dual-core 32-bit microprocessor, 16 MB of flash memory, Wi-Fi and Bluetooth Low Energy, and an external SX1276 868 MHz LoRa module with zero antenna gain (a wire was used as the antenna). As a temperature sensor, a classic DHT11 was used during the tests. Figures 6 and 7 show the arrangement of the experiments in the laboratory (nodes 1-9 and the malicious node). The nodes were arranged relatively close together, so communication was forced so that the architecture shown in Figure 2 was respected. The devices were power bank-powered and programmed to go into deep sleep about every 47 min to save energy. Finally, Figure 8 contains the results of the experiments with our IoT devices after about 48 h: the behaviour of the devices is the same as in the simulations; they communicate the temperatures and exchange the feedback within the network. We can observe that, compared to the simulated environment, the measured reputation shows more oscillations. This is probably due to the delays in the communication of the LoRa packets. This study integrates trust thresholds to assess interactions among Smart Objects (SOs) based on feedback scores ranging from 0 to 1. These thresholds are pivotal in updating reputation scores and determining SO trustworthiness within the network.