# Routing Strategies for Isochronal-Evolution Random Matching Network
## 4 Two Routing Strategies
### Planning Algorithm for the LHPMD
We designed eight scenarios to simulate, as tabulated in Table 1. There were differences in the routing strategy, the number of vertices \(\Theta\), and the delivery capability \(C\) among the eight scenarios. We set the values of \(C\) by referring to [33; 36]. We performed simulations for each scenario with different packet generation rate \(R\) values in order to investigate the value of \(R_{C}\). The range of \(R\) was set as \(\{1,2,\cdots,25\}\). That is, 25 simulations were conducted for each scenario. Each simulation lasted for 2400 time steps, i.e., 1200 slots. One slot was set as 3 s. The planning time window \(\Gamma\) was set as 20. We created 60,000 random pairs of source and destination, which were chosen sequentially as the SVF and the DVF of each newly generated packet in each simulation. We generated an IERPMN with 400 vertices and an IERPMN with 30 vertices to conduct traffic dynamics simulations, which are shown in Figures 4 and 5. In these two figures, we use numbers rather than symbols to signify vertices. The color of an edge indicates the slot in which it occurs. If the edge occurs in more than one slot, only the first one is considered. These two IERPMNs are based on two real-world networks. The IERPMN with 30 vertices was used to simulate BDS [6]. The IERPMN with 30 vertices was used to simulate one shell of the SpaceX Starlink constellation [37]. In each slot of the IERPMN with 30 vertices, 15 edges were constructed using the method presented in Section 1. The generation of the IERPMN for a slot was independent of those for the other slots. \begin{table}
\begin{tabular}{c c c c} \hline
**Scenario Number** & **Routing Strategy** & \(\Theta\) & \(C\) \\ \hline
1 & LDPMH & 30 & 1 \\
2 & LHPMD & 30 & 1 \\
3 & LDPMPH & 400 & 1 \\
4 & LHPMD & 400 & 1 \\
5 & LDPMH & 30 & 10 \\
6 & LHPMD & 30 & 10 \\
7 & LDPMH & 400 & 10 \\
8 & LHPMD & 400 & 10 \\ \hline \end{tabular}
\end{table} 
Table 1: Setup in scenarios. ### Simulation Analyses

#### 5.2.1 Simulation Analyses of the Critical Packet Generation Rate

The order parameter \(H\) versus \(R\) for eight scenarios is illustrated in Figures 6 and 7. In this paper, \(R_{C}(1)\) denotes \(R_{C}\) in Scenario 1, and so on. By comparing the curves of Scenario \(g_{1}\) and Scenario \(g_{1}+1\) (\(g_{1}\in\{1,3,5,7\}\)) in Figures 6 and 7, we found that the value of \(R_{C}\) in a scenario using the LDPMH routing strategy is less than that of \(R_{C}\) in a scenario using the LHPMD routing strategy under the same conditions. Thus, it is easier for the

Figure 4: The IERPMN with 400 vertices. The unit of the heat map below is the slot. The numbers in the network diagram above indicate the vertices of the IERPMN. A line between two numbers in the network diagram above indicates the edge connecting these two vertices. Figure 5: The IERPMN with 30 vertices. The unit of the heat map below is a slot. The numbers in the network diagram above indicate the vertices of the IERPMN. A line between two numbers in the network diagram above indicates the edge connecting these two vertices. LDPMH routing strategy to cause traffic congestion in an IERMN than it is for the LHPMD routing strategy. The reason for this phenomenon is that the planning costs of the LDPMH and LHPMD are different. An LDPMH is planned at the expense of a larger spatial length so that the LDPMH may have the shortest temporal length. On the contrary, an LHPMD is planned at the expense of a larger temporal length so that the LHPMD may have the shortest spatial length. Therefore, the LDPMH is assumed to contain more vertices than the LHPMD. If all paths of all packets contain quantities of vertices, each vertex has to transmit a large number of packets. The high load of vertices must induce traffic congestion. Hence, \(R_{C}\) by the LDPMH routing strategy is less than \(R_{C}\) by the LHPMD routing strategy. #### 5.2.2 Simulation Analyses of the Number of Delivered Packets

A total of 2,419,434 packets were delivered through \(8\times 25=200\) simulations in 8 scenarios.