Simulation Outputs
The evaluation of the simulation result is displayed in this section. First, randomly generate the blockchain connection. After that, communication occurs inside the MANET, then the blockchain is integrated into the network, and nodes are recognized by their relevant weights. The most efficient method of interaction has also been used to finish a transaction over the MANET. At last, a range of attacks are included in the set of data in training, and a range of assaults are validated in datasets by testing. The creation of a node in the MANET blockchain with the proper weight is shown in
Figure 13.
A node is built using a blockchain, with every node having the appropriate weight after the block is created and the data is hashed. In
Figure 13a, Node 1 is the source node and Node 25 is the destination node. The shortest paths go from Node 1 to Node 9, from Node 9 to Node 23, from Node 23 to Node 7, and from Node 7 to Node 25. This may result in improved network performance generally and in transaction confirma-tion times. Also,
Figure 13b–d shows the shortest-path calculation. Due to its ability to quickly recalculate routes and preserve connectivity, shortest-path algorithms can dynamically adapt to changes in network topology, such as those caused by node mo-bility or link failures. As networks grow, the shortest-path algorithms are a good choice since they can manage larger MANETs more effectively than certain routing tech-niques. The simulation parameters of the proposed method are depicted in
Table 3.
Figure 14 and
Table 4 show the average end delay(s) of the proposed methods by varying pause time. This graph demonstrates that the average end delay rises with the pause time over a period of time. For a pause time of 20, the proposed model achieves an average end delay of 19.2 s, compared to the average end delays of the existing SRABC, GRP, and HWMP methods, which are 18.2, 14.21, and 12.34 s, respectively. For a pause time of 40, the proposed model achieves an average end delay of 20.5 s, com-pared to the average end delays of the existing methods of 19.1, 15.5, and 13.4 s, re-spectively. For a pause time of 60, the proposed model achieves an average end delay of 21.3 s, compared to the average end delays of existing methods of 20, 16.4, and 14.34 s, respectively. For a pause time of 80, the proposed model achieves an average end delay of 22.6 s, compared to the average end delays of the existing methods of 21.2, 17.71, and 15.45 s, respectively. For a pause time of 100, the proposed model achieves an av-erage end delay of 23.6 s, compared to the average end delays of the existing methods of 22, 18.34, and 16.12 s, respectively. As a result, the graph indicates that the recom-mended technique performs better in terms of end-to-end delay.
Figure 15 and
Table 4 show the average end delay(s) of the proposed and existing methods by varying pause time. For a pause time of 20, the proposed model achieves an average end delay of 0.04 s, compared to the average end delays of the existing SRABC, AODV, and DSR methods, which are 0.09, 0.19, and 0.197 s, respectively. For a pause time of 40, the proposed model achieves in 0.073 s, compared to the existing methods, which are 0.115, 0.178, and 0.19 s, respectively. For a pause time of 60, the proposed model achieves an average end delay of 0.132 s, compared to the average end delays of the existing methods, of 0.158, 0.187, and 0.2 s, respectively. For a pause time of 60, the proposed model achieves an average end delay of 0.132 s, compared to the average end delays of the existing methods, which are 0.158, 0.187, and 0.2 s, respec-tively. For a pause time of 80, the proposed model achieves an average end delay of 0.166 s, compared to the average end delays of the existing methods, which are 0.188, 0.2, and 0.218 s, respectively. For a pause time of 100, the proposed model achieves an average end delay of 0.172 s, compared to the average end delays of the existing methods, which are 0.198, 0.21, and 0.22 s, respectively. As a result, the graph indicates that the recommended technique performs better in terms of end-to-end delay. For a pause time of 100, the existing SRABC method pause time is 0.198 s, which the pro-posed method improves to 0.074 s. For a pause time of 100, the existing AODV method pause time is 0.21 s, which the proposed method improves to 0.038 s. For a pause time of 100, the existing DSR method pause time is 0.22 s, which the proposed method improves to 0.048 s.
Figure 16 and
Table 4 show the dropped packets of proposed and existing methods by varying time (s). At a time of 0 s, the proposed method achieves a number of dropped packets of 12.2, whereas for the existing SRABC, AODV, and DSR methods, the numbers of dropped packets are 19.5, 46 and 61, respectively. At a time of 100 s, the proposed method has 30.6 dropped packets, whereas the existing methods have 39.3, 60 and 76, respectively. At a time of 200 s, the proposed method has 41.8 dropped packets, whereas the existing methods have 48.5, 79, and 90, respectively. At a time of 300 s, the proposed method has 48.5 dropped packets, whereas the existing methods have 58.5, 88.5, and 98, respectively. At a time of 400 s, the proposed method has 57.6 dropped packets, whereas the existing methods have 69.7, 89, and 99.5, respectively. So, the generated graph proves that the recommended strategy achieves a very low packet drop ratio. At a time of 400 seconds, the existing SRABC method time is 69.7 s, which the proposed method improves to 12.1 s. At a time of 400 seconds, the existing AODV method time is 89 s, which the proposed method improves to 31.7 s. At a time of 400 seconds, the existing DSR method time is 99.5 s, which the proposed method improves to 41.9 s.
Figure 17 and
Table 4 show the packet-delivery ratio (%) of the proposed methods by varying time. At a time of 20 seconds, the packet-delivery ratio of the proposed method is 72.2%, whereas the packet-delivery ratios of the existing SRABC and HWMP methods are 69.5% and 52.54%, respectively. At a time of 40 seconds, the pack-et-delivery ratio for the proposed method is 79.5%, whereas for the existing methods, it is 76%, 64%, and 58%, respectively. At a time of 60, the packet-delivery ratio for the proposed method is 82.3%, whereas for the existing methods, it is 78.6%, 66%, and 60%, respectively. At a time of 80 seconds, the packet-delivery ratio for the proposed method is 87.6%, whereas for the existing methods, it is 84%, 72%, and 68%, respectively. At a time of 100, the packet-delivery ratio for the proposed method is 91.6%, whereas for the existing methods, it is 89.1%, 78.2%, and 73.3%, respectively. The graph clearly in-dicates that the proposed method’s packet-delivery ratio obtains the maximum value compared to the prior techniques.
Figure 18 and
Table 4 show the packet-delivery ratio (%) of the proposed and existing methods by varying time. At a time of 200 seconds, the packet-delivery ratio of the proposed method is 93.3%, whereas for the existing SRABC, AODV, and DSR methods, it is 91.7, 84 and 71.5%, respectively. At a time of 400 seconds, the packet-delivery ratio for the proposed method is 95.2%, whereas for the existing methods, it is 94%, 85%, and 75%, respectively. At a time of 600 seconds, the packet-delivery ratio for the proposed method is 96.4%, whereas for the existing methods, it is 95%, 90%, and 79%, respectively. At a time of 800 seconds, the pack-et-delivery ratio for the proposed method is 98.1%, whereas for the existing methods, it is 96.5%, 91.5%, and 87.2%, respectively. At a time of 1000 seconds, the packet-delivery ratio for the proposed method is 99.1%, whereas for the existing methods, it is 98%, 94%, and 91%, respectively. So, the proposed method delivers a higher packet ratio when compared to other approaches. At a time of 1000 seconds, the existing SRABC method time is 98 s, which the proposed method improves to 1.2 s. At a time of 1000 seconds, the existing AODV method time is 94 s, which the proposed method improves to 5.2 s. At a time of 1000 seconds, the existing DSR method time is 91 s, which the proposed method improves to 8.2 s.
Figure 19 and
Table 4 show the throughput (packets) of the proposed methods by varying time. At a time of 20 seconds, the proposed model achieves a throughput of 580, compared to the throughputs of the existing SRABC, HWMP, and GRP methods which are 350, 170, and 90, respectively. At a time of 40 seconds, the proposed model achieves a throughput of 940, compared to the throughputs of the existing methods, which are 700, 530, and 320, respectively. At a time of 60 seconds, the proposed model achieves a throughput of 1230, compared to the throughputs of the existing methods, which are 950, 790, and 580, respectively. At a time of 80 seconds, the proposed model achieves a throughput of 1880, compared to the throughputs of the existing methods, which are 1550, 1332, and 1190, respectively. At a time of 100 seconds, the proposed model achieves a throughput of 2110, compared to the throughputs of the existing methods, which are 1780, 1510, and 1340, respectively. So, the proposed method is to enable higher actual throughput while reducing total expenses for overhead.
Figure 20 shows the end-to-end delay of the proposed and existing methods by varying nodes. For Node 20, the proposed method achieves an end-to-end delay of 15.2, compared to the end-to-end delays of the existing SRABC, HEDAR, and SETORD methods, which are 16.5, 17.3, and 18.4, respectively. For Node 40, the proposed method achieves an end-to end delay of 16.3, compared to the end-to-end delays of the existing methods, which are 17.8, 18, and 19.1, respectively. For Node 60, the proposed method achieves an end-to-end delay of 16.6, compared to the existing methods’ end-to-end delays, which are 18.2, 19.1, and 20, respectively. For Node 80, the proposed method achieves an end-to-end delay of 18.4, compared to the existing methods’ end-to-end delays, which are 19.4, 20.1, and 21.3, respectively. For Node 100, the pro-posed method achieves an end-to-end delay of 19.1, compared to existing methods’ end-to-end delays, which are 19.7, 21 and 22, respectively. The figure demonstrates that, in comparison to the preceding method, the end-to-end delay is insignificant. For Node 100, the existing SRABC method node is 19.7, which the proposed method im-proves to 0.6. For Node 100, the existing HEDAR method node is 21, which the pro-posed method improves to 1.9. For Node 100, the existing SETORD method node is 22, which the proposed method improves to 2.9.
Figure 21 shows the packet-delivery ratio of proposed and existing methods by varying nodes. For Node 20, the proposed method achieves a packet-delivery ratio of 99, compared to existing SRABC, HEDAR, and SETORD methods’ packet-delivery ra-tios of 98.7, 96, and 95. For Node 40, the proposed method achieves a packet-delivery ratio of 99.1, compared to existing methods’ packet-delivery ratios, which are 98.8, 96.8, and 96.2, respectively. For Node 60, the proposed method achieves a pack-et-delivery ratio of 99.4, compared to existing methods’ packet-delivery ratios, which are 99.2, 97.4, and 97, respectively. For Node 80, the proposed method achieves a pack-et-delivery ratio of 99.6, compared to existing methods’ packet-delivery ratios, which are 99.4, 98.5, and 98.2, respectively. For Node 100, the proposed method achieves a packet-delivery ratio of 99.8, compared to existing methods’ packet-delivery ratios of 99.5, 99.4, and 99.1, respectively. So, the proposed method produces better results than other methods. For Node 100, the existing SRABC method node is 99.5, which the pro-posed method improves to 0.3. For Node 100, the existing HEDAR method node is 99.4, which the proposed method improves to 0.4. For Node 100, the existing SETORD method node is 99.1, which the proposed method improves to 0.7.
Figure 22 shows the routing overhead (%) of the proposed methods by varying nodes. At a time of 20 seconds, the proposed model achieves a routing overhead of 4, compared to the routing overheads of the existing SRABC, HWMP, and GRP methods which are 9, 12, and 17, respectively. At a time of 40 seconds, the proposed model achieves a routing overhead of 15.5, compared to the existing method’s routing over-heads, which are 21, 24, and 32, respectively. At a time of 60 seconds, the proposed model achieves a routing overhead of 31.2, compared to the existing method’s routing overheads which are 37, 41, and 53, respectively. At a time of 80 seconds, the proposed model achieves a routing overhead of 42.1, compared to the existing method’s routing overheads, which are 48, 53, and 61, respectively. At a time of 100 seconds, the pro-posed model achieves a routing overhead of 64.3, compared to the existing method’s routing overheads, which are 69, 74, and 82, respectively. The graph illustrates that the proposed approach leads to a decrease in routing costs.
Figure 23 shows the routing overhead (%) of proposed and existing methods by varying nodes. For 20 nodes, the proposed method’s routing overhead is 5%, compared to the routing overheads of the existing SRABC, HEDAR, and SETORD methods, which are 8.7, 9, and 10%, respectively. For 40 nodes, the proposed method achieves a routing overhead of 14.6%, compared to existing methods’ routing overheads, which are 19, 27, and 22%, respectively. For 60 nodes, the proposed method achieves a routing overhead of 26%, compared to existing methods’ routing overheads, which are 29, 32, and 37%, respectively. For 80 nodes, the proposed method achieves a routing overhead of 30.4%, compared to existing methods’ routing overheads, which are 35, 47, and 48%, respec-tively. For 100 nodes, the proposed method achieves a routing overhead of 41.7%, compared to existing methods’ routing overheads, which are 45, 60, and 69%, respec-tively. So, the proposed method may permit routing to certain networks, and it in-creases security. For Node 100, the existing SRABC method node is 45, which the pro-posed method improves to 3.3. For Node 100, the existing HEDAR method node is 60, which the proposed method improves to 18.3. For Node 100, the existing SETORD method node is 69, which the proposed method improves to 27.3.
Figure 24 shows the throughput (packets) of the proposed and existing methods by varying time. At a time of 2 s, the throughput of the proposed method is 6100, whereas the throughputs of the existing SRABC, OLSR, AODV, DSR, and DSDV meth-ods are 2100, 5719,1750, 1500, and 3141, respectively. At a time of 4 s, the proposed method’s throughput is 6710, whereas the existing methods’ throughputs are 3700, 6193, 3100, 3000, and 3560, respectively. At a time of 6 s, the proposed method’s throughput is 7400, whereas the existing methods’ throughputs are 4600, 6415, 4150, 4100, and 4233, respectively. At a time of 8 s, the proposed method’s throughput is 8100, whereas the existing methods’ throughputs are 5950, 6891, 5150, 5050, and 4436, respectively. At a time of 10 s, the proposed method’s throughput is 9100, whereas the existing methods’ throughputs are 8500, 7637, 6700, 6250, and 4656, respectively. Therefore, the proposed method offers higher throughput, offering an effective trans-mission rate.
Table 5 shows an analysis of throughput (packets) time.
Figure 25 shows the throughput (Kb/s) of the proposed and existing methods by varying nodes. For 20 nodes, the throughput of the proposed method is 930, whereas the throughputs of the existing SRABC, HEDAR, and SETORD methods are 680, 500, and 400, respectively. For 40 nodes, the proposed method’s throughput is 1230, where-as the existing methods’ throughputs are 980, 850, and 700, respectively. For 60 nodes, the proposed method’s throughput is 1640, whereas the existing methods’ throughputs are 1300, 1150, and 950, respectively. For 80 nodes, the proposed method’s throughput is 2210, whereas the existing methods’ throughputs are 1900, 1700, and 1550, respec-tively. For 100 nodes, the proposed method’s throughput is 2900, whereas the existing methods’ throughputs are 2600, 1980, and 1750, respectively. Thus, the proposed method improves throughput compared to the preceding methods.
Table 6 shows the analyzing nodes of the proposed and existing methods. For Node 100, the existing SRABC method node is 2600, which the proposed method improves to 300. For Node 100, the existing HEDAR method node is 1980, which the proposed method improves to 920. For Node 100, the existing SETORD method node is 99.1, which the proposed method improves to 0.7.
Figure 26 shows the training and testing accuracy of the proposed and existing methods for different epoch values. In the training stage, the accuracy of the proposed method increases up to 50 epochs and after the 50th epoch, there is a sudden rise in accuracy up to the 100th iteration, and after that, a rise to the 150th epoch. After an epoch value of 200, and from 250 and 300, the training accuracy remains constant for the proposed methods. Also, during testing accuracy level, after the 50th epoch there is a gradual rise in accuracy up to the 100th epoch, and after that, a sudden rise up to 200 epochs. After an epoch value of 200, and from 250 and 300, the testing accuracy re-mains constant for the proposed methods. Therefore, the proposed approach is effec-tive as, with an increase in repetitions, accuracy likewise rises to produce better out-comes.
Figure 27 shows the training and testing loss of the proposed methods for different epoch values. In the training stage, the loss of the proposed method decreases up to 50 epochs, and after the 50th epoch, there is a sudden reduction in loss value. After an epoch value of 100, and from 150 to 200, the loss value shows a sudden drop, and after that, at epoch values of 250 to 300, the loss value remains constant. So, the proposed method demonstrates better outcomes than comparing to training and testing loss value.
Figure 28 shows the comparison of the proposed and existing methods, with four videos for training and one for testing. For a pause time of 20, the proposed method achieves an average end delay of 0.06 s, compared to the average end delays of the ex-isting SRABC, AODV, DSR, and OLSR methods, which are 0.11, 0.21, 0.199, and 0.09 s, respectively. For a pause time of 60, the proposed method’s average end delay is 0.134 s, compared to the existing methods’ average end delays, which are 0.16, 0.189, 0.22, and 0.154 s, respectively. For a pause time of 100, the proposed method’s average end delay is 0.174 s, compared to the existing methods’ average end delays, which are 0.2, 0.23, 0.24, and 0.21 s, respectively. Thus, the existing methods have more processing time than the proposed method.
Figure 29 shows the comparison of the proposed and existing methods with five videos for training and two for testing. At a time of 200 seconds, the proposed method achieves a packet-delivery ratio of 94.3 s, compared to the packet-delivery ratios of the existing SRABC, AODV, DSR, and OLSR methods, which are 92.7, 86, 72.5, and 84 s, respectively. For a pause time of 400, the proposed method’s packet-delivery ratio is 96.2 s, compared to the existing methods’ packet-delivery ratios, which are 95, 87, 76, and 88 s, respectively. For a pause time of 800, the proposed method’s packet-delivery ratio is 98.9 s, compared to the existing methods’ packet-delivery ratios, which are 97.5, 93.5, 88.2, and 94 s, respectively. For a pause time of 1000, the proposed method’s packet-delivery ratio is 99.5 s, and the existing methods’ packet-delivery ratios are 98.7, 96, 92, and 97 s, respectively. The existing methods involve network expansion, causing congestion and poorer network performance. Also, the proposed method produces a better result.
Figure 30 shows the comparison of the proposed and existing methods with six videos for training and three for testing. For 20 nodes, the proposed method achieves a throughput of 932 s, compared to the throughputs of the existing SRABC, HEDAR, SETORD, and OLSR methods, which are 682, 502, 402, and 902, respectively. For 40 nodes, the proposed method’s throughput is 1232, compared to the existing methods’ throughputs, which are 982, 852, 702, and 1002, respectively. For 80 nodes, the pro-posed method’ throughput is 2212, compared to the existing methods’ throughputs, which are 1902, 1702, 1552, and 1502, respectively. For a pause time of 100, the pro-posed method’s throughput is 2902, compared to existing methods’ throughputs, which are 2602, 1982, 1752, and 1802, respectively. The existing models need a lot of data to be trained compared to the proposed method.
Table 7 shows the values of addi-tional video training and testing by varying time and nodes.