## 5 Use Case: IWSN Resilience Using Maintenance 5.0
### Use Case Background  
This publication is supported by a previous use case experiment carried out with IWSNs [107] that validated only the detection part of the proposed Maintenance 5.0 framework, answering the question: which configuration helps more to protect an IWSN from uncertainty? As seen in Figure 15, the experiment consisted of 12 homogeneous sensor network nodes in an area of 500 m\({}^{2}\), sending data from seven days to a sink node located in the center of the grid. The Node RAM of the sensor nodes is 128 KB, and the nodes work with a voltage range from 1.8 V to 3.8 V.  
The CC2530 sensor node has been used for the gateway. This node is good in system-on-chip solutions for Zigbee and 2.4 GHz IEEE 802.15.4, optimum for industrial control and monitoring, building automation, and low-power WSNs. On the other hand, the CC2650 SimpleLink sensor node has been used for sensor nodes. It supports Multi-Standard Wireless MCU: Bluetooth, Zigbee, 6 LowPAN, and IPv6, and offers low-power consumption supporting low-power sensors such as ambient light, infrared temperature, ambient temperature, accelerometer, gyroscope, magnetometer, pressure, humidity, microphone, magnetic sensor, etc. Six nodes of the experiment are based on the Zigbee protocol and the other six are based on the Lora protocol [107]. The jammer nodes imitated the constant jamming attacks to put noise into the network and distort communication. Three performance metrics were sampled using cooperative and collaborative network schemes: the Packet  
Figure 14: Worker 5.0 collaboration in Jamming Detection and Mitigation.  
Figure 15: Distribution of the IWSN nodes of the experiment. Image obtained from [107].  
Delivery Ratio (PDR), the Receive Signal Strength Indicator (RSSI), and the Energy. The experiment's results for Energy (J) metric are shown in Table 9.  
These results have shown that in the event of a drop in performance metrics due to the presence of a jammer, a collaborative scheme can be used to mitigate part of the damage.  
_Jamming Detection algorithm._ Upon receiving a jamming attack, the IWSN has the current levels of its performance metrics (Energy, PDR, RSSI), which feed into the jamming detection algorithm shown in Figure 16. The performance metrics-based algorithm uses cooperative and collaborative schemes for any density of nodes is based to detect constant, deceptive, random, and reactive jamming.  
Figure 16: Jamming Detection Algorithm. Image obtained from [107].  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Jamming** & \multicolumn{2}{c}{**Energy (J)**} \\ \hline \multicolumn{2}{c}{**Cooperative**} & \multicolumn{2}{c}{**Collaborative**} \\ \hline Constant jamming & 0.37 & 0.32 \\ \hline No Jamming & 0.09 & 0.07 \\ \hline \hline \end{tabular}
\end{table}
Table 9: Jamming experiment results. Data obtained from [107].  
For the detection of jamming, the measurements of the analyzed metric are ordered from the smallest to the largest and the thresholds are calculated. Thresholds are then compared with the real-time measurement. For the algorithm to return the presence of Jamming, a Counter \(\big{(}C_{CO},\ C_{DE},C_{RA},C_{RE}\ or\ C_{NJ}\big{)}\) must be equal to three.