# MPResiSDN: Multipath Resilient Routing Scheme for SDN-Enabled Smart Cities Networks
## 6 Results and Discussion
### Fire Challenges  
The results of evaluating the MPResiSDN scheme under the modeled fire challenge illustrated in Figure 9, using the actual throughput performance metric, are shown in Figure 13a. According to the fire challenge scenario, in the time interval between \(t=0\) and \(t=30\) the fire was too small to affect any sensor node. Consequently, the actual throughput in these time intervals was the same as the actual throughput under normal operating conditions. However, at \(t=30\), the fire expanded and began to affect the sensor nodes. In particular, some of the sensor nodes on path \(1\) were damaged by the fire. Note that Path \(1\) is the only path used in the MPResiSDN(\(k=1\)) scheme, whereas it is one of the selected paths in MPResiSDN(\(k=2\)) and MPResiSDN(\(k=3\)) schemes. Accordingly, the actual throughput produced by MPResiSDN(\(k=1\)) is zero at \(t=30\), while the throughput produced by the MPResiSDN(\(k=2\)) and MPResiSDN(\(k=3\)) schemes is reduced. At \(t=60\), the fire had expanded and affected both paths \(1\) and \(2\). Consequently, the throughput produced by the MPResiSDN(\(k=2\)) scheme under normal conditions was completely obstructed, because all paths used by that scheme were blocked. The MPResiSDN(\(k=3\)) scheme continued to function because it had more alternative paths, including path \(3\), which was not affected by the fire challenge at this time. In this case, the importance of implementing an algorithm with more alternative paths, such as MPResiSDN(\(k=3\)) is evident. While the actual throughput shows how each scheme behaves in the face of a certain challenge, the goodput shows whether that behavior ultimately succeeded in delivering the required data. Figure 13b shows the detailed results of measuring the goodput over time  
Figure 13: Comparison of the four strategies under the fire challenge. under the modeled fire challenge. As expected, all schemes worked well at the beginning because none of the paths were affected by the fire challenge. However, when the fire challenge started to hit path 1, which is the only path used in the \(\text{MPResiSDN}(k=1)\) and Spanning Tree schemes, both algorithms failed to deliver data. \(\text{MPResiSDN}(k=2)\) and \(\text{MPResiSDN}(k=3)\) performed well until the fire started to hit path 2 at \(t=60\). At this time, \(\text{MPResiSDN}(k=2)\) failed because both of the paths it uses failed. \(\text{MPResiSDN}(k=3)\) continued to work well as it had an additional alternative path to use. The Spanning Tree algorithm struggled after the fire started to impact any path because it takes a very long time to figure out a new path to use. Figure 12(c) shows the details of the overhead generated by the four schemes under the fire challenge over time. Given that \(\text{MPResiSDN}(k=3)\) uses two additional alternative paths to deliver data, it takes approximately twice the amount of throughput compared to \(\text{MPResiSDN}(k=1)\) when no challenge is presented at the beginning. In other words, \(\text{MPResiSDN}(k=3)\), under no challenge, results in an overhead of 200% of the actual amount of data produced by \(\text{MPResiSDN}(k=1)\). Similarly, \(\text{MPResiSDN}(k=2)\) generates double the actual throughput produced by \(\text{MPResiSDN}(k=1)\). \(\text{MPResiSDN}(k=1)\) and Spanning Tree deliver the data without any additional overhead. These results confirm the finding mentioned previously when discussing the normal operation case, i.e., alternative paths are only worthwhile under challenges. However, when the fire starts to affect the path used by \(\text{MPResiSDN}(k=1)\) and Spanning Tree schemes at \(t=30\), they fail completely. Consequently, no traffic is generated; thus, there is no overhead. At this point, \(\text{MPResiSDN}(k=2)\) works the same as \(\text{MPResiSDN}(k=1)\) under normal operation, while \(\text{MPResiSDN}(k=3)\) works the same as \(\text{MPResiSDN}(k=2)\) under normal operation.