Computer Science
Computer Science-2021.gz:143315
Computer Science
51aadc87e4a5ea0ba023880641973efd6148e542
Developing and experimenting with LEO satellite constellations in OMNeT++

In this paper, we present our work in designing and implementing a LEO satellite constellation simulation model1 within OMNeT++ and INET, which is validated by comparing the results with existing work. Our model builds upon the fundamentals of the Open Source Satellite Simulator (OS$^3$), which was ported to INET 4.3. We describe how the model was integrated on top of the INET and ported OS$^3$ Framework. We then experiment with the simulation model to demonstrate its viability in simulating LEO satellite constellations. This involved simulating both outdated and more recent satellite constellations, using FCC filing information, to validate latency results.


Starlink
There are currently 1,630 LEO satellites orbiting the earth which are all part of SpaceX's vast plan for global high-speed internet access. In 2018 SpaceX had their proposal for Starlink, the global LEO satellite constellation which is already making monumental progress, accepted by the US Federal Communications Commission (FCC) [9]. With nearly 1,700 satellites already deployed by SpaceX, global internet coverage is highly likely to arrive within the decade.
SpaceX initially set out with the intention of deploying 4425 satellites with different deployment stages, each stage promising high-speed internet access to specific areas. Since this initial intention, the US FCC has approved further 42,000 Starlink satellites, which will operate at lower altitudes from 328 to 580 km in comparison to the previous 1,100 to 1,325 km range [3]. As noted by the FCC application submitted by SpaceX [3], this altitude change reduce the potential propagation delays between ground stations and satellites, as well as reduce the debris collision risk that the constellations presented [13]. Collisions are not a significant consideration of the simulation model, as even though they are vital, the model focuses on the LEO constellations strictly from a network perspective.
Due to the public knowledge provided by SpaceX and research undertaken in comparison to other private companies (such as Telesat [6] and OneWeb [8]), we used Starlink as the primary resource for the specification behind the LEO satellite constellation simulation model. FCC filings for Starlink [9] provided sufficient information to make a realistic model.

Open Source Satellite Simulator -OS 3
To simulate a dynamic constellation of satellites the mobility of a node is vital. Many aspects such as propagation delay, signal strength and interference are all impacted by the distance between nodes, making mobility the foremost step. The OS 3 framework provides suitable mobility modules that allow the importation of current satellite information into OMNeT++ and INET. These mobility models use the established SDP4 and SGP4 [19] mathematical algorithms to accurately simulate the positions of a satellite at a given time. We ported the outdated OS 3 framework for it to work appropriately with the current INET version 4 2 . These changes include, adapting the ground station mobility model LUTMotionMobility from extending the INET 2.5 MobilityBase model to the more current StationaryMobility model and adapting the satellite mobility model SatSGP4Mobility to extend the current INET MovingMobilityBase rather than MobilityBase model. The primary porting efforts were focused on porting only the mobility models of OS 3 into the latest OMNeT++ and INET. OS 3 also includes a graphical user interface for easy simulation, but this does not allow the integration of new models and was consequently not the focus.

LEO Satellite Constellation Simulation Model
Our ground-station and satellite models both extend the INET WirelessHost model. This model defines a host with wireless capabilities which is compatible with INETs vast array of models and protocols, providing sufficient components that allow an accurate simulation of the TCP/IP stack in the process. Ground-to-satellite phased array beams and inter-satellite links are extremely complex, therefore many factors can be considered when transmitting and receiving signals within the simulation model. Like existing work [16], the initial simulation model and experiments predominately focus on latency which is only limited by the topology and speed of light. As a consequence of being built within the OMNeT++/INET framework, increasing the fidelity of the simulation model is very straightforward as additional modules can be integrated without inconvenience. By using the WirelessHost model, the additionally developed models defined below are simply integrated, through either the NED language or specified within the network INI file.
Physical Layer To keep up with the dynamic mesh of satellites, we decided that the INET UnitDiskRadio and UnitDiskRadioMedium models were suitable 3 . These INET physical layer models provide fast and predictable physical layer behaviour, which is a perfect candidate for a large scale moving network. The UnitDiskRadio model is based on three parameters, a communication range, interference range and a detection range. The interference of the model is ignored as this is not relevant to the fidelity of the initial simulation model. We implemented new INET physical layer models that use the longitude, latitude and altitude of the OS 3 mobility models. This includes new UnitDisk models (SatelliteUnitDiskTransmitter and SatelliteUnitDiskTransmission) and a propagation model (SatellitePropagation). The OS 3 mobility modules map only the longitude and latitude (altitude is ignored) onto the OMNeT++ X, Y and Z coordinates, most likely for visualisation purposes. There are many issues with projecting the Earth onto a two-dimensional plane [14] therefore by creating new INET models that only use the longitude, latitude and altitude, the calculation of distance for determining propagation delay between nodes is much more accurate.
Routing We implemented a new INET configurator module, SatelliteNetworkConfigurator, which follows the IPv4NetworkConfigurator model in INET. The IPv4NetworkConfigurator works in INET as follows: 1) A graph is built representing the current network topology, 2) IP addresses are assigned, 3) Link and node weights are set, 4) Dijkstra's Shortest Path Algorithm is run from each network node, where all the routes are determined, 5) The routing tables for each node are generated. The SatelliteNetworkConfigurator has been created with the intent to run throughout the simulation, thus a new method (SatelliteNetworkConfigurator::reinvokeConfigurator ) ensures that the allocated memory for the past topology is released, and then goes through the configuration steps again to rebuild a new topology.
Step two is ignored once the configuration is reinvoked, as the IP addresses have already been assigned, and it would be redundant to reassign them. The frequency that the configurator recreates a new topology is determined by the INI file parameter updateInterval. The SatelliteNetworkConfigurator also filters links within step 3, to ensure that links are valid. This includes whether or not satellites are compatible for inter-satellite links or if a ground-satellite link satisfies the minimum elevation angle stated within the Starlink FCC filings [3]. Figure 1 shows how altering the updateInterval parameter impacts the latency between two ground-stations using the simulation model. All of the experiments are tested on a constellation of 660 satellites with inter-satellite links, with pings being sent between Washington DC to Frankfurt. The constellation mirrors the 2018 FCC specification [2], where there is 66 satellite per plane with an inclination of 53 • . Figures 1c and 1d both indicate a slight degradation of results when there is a lower granularity of the updateInterval parameter. Despite the minor loss in accuracy, the results still show that a lower granularity is competent in showing the patterns of RTT changes due to the paths moving to an alternate orbital plane. The runtime of Figure 1a shows that the one-second update interval is noticeably slower in comparison to the other experiments. With larger constellation sizes of 1500 satellites, the runtime will be even larger, with the configurator taking up to a minute to reconfigure the routes.   of the simulation model. As the size of the satellite constellation increases, the SatelliteNetworkConfigurator will need to build an even larger graph representing the network topology. This results in a higher routing complexity and larger routing tables. Extremely large constellation sizes can take the simulation model up to five hours of real-time to simulate five minutes of simulation time with the SatelliteNetworkConfigurator routing every 1 second using a 3.2 GHz Intel Core i7 processor. The run time of the simulation drastically decreases when increasing the update interval of the routing, at the cost of varying levels of accuracy loss (see Figure 1) depending on the granularity.
Removing the TLE data set dependency A large limitation of the simulation model is that the OS 3 satellite mobility models require existing satellite data (Two-Line Element sets).
However, this presents many problems such as the inability to simulate unimplemented/experimental satellite constellations and the need to constantly update the TLE data files as more satellites are deployed. Another issue is that the satellite data provides no information on inter-satellite connectivity, making implementing the laser links within the simulation model difficult. We decided that to be able to replicate existing inter-satellite latency experiments as well as to enable the capability of exploring any future constellation, a new Norad module was implemented that does not depend on two-lined element set data.
This module instead automatically generates specific orbital elements depending on a combination of Keplerian elements and constellation characteristics that are specified within the network INI file. A phase offset is also considered [16], which is the offset between satellites on adjacent orbital planes to prevent collisions. This value is included within the NoradA module to allow more precise satellite constellation deployments if required.
For ease of use within the developed simulation model, the original OS 3 Norad module was split into three different modules. This includes the module interface INorad, and two submodules NoradA and NoradTLE. NoradTLE is identical in implementation to the original OS 3 Norad module, where existing satellite data is used to propagate the orbits of the satellites. The NoradA module demonstrates the new automatic generation implementation, where different orbital parameters can be specified by the NED language or INI file.  Inter-Satellite Links As each satellite is given an index position from 0 to the maximum satellite number specified, which is used to determine its orbital plane and position, it is possible to determine inter-satellite links. Starlinks FCC filings [3] state that each satellite will have four inter-satellite links. [16] notes that for the best connectivity, satellites will most likely connect to the two satellites on either side of its current orbital plane, and the two adjacent satellites that are on neighbouring orbital planes. As each satellite has an index within the simulation model, it is extremely easy to determine the four laser links of a satellite. A method was created within the NoradA class (NoradA::isInterSatelliteLink )which determines whether, given a satellites index, it is compatible as an inter-satellite link. This method is used during the link filtering within the SatelliteNetworkConfigurator so that any non-compatible inter-satellite links are disabled.

Experiments
To validate the simulation model we conducted a variety of experiments, mirroring existing work [16,17,12]. INETs PingApp module will be used to simulate ping between two ground stations so that the round-trip time between two locations can be examined and compared to existing work results. The PingApp will generate ping requests from an initial ground station to another ground station every 500ms throughout the simulations.

Experiment 1
The first simulation that we evaluated mirrored the specification defined in [17]. The constellation involves 66 satellites per plane, with a total of 24 planes, which are generated using the NoradA module. There are 14 ground relays used in this simulation, with two being situated on ships between the source and destination; London and New York. The inter-satellite link experiment will update the mobility and routing every five seconds to reduce the run-time. This experiment will simulate 120 minutes of simulation time.  The results validate the simulation model by accurately recreating the results described in [17]. The ground relays that are only using 6 orbital planes provide varying latencies of 50-63 ms in comparison to the current Internet's 73 ms RTT [4]. The more planes, the lower the latencies with 12 and 24 planes rivalling an ideal Great Circle optical fibre [1] 4 . The results also show that the inter-satellite links perform better than any of the comparisons, with a mean RTT of 43 ms. The variations of round trip times are a result of the shortest path between London and New York changing to a different orbital plane as a satellite becomes inaccessible, or a better path is emerged due to a new satellite becoming within range. As evident in the results more satellites lower the chances of a route becoming inaccessible due satellites going out of range, as well as providing potentially better paths that the lower constellations sizes were unable to provide. With ground relays, there are less potential routes depending on the amount of relay stations that are used, leading to more drastic fluctuations in RTT in comparison to inter-satellite links. Figure 5 depicts another simulation example with information used from [16] and [17]. This simulation uses the TLE data sets of 1300 of the current Starlink constellation, demonstrating the NoradTLE module in contrast to the previous simulation. The simulation portrays how two different sizes of satellite constellations affect the RTT between New York and Seattle using 10 ground relay stations that replicate the positions of existing Starlink control centres [10]. The results show that using the NoradTLE module leads to less predictable fluctuations of RTT, which is due to SpaceX strategically placing its satellites rather than simply filling out an orbital plane at a time. This makes gaps within an orbital plane much more likely, causing more variations in RTT as paths will frequently shift between orbital planes. From 700 to 1300 satellites, the RTT begins to stabilise as there are more shortest paths available and less potential gaps within an orbital plane, which will continue for future Starlink deployments until the first phase is complete.

Experiment 2
To test the capabilities of the simulation model, a completely uniform constellation with each orbital plane having an inclination of 90 • was simulated, shown in Figure  6. This simulation was juxtaposed with the results shown in [12]. The simulations consist of constellation sizes of N 2 where there are N orbital planes with N satellites per plane. Three constellation sizes will be evaluated where N = 25, 30, 35. A constellation size of 20 2 was not tested unlike [12] as the minimum elevation angle specified by FCC filings [3] makes them infeasible for solely inter-satellite links. The simulation also differs by using a mean altitude of 550 km for satellites to reflect recent FCC filings [3]. The results demonstrate the advantages of a larger constellation size, with latencies becoming less variable as the sizes increase due to the reasons mentioned in the prior experiments.

Conclusions and Future Work
In terms of the future of the simulation model itself, future work would entail optimising the routing of the model. [17] uses a similar Dijkstra's Algorithm routing computation and presents many methodologies in reducing the time complexity of the algorithm. SpaceX plans to have a constellation of 4,408 satellites in its initial phase [18] which will be progressively demanding for the routing computation as the phases advance, making the complexity of the routing computation crucial for simulating later deployments. The simulation model uses the simplistic Unit Disk Radio model described in Section 4, which does not model complex satellite characteristics such as modulation and bit error rate. Future work could also involve adapting the INET APSK radio model for more realistic behaviours which was not the focus of the prior simulation experiments.
Using the developed simulation model, many research areas can now be addressed. The next major step will be to extend and use the simulation model to evaluate the performance of existing data transport protocols. This includes an evaluation of protocols such as TCP [15], NDP [18] and SCDP [11]. Due to the high fluctuations in latencies, delay-based congestion control may be insufficient, which will also be evaluated using the simulation model.