## 4 Proposed Routing Scheme
### Distributed Detour Routing Scheme
In particular, for the highest failure rate, the proposed scheme produces only 0.48% of the communication overhead compared to OPSPF. The number of ISLs present in the constellation influences communication overhead. The number of flooding messages in the proposed algorithm is determined by the value of \(N\) in Equation (7). Additional experiments were conducted to determine the extent of the difference in flooding messages in constellations with more satellites than the Iridium constellation. Therefore, to assess the impact on communication overhead, we varied the number of satellites comprising the constellation. The number of satellites chosen to form the constellation was based on existing commercial satellites, specifically those with a polar constellation configuration similar to that of the simulation environment. Each constellation consisted of \(8\times 16\), \(6\times 58\), and \(12\times 49\) satellites for Telesat, SpaceX, and OneWeb, respectively [26]. Table 2 shows the amount of overhead for different LEO constellations. In each constellation, the link failure rate was based on the median value of 5% used in the previous experiments. Both OPSPF and DTDR flood information went to available links. Consequently, with an increase in the number of ISLs composing the constellation, the communication overhead is two to three times higher. While the proposed scheme experiences a larger rate of increase in overhead as the number of satellites increases compared to the others, the absolute amount of communication overhead remains significantly lower. Compared to OPSPF, with the proposed scheme, the communication overhead is reduced by approximately 3.38%. This means that the proposed scheme becomes more effective in reducing communication overhead as the number of constellations increases. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Constellation**[26] & **OPSPF**[7] & **DTDR**[11] & **Proposed Scheme** \\ \hline Telesat (128) & 1465 & 690 & 98 \\ SpaceX (348) & 12,525 & 9749 & 6139 \\ OneWeb (588) & 1,156,064 & 838,464 & 39,082 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: The amount of communication overhead for flooding by constellation. Figure 7: Average communication overhead from flooding according to link failure rate. ### End-to-End Delay in Routing Path Comparison

The end-to-end delay was compared for the three scenes in case of link failure. In this study, the ISL length was the only routing metric considered. Therefore, the propagation delay only includes end-to-end delay and is calculated as follows:

\[d_{h}=\frac{e_{\text{len}}}{c}, \tag{8}\]

where \(d_{h}\) is the propagation delay; \(e_{\text{len}}\) is the distance between the two satellite nodes; \(c\) is the speed of light in a vacuum. Then, the end-to-end delay \(d_{p}\) in this simulation is calculated by

\[d_{p}=\sum_{i=1}^{H_{c}}d_{hi}, \tag{9}\]

where \(H_{c}\) is the hop count of the path and \(d_{hi}\) is the delay of the \(i\)th hop with a path. Figure 8 shows the average end-to-end delay based on the link failure rate. It is observed that OPSPF outperforms the proposed scheme and DTDR in end-to-end delay. In all link failure rates, OPSPF is 10 ms faster than the other algorithms. This is because the link-state routing scheme maintains the network in an up-to-date state through periodic information exchanges and flooding across the entire network. The flooded link information invokes the routing table to update the detour failure links. The proposed scheme and DTDR use a hop-by-hop routing scheme, with only the direction of the next hop determined at any given moment. Consequently, link failures cannot be anticipated in advance, which leads to additional detour delays. However, as shown in Figure 8, the proposed scheme has a 1 ms lower end-to-end delay compared to the DTDR approach. Figure 9a further explains the results in Figure 8 showing that the increase in link failure rate results in the detour path of the proposed algorithm having a lower end-to-end delay.