# Efficient Resource Scheduling for Multipath Retransmission over Industrial WSAN Systems
## 4 The Proposed Scheduling
### Simulations  
Our simulations are presented to demonstrate the schedulability and effectiveness of our scheduling. The algorithms have been written in C language, and the simulations have been performed on a Windows machine with a 3.1-GHz Inter Core 3 processor. The following metrics are used for performance analysis: (a) Schedulable ratio is measured as the percentage of test cases for which a scheduling policy is able to schedule all transmissions. (b) Scheduling time is the total time required to successfully make a complete hyperframe for all transmissions. (c) Average normalized bandwidth is the ratio between the number of allocated resources and the total resources within a hyperframe after scheduling. In simulations, we assume that every node generates a packet periodically and sends it to the gateway along the routing graph. A packet is regarded as a flow without aggregation. The period is randomly selected in the set \(\{p_{m}\cdot 2^{a}\mid\forall a\in[0,b]\}\), where \(b\) is the maximum exponent. A packet belonging to a fourth-hop node needs at most 22 transmissions using the scheduling of multipath scheme; thus, three values of \(p_{m}(0.25\;\mathrm{s},0.5\;\mathrm{s},1\;\mathrm{s})\) are tested in the simulations. Figure 6 shows the schedulable ratio of the three scheduling policies with different parameter configurations. The number of nodes ranges from 50 to 100. We randomly generate 8000 cases for each node quantity and use the three algorithms to schedule the generated topologies separately. The number of available channels is set to be the maximum, 16, for a better comparison, since several cases using less channels are hardly scheduled with the existence of diverse periods. In Figure 6a-d, \begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Type of Topology**} & \multicolumn{4}{c}{**Probability**} \\ \cline{2-5}  & **1 st Hop** & **2 nd Hop** & **3 rd Hop** & **4 th Hop** \\ \hline Tp1 & 0.5 & 0.3 & 0.1 & 0.1 \\ Tp2 & 0.5 & 0.2 & 0.2 & 0.1 \\ Tp3 & 0.4 & 0.3 & 0.2 & 0.1 \\ Tp4 & 0.3 & 0.3 & 0.3 & 0.1 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: The proportions of different types of topology. the three algorithms, which execute on each type of topology with \(p_{m}=1\) s and \(b=0\), can successfully schedule the majority of graphs. Obviously, the schedulable ratio drops in pace with the increase of nodes; however, we can see that our proposed scheduling is almost unaffected with these configurations. With the period shortened and diversified, the number of schedulable graphs decreases dramatically. Figure 6e-h and Figure 6i-l show the results under the period configurations of \(p_{m}=0.5\) s, \(b=1\) and \(p_{m}=0.25\) s, \(b=2\), respectively. They clearly indicate that the schedulable ratio of CEM-RM is higher than that of M-LLF and M-RM. Especially, increasing the number of nodes makes the gaps between CEM-RM and the others even bigger. Figure 6: A comparison of the schedulable ratios of the three algorithms with different periods and topologies. The execution time of a scheduling can affect the performance of network formation and rescheduling; thus, we have measured the average run time of the three algorithms. Each test with a different number of nodes and algorithms includes 100 successfully scheduled graphs. To guarantee that the tested graphs are more schedulable, we set \(p_{m}=0.5\) s and \(b=1\) in all tests. As displayed in Figure 7, the markers represent the average time of different algorithms with different numbers of nodes and the lines show the trend of scheduling time as the number of nodes is increased. We can obtain that the average execution times of M-LLF and M-RM are lower than 1264 ms, while the time of our proposed scheduling is lower than 371 ms. The results indicate that CEM-RM is better for the performance improvement of network formation or rescheduling. Moreover, Figure 8 shows the average requirement of the wireless bandwidth for our scheduling and for the others.