## 5 Simulations and Discussions
### Simulation Setup  
To evaluate the effectiveness of the detection and protection framework proposed in this paper, we use a computer to simulate the ground station (digital twin). At the same time, we build a satellite network simulation scenario based on the Iridium constellation [13], which is widely used in the literature, and regard it as the physical twin. The satellite network parameters are shown in Table 5. In this paper, the region with a latitude higher than 70 degrees is set as the polar region. In polar regions, the relative speed between satellites in different orbits is too fast to build stable inter-satellite links in adjacent orbits. Therefore, we only consider inter-orbital links (IOLs) in the same orbit in the polar region. In this paper, the STK 11.6 simulation tool is used to obtain the propagation delay of communication links and satellite position information. In addition, we assume that the sensor can provide correct data about the satellite network. We also assume that the secure communication protocol can ensure the correctness of data transmission. At the same time, we import the satellite network orbit data files obtained from an STK simulation into the ONE v1.6.0 simulator, which is an open-source software developed by Nokia (Finland) Research Center, to simulate network communication scenarios. The scenario randomly selects nodes to send 50 kB\(-\)1 MB sized packets to other nodes and the packets are generated at the rate of one per 1-3 s. We set 10% of nodes as SHs or GHs, and evaluate the SH or GH detection methods, respectively.  
The routing discovery, path planning, fault injection, and detection experiments were performed on a computer with the following configuration: Ubuntu 16.04 (64-bit) operating system, i7-8550 CPU, and 8 GB of RAM. We use LFI to conduct fault injection experiments. The routing programs are written in the C programming language, and the fault injection result statistics and fault detection algorithms are implemented in Python 3.7.9. In this scenario, the satellite network uses the classic link-state-oriented routing protocol DHRP [31]. The main behaviors of the satellites in different routing phases are as follows:  
(a) Route discovery phase  
In the route discovery phase, to reduce the number of broadcasts and update the link state of the whole network as quickly as possible, DHRP sets up a plane speaker (PS) at each orbit plane to collect the LSAs of satellites in the plane. The PSs construct link-state  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter Description** & **Value** \\ \hline Number of satellites & 66 \\ \hline Number of orbital planes & 6 \\ \hline Number of satellites per orbit & 11 \\ \hline Orbital altitude (km) & 778 \\ \hline Orbital inclination (\({}^{\circ}\)) & 86 \\ \hline Adjacent orbit equatorial longitude difference (\({}^{\circ}\)) & 31.6 \\ \hline Adjacent satellite latitude difference (\({}^{\circ}\)) & 16.4 \\ \hline The polar region boundary latitude (\({}^{\circ}\)) & 70 \\ \hline Number of ISLs for each satellite & \(\leq\)4 \\ \hline \hline \end{tabular}
\end{table}
Table 5: The network parameters of the Iridium constellation.  
advertisement sets S-LSAs. The PSs of different orbits also exchange S-LSAs to obtain the overall link states of the satellite network, build a routing information base (RIB), and build a link delay adjacency matrix. The main program at this stage is the Build_RIB described in Table 2.  
In the route planning phase, the PS takes the link delay adjacency matrix built in the route discovery phase as the input parameter and uses [PERSON]'s Shortest Path algorithm (DSP) algorithm to calculate the routing tables for the satellite nodes in this orbit. The satellite nodes can transmit data after acquiring the routing table. The main program at this stage is the DSP described in Table 2.