# Trust and Mobility-Based Protocol for Secure Routing in Internet of Things
## 5 Simulation Study
### Results and Analysis
#### 5.2.4 Comparison of Power Consumption  
The power consumption depends on the nodes' involvement in the network, for example the frequency of rank change, parent selection, and trust computation, so it cannot be consistent for all the nodes for three scenarios under attacks. This is reflected in the graphical analysis of average results for power consumption in Figures 6-8 for Scenario I, II, and III, respectively. It can be observed that SMTrust shows a comparably acceptable power consumption value for all three scenarios, with an average difference of only 0.22 mW. This difference is due to the computations involved in trust metrics calculations and trust evaluation, including the control messages transmission. For this research, the improvement of power consumption is beyond the scope and will be considered in future work. The values for power consumption of nodes are taken from the sensor collect view in Cooja simulator. Some of the nodes consume more power than others because they are chosen as preferred parents more frequently. In addition, the increased frequency of node rank changes, that is, topology instability, causes more power consumption, as in case of MRHOF. Similarly, according to the scenario for static nodes (Scenario I), SMTrust consumes more power as compared to other OFs, because of the computations involved; specifically, the mobility-based metrics for trust calculation is not applicable for static scenario. Whereas for Scenario II and Scenario III in which the nodes are mobile, the power consumption is less as compared to other OFs, because the mobility metrics involved for trust calculation play a part in parent selection according to neighbouring nodes' mobile nature. IoT networks are lossy in nature, and for this research we have considered the packet loss rate under the attack scenario. It is worth noting that the packets can be lost due to link unreliability (lossy nature), collisions, or attack scenarios. Since isolating the packet loss due to collisions or link instability would be a much more complicated task to undertake, in our experiments we therefore reported the overall packet loss rate. This is justified because the parameters settings and simulation configurations remain the same for all the experiments. From the average values, it can be analysed that SMTrust performs better than Secret Trust and MRHOF in Scenarios I, II, and III under attacks. Overall, SMTrust offers more stable topology in all three scenarios under attacks in comparison with existing methods. Overall, SMTrust shows better performance for both Rank and Blackhole attacks. SMTrust performance is better for Scenario II in comparison with Scenario I and Scenario III, indicating the importance of mobility-based trust metrics computation for parent selection algorithm. Moreover, the effects of sink mobility degrade the network performance for SMTrust under Rank and Blackhole attacks compared to Scenario I and II results. However, SMTrust still outperforms in overall network performance parameters, including topology stability, packet loss rate, and throughput measurement of nodes, thus indicating significant improvement as compared to existing systems. The major impacts of the considered RPL attacks include the increased packet loss and reduced throughput, which is evident from the results of the default objective function MRHOF, that is, the increase in packet loss rate, the reduction of average throughput, and the increase in the frequency of nodes rank change. It is to be noted that there is no attack defence mechanism in MRHOF, which is RPL's default implementation. When SMTrust is integrated into RPL's objective function, the results under attack scenarios show that the packet loss rate is reduced and throughput is increased as compared to MRHOF, thus justifying the detection of attacks by eliminating the malicious nodes from the potential parents list and adding to the suspicious list, leading to its isolation from the network when no traffic will pass through it.