## 4 Algorithm Design
### Fast Rerouting Mechanism
We utilize satellite constellations of sizes \(10\times 10,20\times 20,30\times 30,40\times 40\), and \(50\times 50\) to investigate the impact of different constellation densities on the performance of the routing algorithm. The simulation results are shown in Figure 9.

From the perspective of path stability, the stability obtained by the _Shortest Path_ algorithm decreases as the constellation density increases. In contrast, the path stability obtained by the MOLM algorithm does not exhibit a monotonic decrease but rather shows two significant peaks at constellation densities of \(20\times 20\) and \(30\times 30\). In terms of latency, all three strategies adhere to the rule that \"higher constellation density leads to lower path latency\". Therefore, this implies that in certain constellations with specific simulation characteristics (orbit height of 1200 km, inclination of 60 degrees, and constellation density of \(20\times 20\) or \(30\times 30\)), when network congestion occurs, the new paths obtained using the MOLM algorithm can achieve a good trade-off between stability and latency. ### Evaluation of FRR-BP

We integrate the MOLM algorithm with a Fast Reroute mechanism based on backup paths. After using multi-objective simulated annealing to select continuous neighbors for replacing congested nodes, if any node along the newly selected path experiences a failure, we promptly initiate the Fast Reroute based on backup paths. When establishing backup paths, two considerations are essential: first, avoiding the failed node, and second, steering clear of congested nodes to prevent potential congestion on the newly created backup path. Additionally, if the newly generated backup path still encounters network congestion with other existing traffic paths, we further employ the MOLM algorithm to alleviate network congestion. We consider the time required to generate the final feasible backup path as the evaluation metric for rerouting. Tests were conducted on constellations with densities of \(10\times 10,20\times 20,30\times 30,40\times 40\), and \(50\times 50\) under both +Grid and Ideal networking meth

Figure 8: Constellation topology with different densities under the +Grid scheme. Figure 4:0 The impact of constellation density on algorithm performance. ods. In general, higher constellation density leads to increased traversal time, resulting in longer rerouting times. The test results, as shown in Figure 10, indicate that under both +Grid and Ideal networking methods, higher constellation density corresponds to longer backup path reconstruction times. In the +Grid scenario, even with a constellation density of 50 \(\times\) 50 (2500 satellites in total), the reconstruction time remains within 1000 ms, which aligns with expectations. However, in the Ideal scenario, where there are no restrictions on the number of connections between satellites, the increase in connection density with rising constellation density leads to a rapid increase in backup path reconstruction time. This is a normal occurrence. Nevertheless, at lower constellation densities, the backup path reconstruction time remains relatively low, within 1000 ms.

## 6 Conclusions

Based on the predictability of LEO satellite networks, we propose a novel congestion resolution method named MOLM. Other congestion resolution methods focus on reducing path latency or increasing throughput while addressing network congestion. In contrast, MOLM considers path stability because it affects the cost of path switching and routing table maintenance. The main advantage of our proposed algorithm over others lies in simultaneously addressing network congestion, enhancing path stability, reducing path switching costs and routing table maintenance costs while maintaining relatively low latency costs. The approach constructs a continuous neighbor set when updating paths, consisting of nodes that can establish sustainable connections with both the predecessor and successor of congested nodes, thereby enhancing path stability.