LEOCN: Real-time and complete network simulation framework for LEO constellation networks 1

1. Introduction

Low Earth Orbit (LEO) constellations such as Starlink [23] are groups of satellites that are below the altitude of 2,000 km, working together as a system. With the development of carrier rockets, thousands of LEO satellites pour into space, and the age of LEO constellation networks has been coming up.

As one of the most promising fields, the LEO satellites have the characteristics of high bandwidth and low latency, which are able to support more services than medium or geostationary Earth orbit (MEO/GEO) satellites. Delay-sensitive services, such as online games and real-time communication, are more fitted with the LEO network. The LEO satellite networks can be applied to sparsely populated areas that are challenging to cover by the Internet, such as deserts, forests, and oceans. Compared to conventional networks, the one based LEO constellations can bring lower costs than the fiber-optic connections, especially for ships and airplanes that are hard to use terrestrial networks.

Although the LEO constellation network has caught the eyes of the whole world, several challenges still stand in the way of it being used on a wide enough scale to replace the use of fiber networks as a primary linking method. The speed of LEO satellites reaches around 27,000 km/s [2], at which the LEO satellites circle the planet every 90 minutes. The high velocity severely affects the topology of the LEO constellation network, making the topology extremely unstable.

The instability of the topology nevertheless leads to more questions. Zhang et al. [42] proposed that there is a great need to study the handover strategies for the giant LEO satellite networks, like which satellites a user terminal needs to connect to during a handover. Therefore, the balance among handover delay, probability of erroneous handover, resource utilization need us a long way to go. On LEO constellation networks, conventional routing algorithms have to take much traffic for updating and synchronizing strategies because of frequent alteration of networks such as Open Short Path First (OSPF). The shortest path routing algorithm has large overhead [9] with the problem of instability, and it loses sight of trade-off against network preferences such as delay and bandwidth due to the instability problem, and it loses sight of the trade-off between network preferences such as latency and bandwidth [21]. The aforementioned challenges seek an appropriate LEO constellation network simulator to analyze and address them. In this paper, we propose a real-time and complete network simulation for the LEO constellation, LEOCN, to accelerate research.

LEOCN mainly focuses on the real-time and completeness of the network, which are missing from previous frameworks [10,15]. The real-time nature gives researchers the freedom to manipulate nodes and interact with the platform, and users can assign tasks or change system settings in real-time to observe system outcomes. There are nine task templates in LEOCN for providing examples to construct new tasks .Completeness in constellation networks digs up more unexpected phenomena that are possible in the real world. LEOCN has an analog module to simulate traffic that could be found on a traditional network based on the completeness of the framework. Mininet [22] plays a crucial role in ensuring these features, such as it provides the support of the data link layer and above, and possesses properties such as bandwidth, latency, jitter, and loss rate that make the network more realistic.

LEOCN consists of six modules, each of which focuses on different functional modularity and provides a diverse set of features designed for diverse objectives.

To summarize, we have the following contributions:

Numerous researchers prefer the Systems Tool Kit (STK) [31] due to its substantial tool package. STK also supports the deployment of LEO satellite constellations. However, it is not very excellent at network experiments. LEOCN makes up for this shortcoming. We hope that more and more researchers will focus on both LEO constellations and networks.

The rest of this paper is organized as follows. In Section 2, we describe the background of LEO and the tools of our platform. In Section 3, we describe the related work on LEO constellation simulation. In Section 4, we proposed the architecture of LEOCN. Then we introduced concrete implementation of LEOCN, especially in terms of topology, mobility, routing algorithms and visualization in Section 5.The results and evaluation of simulation for the simulation utilization, memory usage and network latency are shown in Section 6. In Section 7, we discuss what has been done and what is to come, and finally, we conclude the paper in Section 8.

2. Background

The Low Earth Orbit(LEO) satellite, with altitude ranging from 250 km to 2,000 km above the Earth’s surface and orbital periods ranging from about 84 to 127 minutes, has been developing in the 5G period [7,11] and is expected to play a key role in providing ubiquitous Internet and communications services of 6G period in the future. Compared to GEO and MEO satellites, LEO satellites have the advantages of lower emission cost [17], higher network capacity, higher resolution of Earth observation and better signal quality reception, and alleviate the problem of Antenna angle, polar coverage and time delay with regard to communication. For instance, recent work shows that it could offer lower latency than not only present fiber infrastructure, but also specialized free-space radio networking used in the high-frequency trading industry over long distances. Therefore, SpaceX Starlink, OneWeb and others are deploying hundreds to thousands of satellites to provide global broadband Internet service [10].

Nevertheless, orbital periods between 90 and 130 min render short visibility episodes from ground sites, where an LEO satellite appears on the horizon and disappears on the opposite side in about 6 12 min. Depending on the latitude of the location, an LEO satellite will appear over a spot two to four times a day contributing to the disadvantages of longer distances and faster satellite switching, and these networks also demand unique design and operational challenges especially in Physical topology design, routing [44] and congestion control [1]. As time goes by, the requirements toward data processing speed, network resources utility, energy saving, privacy protection, user quality of user service and survivability under link failures are higher and higher. Deng et al. [8] proposed an iterative optimization algorithm based on the Stackelberg game developed to maximize resource utility. By analyzing the shortcomings with regard to energy saving, Gregory et al. [29] present the crucial components of software infrastructure for safe, fully automated, energy-effective, dynamic, and reward-optimal operation of LEO satellites and satellite constellations. In order to copy with the problem of survivability, Shaoqing et al. [38] present k-means and β-means to protect against link failures, while Wang et al. [39] proposed to protect them after recognizing several key nodes in the network. Ting et al. [36] presented a blockchain-based trusted and privacy-preserved authentication scheme for inter-constellation cooperation in SGINs to not only protect the privacy, but improve the survivability of the LEO satellite network.

STK [44] is a prominent business analysis software developed by an American analytical graphics company in the space industry, supports the entire process of space missions, including design, testing, launch, running, and task applications and offers the communication simulation of satellite and ground stations in the graphical interface. It can not only calculate the location and position of the satellite at any time, and provide a satellite orbit generation guide to help users establish common orbits, but display all the information that is based on time, and have a multi-window real-time display of the task scene change. Cesium [4] is a JavaScript based map engine using WebGL which supports 3D, 2D, 2.5D map display and most browsers and mobile. It focuses on the visualization of dynamic geospatial data, with a high performance of system and precision.

The SGP4(Simplified General perturbation modes) model was developed by Ken Cranford in 1970 for near-Earth satellites. It is an extensive analysis of Lane and Cranford (1969), takes the effects of perturbation forces such as the non-spherical attraction of the earth, the attraction of the sun and moon, solar radiation pressure and atmospheric resistance into account and can be used for near-earth objects with orbit cycles less than 225 minutes. If the TLE track report is substituted into the SGP4 model, the space target with an orbital period of fewer than 225 minutes can be predicted successfully, and the position and velocity of the target object at any time can be solved [26]. Mininet [22] is a simulation tool for processing virtualization network developed by Stanford University based on Linux Container architecture and can create a virtual network containing hosts, switches, controllers, and links. Its switches support OpenFlow and have highly flexible customized software-defined networks. It provides a simple and inexpensive network testing platform for OpenFlow applications, topology-aware and OpenFlow-aware CLI for debugging or running network-wide tests, an extensible Python API for user network creation and experimentation, and enables complex topology tests without physical network connections.

3. Related work

4. Architecture of LEOCN

To make up for the question of real-time and interactivity, we built LEOCN, the structure of this LEO constellation network containing Node, Link, Constellation, Topology, Network and Monitor module and some submodules, as shown in Fig. 1.

OPEN IN VIEWER

Fig. 1.

Overall architecture of LEOCN.

4.2. Link

OPEN IN VIEWER

Fig. 2.

Link modes in LEOCN.

LEOCN has two link modes. Links between satellites are inter-satellite link (ISL), and directly they are connected to each other. Links between satellites and ground stations are ground-to-satellite links (GSL). Unlike ISL, all ground stations do not connect to satellite instead of their mobility switch node, as shown in Fig. 2. GSL simulates wireless communication with poor bandwidth, and ISL simulates laser communication with high bandwidth. However, the bandwidth of the link is not fixed, and it can be adjusted according to the requirements of researchers. In addition to bandwidth, there are delay, jitter and loss rate properties that can be controlled in the link module.

In the whole architecture, link modules are responsible for connecting the state between two nodes. It provides interfaces that modify its connecting state such as bandwidth, and record the instance of two link ends for the development of an add-on function. Each link instance has two independent network interfaces which control outgoing and ongoing connecting states, which supports future more complex architectural designs.

5. Implementation of LEOCN

To promote understanding of the following algorithm, the Table 1 and following definitions are provided.

Definition 1.

s TLE is expressed as a single satellite TLE, E TLE as the satellite TLE set of constellation, where E TLE = { s 1 TLE , s 2 TLE , s 3 TLE , … , s m TLE } , which m is defined as the total number of satellites in the constellation.

Definition 2.

t is defined as timestamp, T is defined as T = { t 1 , t 2 , t 3 , … } , where ∀ i ∈ 1 , 2 , 3 , … t i < t i + 1 . To emphasize the characteristics of the real-time property in LEOCN, t 1 is defined as the timestamp of the starting simulation.

Definition 3.

At each timestamp t ∈ T , the constellation topology is defined as an undirected graph G t = ( V t , E t ) , where V is the set of ground station nodes and satellites nodes at the timestamp of t, and E t is the set of ISL link and GSL link at the timestamp of t.

OPEN IN VIEWER

Table 1

Notations

Notations	Description
m	the number of satellite nodes
n	the number of ground station nodes
g	the ground station instance
f max	the maximum float
E tle	the satellite TLE set of constellation
E sat	the satellite set of constellation
E gs	the ground station set of constellation
E	the all node set of constellation, where E = { E sat , E gs }
V gsl	the GSL link set of constellation
f ( t , s tle )	compute the coordinate of latitude and longitude of satellite at time t
dis ( t , e 1 , e 2 )	compute the distance between e 1 and e 2 at time t

5.1. Topology

OPEN IN VIEWER

Fig. 3.

Topology of LEOCN, including ISL topology and GSL topology. ISL topology describes the connection between satellites, GSL topology describes the connection between satellite and ground station.

At the process of building network topology, topology module obtains the information of satellites and their ISL from constellation module and ground station ones from configuration file, and then generates corresponding instances. These instance nodes are granted for the specialized IP ranges. Each ISL is allocated as a 30-bit subnet mask, which accommodates the two end nodes. The GSL of ground station nodes which connect to the same satellite node are considered as a same subnet, and its capacity depends on the range of subnet mask designed by the researchers.

Each construction and destruction of ISL and GSL require the IP pool module of the topology module to control. This module allocates IP to the instance node from the IP pool while construction, and releases IP from the instance node to the IP pool while destruction. Topology module utilities graph of networkx [24] to record all instance nodes.

As can be seen from Fig. 3, each satellite is able to connect any number of ground stations except for more than the capacity of the subnet, and has 4 ISL links, 2 links in the same orbit and 2 links connected to adjacent orbit. Throughout the whole process of constellation simulation, topology module need to record all IP of the network interfaces and all subnet for each network interfaces. These data support for the implementation of routing algorithm mentioned later in this section.

The LEOCN utilizes the time slice algorithm for the implementation of mobility, which updates topology states with unceasing regularity. The update algorithm seeks the shortest satellite for each ground station, so the distance between every ground station and all satellites must be computed, and the time complexity is O ( n 2 ) , as shown in Algorithm 1. After this process, the new graph generated by the mobility process will be stored in the topology module.

OPEN IN VIEWER

Algorithm 1

Mobility algorithm

OPEN IN VIEWER

Fig. 4.

Workflow of link updating.

The link process of mobility algorithm, as shown in Fig. 4, consists of multiple verification and link switch processes. First, check whether the link needs to be replaced. Connectivity validation is then required, regardless of whether changes are required. Lastly, disconnecting the current link if both connection links fail to verify in connectivity validation, otherwise update the current connection state that contains bandwidth, IP and delay computed according to distance.

LEOCN deploys the minimum hop routing algorithm with Dijkstra method, which can be well applied to the topology mentioned earlier in this section, as shown in Algorithm 2. Since initialization, the ISL topology has been fixed, and so has the subject of every satellite. Consequently, fixed are paths to any subnet of satellite from other satellites. In this case, the minimum hop routing algorithm only requires to update routing strategies once at the initialization. Compared to the perpetual updating strategies of the shortest path routing algorithm, it has the lower overhead.

OPEN IN VIEWER

Algorithm 2

The shortest hop routing algorithm

OPEN IN VIEWER

Fig. 5.

Subnet mode of LEOCN, thin dotted lines indicate GSL link, thick dashed lines indicate ISL link.

The implementation of routing algorithm requires the information of next-hop IP, which comes from topology implementation. Instead of computing the next-hop of all subnet, the routing algorithm of the LEOCN only calculates that part of the subnet of the ground station, as shown in Fig. 5, 1◯ and 2◯ are the reachable subnets. 3◯, 4◯, 5◯, 6◯, 7◯, 8◯ and 9◯ are the unreachable ones that the simulation does not compute the routing strategies to. The number of subnet of constellation simulation is 3 m , of which 2 m is ISL subnets and the other m is the subnet of satellites for ground stations. In LEOCN, all ground station nodes employ the connected satellite as the gateway, so the implementation of routing algorithm only depends on the routing strategy of satellite. And one routing updating process takes m × ( m − 1 ) routing strategies, where each of the m satellites has m − 1 routing strategies. It is considerably smaller than the full subnet routing strategies.

The visualization of LEOCN implements with Cesium [3], which can show the satellite trajectories, the topology information, the ISL link state and link traffic size. The generation of satellite trajectories depends on TLE, which LEOCN utilities TLE to generate CZML data for Cesium in real-time. The topology information and ISL link state are retrieved from the topology module and visualized in the Cesium. The link traffic size is acquired from the monitor module and visualized on a separate page.

6. Evaluation

In this section, we present four experiments to show the status of constellations in different environments. Since LEOCN is the first real-time and complete framework for network simulation, we can not conduct comparative experiments with the frameworks of other papers. The environment of the four experiments:

OPEN IN VIEWER

Fig. 6.

Visuilization of experiment environment, each thick line in a different color indicates a satellite orbit, and the same colored dots above indicate satellites in that orbit, and the thin purple lines indicate ISL link.

Fig. 6 shows the visualization of the environment of experiment. It can see the different orbits, ISL state, satellite position and ground station position.

6.1. Resource consumption OPEN IN VIEWER

Fig. 7.

Resource consumption statistical figure, Fig. 7a was experimented in the environment of no network communication, Fig. 7b was experimented in the environment of randomly network communication, Fig. 7c shows the memory usage of the preceding two environments.

The consumption of system resources is one of the important indicators to evaluate the performance of LEOCN. Fig. 7 shows the state of system resources from the beginning of the simulation. The top [34] from procps 2:3.3.16-1ubuntu2.2 is used to collect the system resource state every 100 ms in these experiments. There are three labels in the first two figures Fig. 7a and Fig. 7b, user space as the time running user processes of the CPU state percentages, kernel space as the time running kernel processes of the CPU state percentages, and I/O as the time waiting for I/O completion of the CPU state percentages. Two kinds of experiments were tested here, No-Load Simulation and General-Load Simulation. There is no network communication in No-Load Simulation. General-Load Simulation will randomly pick some nodes and make them communicate with each other. The third figure Fig. 7c shows the state of physical memory usage for two kinds of experiments, and as can be seen in the figure, the Ubuntu system itself consumes about 1,500 MB of physical memory.

The time from 0 to 150 seconds is the initial process of LEOCN, and after this process, the simulation is up and running. As shown in Fig. 7, the first kernel space peak around 50 seconds is due to the initialization of the node network interface, and the second one around 100 seconds is due to the initialization of routing strategies. In No-Load Simulation experiment, there is a kernel space peak every 10 seconds after 150 seconds where the simulation started, and they are due to the updating of the mobility module. In the running period of General-Load Simulation experiment, user space and kernel space keep dynamically changing due to the random network behavior. The utilization of I/O had been low in the whole process. The LEOCN is not a memory-consuming system, and even with so many nodes, the entire system utilizes less than 5,000 MB of physical memory.

6.2. RTT and path-hop OPEN IN VIEWER

Fig. 8.

RTT and path-hop evolution, the experimental data were collected every 100 ms.

We examine how the end-end RTT and path hop differ over time, its result is shown at Fig. 8. The mobility of satellites has a great influence on the stability of the satellite network while the handover of satellites happening. The ping measurements from iputils-ping and the simulation utilities are the minimum hop routing algorithm. From Fig. 8, the RRT could have shot up and bounced back while the handover of satellites happening. For path-hop, the distance as far apart as Guangzhou and Chicago maintains between 8 and 11 hops, but even the shorter distance from Guangzhou to Beijing has the probability that path-hop jumps to a high value of around 11 and stays there for a while.

6.3. Loss OPEN IN VIEWER

Fig. 9.

Loss packet overall, this experiment utilizes iputils-ping to collect the information of the loss packet, its timeout has been set to 1 second and it measures the information every 100 ms for one hour.

Most previous works do not pay attention to the loss information, here is the experiment for loss, as shown in Fig. 9. This experiment utilizes iputils-ping to collect the information of the loss packet, of which timeout has been set to 1 second and it measures the information every 100 ms for one hour. There are five paths that have been experimented, Beijing-Chongqing, Chicago-Paris, Lagos-Karachi, Chengdu-Tokyo and HongKong-Guangzhou. As can be seen from the figure, HongKong-Guangzhou and Beijing-Chongqing have a better overall amount of loss packets than others, and Chicago-Paris have the worst overall amount of loss packets in the whole experiment.

6.4. Mobility OPEN IN VIEWER

Fig. 10.

Mobility experiment: in this experiment, the simulation stays running continuously for one hour and records the switch times Fig. 10a of satellite connected by ground station. The values of Fig. 10b are the sum of the switch times of the two target ground stations.

OPEN IN VIEWER

Table 2

Part of ground station

	Beijing	Chicago	Guangzhou	Paris	Tokyo
Latitude	39.9075	41.85003	23.8	48.85341	35.6895
Longitude	116.39723	−87.65005	113.17	2.3488	139.69171

We also explore the effects of the position of a ground station on mobility. In this experiment, the simulation stays running continuously for one hour and records the switch times of the satellite connected by the ground station. The result is shown at Fig. 10. In the The Switch of Ground Station of the figure, it displays the switch time of five ground stations, and Paris has the largest switch time while Guangzhou has the minimum one. These just correspond to the latitude of the ground station, as shown in Table 2: the higher latitude is, the more times the ground station needs to switch. At the same time, it has a huge influence on the end-to-end path, as shown in The Switch of Path of Fig. 10.

On this platform, we achieve the following two experiments. The first experiment is about a network attack on our platform that is involved with five attacks including a DDoS attack, FTP burst, PortScan, SSH burst, and web scan attack. We use a Machine Learning (ML) algorithm to recognize the sort of network attack in LEO link flow. To prevent our model from identifying potential attacks by mistakes in the future, we conduct another experiment, and we create the adversarial example, meaning that this sort of flow will happen in a few days to enhance the robustness of our model. For generating better images, we transfer our flow bytes into images and train our model by those images. These two experiments are detailedly written in other papers. And we evaluate our platform with the two experiments above conducted, and it shows good link utilization and low network delay.

Applying NWDAF(Network Data Analytics Function) to leo installation will have been becoming a trend taking the special structure of 5G into account. By using edge computing, we can process network edge cache and unload calculation when facing insufficient resources, and keep user data security and privacy. Shaoqing Wang et al. [30] proposed an AI-driven F-RAN (fog radio access networks) paradigm combining the edge computing with ML. Their thoughts include Artificial Intelligence (AI) capsules alleviating the transmission burden incurred by network data collection through utilizing computation and cache resources at various fog nodes, and AI brain that considers completely minimum energy consumption for offline AI model training and evaluation. Our platform can conduct some AI analysis toward both resources computation offloading and emergent data processing combining their ideas. It will be combined with the method proposed by Tianqing Zhu et al. [33] in the future. Over and above, we can avoid the overhead incurred by massive training data collection by federated learning and solve cost-inefficience of re-designing AI models by transferring learning in the future.

Considering the lack of trust among different constellations, communication security and privacy protection are important issues that need to be solved during inter-constellation cooperation. Blockchain has the advantages of privacy security, non-tamperability of data and decentration and it will properly satisfy the demand for LEO satellite constellation. Therefore, Shaoqing Wang et al. [36] presents a trusted and privacy-preserved authentication scheme for inter-constellation collaboration. They design the permanent identity used for inter-constellation communication, and the temporary identity used for inter-constellation cooperation and privacy leakage for each satellite respectively. When satellites go commercial, these methods else proposed by Jiang Nan et al. [14] and Li Jin et al. [19] will also be used. Besides, a consortium blockchain for sharing information is introduced, while a replica storage node method for efficient authentication under limited resources is proposed. Based on their research, our platform will conduct further experiments to design intelligent contracts customized for LEO installation.

We have achieved the function of judging whether our network suffers from an attack and recognizing classification towards network attack and which terminal launches this attack, and we make defense based on that. To prevent some attacks that can happen in the future and enhance the robustness of our model, we make adversarial samples by network flow on the LEOCN platform. The following is edge computing [30] based Deep Learning to enhance the function of data analysis and reduce traffic congestion which contributes to our following experiments. Finally, we need to achieve the blockchain [36] to keep the encryption and security of communication among LEO satellites and ground terminals.

8. Conclusion

We presented LEOCN, a new platform for network simulation that includes topology and routing algorithm, visualization, satellite mobility, communication protocol and network traffic. LEOCN exhibits dynamics of the constellation with special celestial movement in our implementation. It offers a real-time and complete network simulation platform on which we have conducted some experiments about network defense and adversarial examples offering topology and routing algorithm in advance for LEO satellite constellations. With this platform, you can conduct some LEO experiments about blockchain, edge computing, deep learning and so on, without the trouble of special celestial movement, routing algorithms, etc., especially for low orbit satellites.