Digital Twin Technology-Based Networking Solution in Low Earth Orbit Satellite Constellations

Abstract

Digital twin technology provides a reliable paradigm to address the high trial-and-error costs and limited perception capabilities in satellite networking. However, the dynamic constellation topology and real-time twin applications remain significant challenges in satellite network design. This paper proposes a network topology simulation approach that dynamically analyzes the inter-satellite topology based on pre-calculated ephemeris and orbital information. Furthermore, the paper introduces a digital twin algorithm based on network virtualization, cloud platform management, and software-defined networking to validate and analyze the twin requirements at different stages. Finally, a low Earth orbit (LEO) constellation twin validation environment is constructed to verify the networking protocols at various stages. The experimental results demonstrate the performance of the proposed twin systems at different stages.

1. Introduction

The deployment of large-scale low Earth orbit (LEO) satellite networks offers a promising solution to achieve truly global access services [1]. Compared to traditional ground infrastructure and geostationary satellites, LEO satellite networks utilize satellites deployed in a low Earth orbit, providing global communication coverage with lower latency and higher throughput. In this context, LEO satellite networks are widely recognized as a core component of future 6G networks. Several companies (e.g., SpaceX, OneWeb, O3B, and Iridium Next) have begun deploying large-scale LEO satellite constellations to gain an advantage in the fierce ‘NewSpace’ race [2,3].

Although significant progress has been made in the research of LEO satellite networks, the high trial-and-error costs and limited perception capabilities remain two major issues constraining the further development of the LEO satellite industry.

To address these two issues, digital twin technology [4,5] serves as a reliable paradigm to facilitate the development of LEO satellite networks. By conducting high-precision, multidimensional, and comprehensive dynamic simulations on computers, digital twin technology can create models of physical entities in the virtual world according to certain rules. It establishes connections between the physical and virtual worlds, enabling real-time interactive communication, virtual-to-physical control, self-iterative optimization, and updates. Currently, digital twin technology has become a major focus in both academia and industry. Companies like Siemens and NASA have utilized digital twin technology to construct end-to-end digital twin production system models and virtual systems equivalent to aerospace systems. Several universities, including Wuhan University and the University of Michigan in the United States, have conducted research on the theory and future development of digital twin technology. As such, digital twin (DT)-enabled LEO satellite networks provide an efficient tool that can comprehensively evaluate effective and stable collaboration among LEO satellites.

On the downside, considering the high-speed orbital motion of satellite constellations and the diverse validation requirements, digital twin (DT)-enabled LEO satellite networks face the following challenges: (i) as space devices moving around the Earth at a speed of 27,000 km/h, satellites cannot provide long-term stable services to users, making existing ground-based network-based digital twin solutions unsuitable for satellite networks; (ii) satellite constellations have different requirements during different stages of construction, making it difficult to meet the twin validation needs of different stages based on a stable solution.

Motivated by the above-mentioned challenges, in this study, we strive to develop a DT-enabled LEO satellite networking framework. In particular, we propose a digital mapping method to represent network elements, network connections, and network behaviors. In doing so, we construct virtual models of the physical entities in LEO constellation networks. Following this, based on pre-generated ephemeris and orbital information, we design a network topology simulation method to analyze the satellite topology structure. Lastly, we propose to implement interaction mapping between the physical space and virtual space, thereby meeting the twin validation needs in various stages (before, during, and after) of the construction of the LEO constellation system.

Digital twins have found widespread application in satellite platform twinning, yet their usage in low-orbit constellation network protocol twins remains largely unexplored. Due to the limited availability of research references in this area, existing twinning techniques can only be applied by adopting other conceptual frameworks. In this context, the main contributions of this paper are summarized as follows.

• We propose a network topology simulation method that combines pre-generated ephemeris and orbital information, enabling the dynamic analysis of the satellite interconnection structure in low Earth orbit (LEO) constellations.
• For LEO constellation networks, we develop a digital twin algorithm based on network virtualization, cloud platform management, and software-defined networking. The proposed algorithm effectively meets the twin validation requirements of large-scale, high-fidelity, and low-cost simulations.
• Based on the twin validation needs at different stages of satellite development, we construct an LEO constellation twin validation platform that comprehensively enhances the virtual-to-physical mapping, virtual-to-physical interconnection, and virtual-to-physical optimization. Such a validation platform facilitates twin validation work for network protocols at different stages.

The remaining sections of this paper are organized as follows. Section 2 presents related work. Section 3 describes the different stages of digital twin system design. Following this, Section 4 describes the system model and Section 5 elaborates the networking protocol based on digital twins. In Section 6, the simulations and analysis are provided, followed by the conclusions in Section 7.

2. Related Work

With the development of wireless communication, networks, sensing, and the Internet of Things (IoT) [6,7], the amount of detection data obtained based on sensing or collection has increased dramatically in various fields. These data exhibit the typical characteristics of industrial big data, such as heterogeneity, dynamism, high speeds, and massive volumes. Additionally, the dynamic changes in complex operating environments pose significant challenges for the processing, analysis, and predictive accuracy of the aforementioned data. However, current research on data detection and fault analysis mainly focuses on ideal static scenarios, which cannot meet the real-time status assessment and predictive accuracy requirements of devices operating in complex and dynamic environments. The emergence of digital twins provides a new solution to address these challenges. In recent years, there has been a growing demand for network digitalization and model digitalization in China, and digital twin technology has attracted widespread attention and research from the global industrial and academic communities. The origin, domestic and international technological developments, and application status of digital twins are summarized as follows.

The concept and application of digital twins [8,9] originated abroad. In 1969, the National Aeronautics and Space Administration (NASA) of the United States began using the concept of virtual mirroring in the Apollo program. In 2003, Professor Michael Grieves of the University of Michigan proposed the concept of “virtual digital representation equivalent to physical products” in the Product Lifecycle Management (PLM) course. From 2003 to 2005, this model was referred to as the “mirror space model”, and from 2006 to 2010, it was called the “information mirror model” and “digital twin”. In 2010, NASA introduced the concept of digital twins in its Space Technology Roadmap, aiming to achieve comprehensive diagnostic and predictive capabilities for flight systems using digital twins to ensure continuous and safe operations throughout the system’s lifespan. In 2012, NASA summarized its research and engineering processes and officially released a roadmap for “modeling, simulation, information technology, and processing”, making digital twins known to the public for the first time. In 2014, the theory and technological system of digital twins were introduced and accepted by the U.S. Department of Defense and other entities. From 2017 to 2019, Gartner listed digital twins as one of the top ten strategic development trends for three consecutive years.

In recent years, along with the development of 5G/6G industries [10,11], digital twin technology has also been gradually developed in various fields in China. In the field of production manufacturing, concepts such as the Digital Twin Shopfloor (DTS) have been proposed by Tao Fei et al., who studied five key technical issues related to twins and designed the composition and operation mechanism of the DTS, providing theoretical support for the application of digital twin technology in production manufacturing. Zhang Hao et al. proposed a design method for production line digital twins, synchronizing the virtual and the real to form a complete digital twin system to optimize the production manufacturing process. In the field of wireless networks, Lu Yunlong et al. introduced digital twins to wireless networks and designed a wireless network digital twin system for collaborative edge computing research. In the field of intelligent transportation, Wu Chaohui et al. constructed a digital twin system for intelligent transportation application scenarios, mapping multiple physical entities in the transportation field to the virtual world, providing technical support for the realization of “digitization, networking, and intelligence” in the digital transformation of transportation. In the field of smart digital cities, academician Li Deren proposed that digital twin cities are the construction goals of the future, conducted an in-depth analysis of the characteristics and advantages of digital twin cities, and provided construction directions and application guidelines for digital twin smart cities. In the satellite field, Liu Weiran et al. conducted research on digital twin satellites based on satellite internet construction, focusing on the composition of satellites and the digital twinning of core functions. Liu Datong et al. proposed a scheme for the building of a satellite digital twin on the ground, using the constructed model to reflect and evaluate the real operational status of satellites and predict their service life.

In both production manufacturing and aerospace, significant advances have been made in the development and application of digital twin technology. In the field of production manufacturing, Siemens has built a full-process digital twin production system model. The digital enterprise virtual model can cover the entire value chain and has been applied and verified in the production processes of Siemens industrial equipment, such as the Nanobox PC. In aerospace, digital twin technology generates extensive simulated data by replicating the continuous time history of a flight through simulation. These data serve as the foundation for the identification of various conditions encountered by an aircraft. Additionally, when coupled with diverse simulation techniques and computational fluid dynamics, digital twin technology can predict future maintenance requirements and potential flight safety challenges in the aerospace sector [12].

Currently, in the satellite field, digital twins [13] are primarily used for platform twinning. Based on rich sensing information [14], they monitor, reproduce, schedule, and optimize the status of satellite platforms. However, concerning network protocol twins, particularly for low-orbit constellations, the application of digital twin technology remains relatively unexplored. This study focuses on the popular low Earth orbit satellite constellation formation protocols and conducts key technological research on digital twin technology in this field. The difficulty lies in the fact that, since all of the above areas are in the unexplored stage, the existing digital twin technologies only draw on external concepts in this task, and there are no concrete and well-established approaches that we can refer to.

3. Phased Digital Twin System Design

The satellite internet constellation system (LEO constellation) is a complex, large system composed of large-scale low-orbit satellites. Unlike high-orbit and terrestrial networks, it possesses the unique attributes of a low orbit, such as a highly dynamic satellite inter-satellite topology, the fast movement of satellite nodes, and the limited capacity of on-board payload platforms. The LEO constellation aims to meet the requirements of large-scale operation-level networking applications. As a result, its networking protocol is highly complex and specialized. The launch and deployment of the LEO constellation will be carried out gradually in stages. Taking into consideration the protocol design requirements and deployment implementation plan, the design of the digital twin architecture for the LEO constellation network’s networking protocol needs to be divided into three stages: pre-construction, construction, and post-construction.

Phase 1: Digital twin system before construction

This stage belongs to the “simulating reality and reflecting reality through simulation” phase. To validate the effectiveness of the low-orbit constellation network’s networking protocol, it is necessary to establish a simulated verification environment that closely resembles the real constellations and ground elements. This environment will enable functional implementation, design feasibility assessment, testing, and verification. This stage does not involve the physical system, and there is no actual data interaction between the digital twin system and the physical system, which is the internal closed-loop simulation verification of the pure digital twin system.

Phase 2: Digital twin system under construction

This stage belongs to the phase of the “interconnection of the virtual and real, and the control of reality with virtuality”. On the basis of the first stage, the maturity level is further increased. Given the gradual verification requirements in constructing and deploying a satellite internet system, the strategy involves launching only a subset of satellites in the constellation, rather than deploying the entire network at once. It is necessary to build a digital twin system that can be interconnected with the physical system and directly deploy the routing protocols of satellites, information customs stations, and terminals that are actually used in the physical system to the digital twin system to build the corresponding twin nodes. At the same time, through the real-time two-way closed-loop interaction of virtual and real traffic, a semi-physical digital twin system based on the combination of on-orbit satellites and ground simulation is realized, which fulfills the requirements for functional performance verification, analysis, and evaluation throughout the construction phase. It also supports the continuous, iterative enhancement of networking technologies as the constellation progressively expands.

Phase 3: Companion digital twin system after completion

This stage belongs to the phase of “using the virtual to accompany the real, and the virtual to accompany the real”. Twin rehearsal, optimization decision-making [15], and future deduction are accomplished through real-time, two-way, closed-loop state and data interaction between the digital twin system and the physical system. This interaction enables the near-real-time dynamic reflection of the current network status of the physical constellation system. The digital twin system involves three aspects: (1) completing the synchronous visual presentation; (2) predicting the network states that may occur in the future operation of the physical constellation system through the intelligent analysis of the obtained data, intelligently selecting the optimal network solution for the future, and finally implementing the intelligent management and control of the actual physical networking system; (3) carrying out the simulation and optimization of the new networking technology or protocol based on the current network state data. After the test is passed, the physical constellation system is released in grayscale to meet the needs of system technology iteration and optimization.

4. System Model

4.1. Low-Orbit Constellation Network

The low Earth orbit (LEO) satellite network consists of LEO satellites, satellite terminals, and gateway stations, as shown in Figure 1. The network comprises satellites, terminals, and gateway stations. The network element equipment includes on-board routing and switching payload equipment, mobile satellite terminals, broadband satellite terminals, and protocol networks at the gateway station. The LEO constellation primarily consists of multiple communication-enabled satellites, interconnected through intra-constellation and inter-constellation links, strategically deployed across different orbital planes to achieve seamless global coverage. Additionally, satellite payloads with routing and switching capabilities are deployed onboard the LEO satellites to facilitate the routing, switching, and forwarding of data within and between satellites. Satellite terminals, categorized as mobile and broadband terminals, enable user data access, protocol conversion, and satellite-to-ground user routing. Gateway stations serve as the core hubs and management control centers of the LEO satellite constellation, responsible for network formation control, information exchange, and distribution.

4.2. Networking Routing Protocol

4.2.1. Low-Orbit Constellation Network Routing Protocol

The routing protocols in the low Earth orbit (LEO) satellite network [16,17] include the inter-satellite routing protocol, feeder satellite-to-ground routing protocol, and user satellite-to-ground routing protocol. The inter-satellite routing protocol is deployed among the LEO satellite nodes to establish inter-satellite forwarding paths. This protocol takes into account the periodic and dynamic changes in the topology of the LEO inter-satellite network. The feeder satellite-to-ground routing protocol is deployed between the LEO satellites and gateway stations to address the feeder selection problem among multiple gateway stations and within a single gateway station. When designing this protocol, the frequent switching of feeder links caused by the high-speed movement of the LEO satellite nodes is considered, and the routing selection incorporates ephemeris calculation and real-time feeder detection. The user satellite-to-ground routing protocol is deployed among satellite terminals to enable addressing and forwarding between terminals. In the design of this protocol, the frequent switching of user links caused by the high-speed movement of LEO satellite nodes during user communication is taken into account.

4.2.2. Network Routing Protocol in Satellite Broadband Internet System

The digital twin technology [18] discussed in this study primarily focuses on the application scenarios of network routing protocols, specifically in the context of the low Earth orbit (LEO) satellite network. The routing protocols in the LEO satellite network are applicable to both broadband and mobile satellite communication architectures [19,20]. However, since the routing in the broadband architecture is based on full-mesh routing, the research scope of the digital twin for the LEO satellite network proposed in this study is specifically targeted at the broadband routing protocols.

The deployment and application of the routing protocols in the satellite broadband internet architecture are illustrated in Figure 2. In the broadband regime, the routing is characterized by full-set routing, while, in the mobile regime, subscriber satellite–Earth routing is absent. In the case of a satellite broadband internet system [21,22] that employs full-mesh routing, it includes inter-satellite routing between the LEO satellite nodes [23], feeder-side satellite-to-ground feeder routing between the LEO satellites and gateway stations, and user-side satellite-to-ground user routing between user terminals.

5. Networking Protocol Based on Digital Twins

To meet the requirements of constructing a digital twin for low Earth orbit (LEO) constellation systems, it is necessary to first research and address the challenges of simulating LEO constellation network scenarios with multiple nodes, complex constellation configurations, and high-dynamic inter-satellite topology constraints. The research involves building a foundational platform for digital twinning, which is essential to support the development of LEO constellation network protocol digital twins. Therefore, establishing a highly realistic, easy-to-deploy, and cost-effective LEO constellation network simulation platform on the ground is a crucial research topic. It forms the basis for the construction of digital twin systems of network protocols and holds significant engineering practicality.

Currently, there are two mature methods used in the industry: software simulation based on simulation software such as NS-2, NS-3, and OPNET and physical emulation based on actual hardware devices.

Software simulation primarily involves building a simulated network using probabilistic statistical models of network devices, communication links, and network protocols. It abstracts and models the transmission of network traffic at different granularities, such as flows or packets. Software simulation methods typically rely on discrete event-driven models and employ Monte Carlo methods, performing a large number of repeated experiments within the same simulation scenario to obtain a series of key performance data and metrics required for network design or optimization. The advantages of software simulation include low costs, as software models can replace the hardware and network behavior of the actual target network. Typically, complex system simulations can be performed using only a regular computer. However, software simulation also has the following two main drawbacks: (1) it is inherently an approximation of the actual target system and may have certain differences from the real system; (2) the portability of the implemented device software in software simulation is poor and not interchangeable with the software of actual deployed devices.

Physical testing refers to replicating all or part of the hardware structure of the target network and conducting tests and performance evaluations on the actual physical links [24], network protocols, and various upper-layer application software. All experiments must be conducted in real time, so the test environment in physical testing has strong consistency with the real target system scenario. Compared to software simulations, the test results obtained on the physical testing platform can typically sufficiently and accurately demonstrate the performance of the target network’s various protocol layers and upper-layer application software under real-world conditions. However, the physical testing method also faces the following three main problems: (1) high costs—deploying actual hardware in a real-world scenario for testing and verification, especially for large-scale network testing and verification, incurs extremely high costs to build and configure a test network environment that is identical or highly similar to the actual scenario; (2) low testing/integration efficiency—during system testing and performance evaluation experiments, different experimental conditions and environmental parameters need to be selected and set to obtain test results under different scenarios; however, due to the use of actual physical hardware in physical testing, it is usually not as convenient, fast, or flexible as software simulation methods in configuring the experimental scenarios, resulting in lower testing efficiency; (3) difficulties in scenario simulation—in the simulation of LEO constellation scenarios, there are characteristics such as a large number of network nodes and high-dynamic inter-node topology; it is challenging to simulate these characteristics based on physical environments.

However, the requirements for digital twins in the context of low Earth orbit (LEO) satellite constellation networks are as follows: (1) a low-cost digital twin with the ability to simulate a large number of network nodes (hundreds/thousands/millions of satellites); (2) a high-fidelity topology simulation that accurately reproduces the dynamic interconnections between satellites and ground stations; (3) high maturity in simulating network node functionalities, where the digital twin scenario should align with the code of the physical devices and network protocols being tested. Only by meeting these requirements can we construct a LEO satellite constellation network digital twin platform that is highly realistic, cost-effective, and flexible, aligning with the future operational LEO satellite systems and fulfilling the needs of twin verification.

Therefore, by integrating the advantages and disadvantages of software simulation and physical testing methods, this study introduces mature concepts from academia and industry, such as cloud platform resource management, host and network virtualization, and software-defined networking, into the field of simulation testing. A digital network simulation approach is adopted, and research is conducted on the methods for the construction of a digital twin platform for LEO satellite constellation networks, taking into account the network’s specific scenarios and application requirements.

5.1. Architectural Design of DT-Enabled LEO Satellite Network

In the architectural design of the digital twin platform for low Earth orbit (LEO) satellite constellation networks, strict adherence to modular software design principles is ensured. Cloud platform [25] resource management technology is employed to dynamically allocate and accelerate the construction and teardown processes of computing and network resources in the simulation platform, facilitating the dynamic creation of network topologies. Host virtualization technology is utilized to improve the hardware resource utilization, enhance the scalability of the simulation system, and provide a runtime environment identical to the actual devices. This enables the direct testing of real network protocols and upper-layer applications without the need for porting, significantly improving the efficiency and accuracy of simulation testing. Network virtualization and software-defined networking technologies are leveraged for fine-grained network traffic control, enabling multi-granularity network simulation based on the precise physical-layer modeling of the channels. Therefore, the digital network environment offers numerous advantages, such as low construction costs, high scalability, ease of management, flexibility, and high maturity, making it suitable for the entire lifecycle of target network system design, development, delivery, and operation.

The architecture of the digital twin [26,27] platform for the LEO satellite constellation network, as shown in Figure 3, consists of the following layers: resource layer, virtualization layer, management layer, and human–machine interaction layer. The resource layer utilizes common hardware devices such as computing and networking equipment with horizontal scalability. The virtualization layer deploys tools for compute virtualization and network virtualization. The management layer facilitates network node management, as well as topology and link management. The human–machine interaction layer enables user operations on the platform. Based on this platform, various types of twin scenarios can be generated according to the requirements of the LEO satellite constellation twin scenarios.

5.2. Construction of DT Platform

The focus of the research lies in the virtual reconstruction technology of twin systems that are consistent with the tested low Earth orbit (LEO) satellite constellation network in terms of scale, identical network element functionalities, twin application, and lifecycle management. There are two main approaches to the construction of network element digital twin models. The first approach is based on KVM virtualization technology, which builds a virtualization layer on the physical resource layer and runs multiple KVM virtual machines on top of it. Each virtual machine operates its own independent operating system, providing various mainstream Linux operating systems. The network layer, transport layer, application-layer protocol software, and various deployed upper-layer network business application codes in the real devices do not require porting and can be directly applied, achieving the high-fidelity simulation of various types of network nodes. The KVM virtual machines can realize the functionalities of LEO satellite onboard routing and switching, satellite terminals, and gateway nodes at the satellite–ground station boundary.

The second approach is based on container-based lightweight virtualization technology, where the process of the operating system serves as the basic unit. It runs a complete operating system on the virtual hardware, but, instead of creating a separate virtual machine, it isolates and further abstracts the resources of the host machine to provide a relatively independent runtime environment. Compared to virtual machines, containers consume fewer resources and have higher resource utilization, faster startup speeds, and more efficient and convenient deployment. Therefore, under the same physical hardware conditions, a significantly larger number of container instances can be virtualized compared to virtual machines. Additionally, the time from creating to starting a container instance is in the millisecond to second range, far superior to the minutes required for virtual machine startup. Furthermore, container technology allows the packaging of target applications for single-address access and image storage, requiring only simple commands for deployment. The comparison between container technology and KVM virtualization technology is shown in

Table 1. Comparison of the characteristics of containers and KVM virtualization.

Comparison Items	Container	KVM Virtualization
Startup Speed	Milliseconds to seconds	Minute level
Deployment Mode	Container + application	Operating system + application
Running Location	On hypervisor	On host operating system
Image Type	Container image	Virtual machine image
Image Size	Small (MB or even KB)	Larger (GB level)
Performance	Weaker than host machine	Close to host machine’s local process
Resource Utilization Rate	Low	High

.

Therefore, the proposed twin platform in this study supports two different approaches to constructing twin network elements, catering to diverse application requirements. For instance, for scenarios demanding large-scale deployment and rapid implementation, the adoption of container-based lightweight virtualization technology for twin network element nodes is recommended. Conversely, for cases with specific demands regarding performance and operating systems, the use of KVM virtualization technology is suggested for the construction of twin network element nodes.

5.3. Topological Twinning

In order to address the constellation scenarios associated with different orbit altitudes (orbit stratification) and constellation configurations (near-polar orbit, inclined orbit), this research focuses on generating a physical world representation of low Earth orbit satellite movements and their relative positional relationships through orbit calculations. It investigates twin network traffic steering techniques, wireless channel characteristics, and the transformation and mapping of network layer features. These efforts aim to accurately characterize the topological connectivity, dynamic latency, and bandwidth of the constellation network, ultimately achieving the simulation of the real target network’s topology and link characteristics. Specifically, there are two types of twin simulations: topological twinning and link twinning.

The topological twinning [28,29] implemented in this study includes a static topology and dynamic topology. A static network topology refers to a network composed of multiple nodes, where the attributes of links and their connectivity remain unchanged. In contrast, in a dynamic network, the attributes of links and their connectivity change over time. For a given scenario, the static network topology can be decomposed into a collection of nodes, ports, and links, while the dynamic network topology can be decomposed into a collection of static network topologies at different time instances. To achieve a highly realistic simulation of the low Earth orbit constellation network topology, the dynamic topology simulation adopts the design principles of software-defined networking (SDN). It separates the control plane from the forwarding plane and utilizes the orbit information of the real constellation obtained through STK software simulation as input. It precomputes a collection of network topologies within a time period. When the simulation reaches a moment at which the network topology changes, the topology information at that specific moment is dynamically parsed and deployed to the forwarding plane through flow tables, enabling the dynamic variation of the low Earth orbit constellation network topology, as shown in Figure 4.

Due to the periodicity and predictability of the low Earth orbit constellation network topology, the real-time positions of each satellite at the simulation time can be calculated based on the two-line element sets (TLEs) of each satellite in the low Earth orbit. By utilizing the position information of the satellites, the visibility between any two adjacent satellites, i.e., the connectivity status of inter-satellite links, can be determined. If the inter-satellite link is not visible, the connectivity status of the underlying platform’s links is examined. If the link is already connected, it is disconnected. If the link is not connected, its status remains unchanged. If the inter-satellite link is visible, the distance between adjacent satellites is calculated, and the link delay between any two low Earth orbit satellites at the simulation time is determined. The connectivity status of the underlying platform’s links is checked. If the link is already connected, it remains connected, and only the link delay needs to be reset. If the link is not connected, it needs to be established, and the current link delay is set. The dynamic calculation logic of the low Earth orbit constellation network topology is illustrated in Figure 5.

The network topology of the LEO constellation is characterized by periodicity and predictability. Two lines of reports for each satellite in the LEO constellation are pre-entered, along with the limiting latitude values visible between neighboring heterodyne satellites in this constellation from the STK software simulations. At the onset of the simulation, the SGP4 algorithm is employed to calculate the real-time position information of each satellite at the current simulation moment, which is then represented using Cartesian coordinates. The position information is subsequently converted into latitude and longitude coordinates, which determine the link status between any two neighboring LEO satellites. For example, the two lines of reports for two neighboring heterorbital satellites, L0101 and L0201, in the 60-star constellation in a LEO polar orbit on 1 August 2022 are shown in Figure 6. The maximum visible latitude between neighboring heterorbital satellites in this constellation, as determined from the STK software simulations, is 75°. The gp4 algorithm was utilized to calculate the Cartesian coordinates of satellite L0101, resulting in the position (7558.71112301405, 0.4011442917211835, −0.3435727076716426) on 1 August 2022, at 4:00:00 h. These coordinates were then converted to longitude and latitude, resulting in (0.00304071348882°, −0.0026191100101°). Likewise, the Cartesian coordinates for satellite L0201 are (6154.4885404322695, 3715.757929718934, 2333.5585136680743), resulting in longitude and latitude values of (31.1213807701°, 18.07854158°). Since neither satellite dimension exceeds the limiting latitude, the link between L0101 and L0201 is connected at this moment.

5.4. Virtual and Real Interface of Twin Platform

To meet the requirements of the first two stages of twin verification, the twin verification platform needs to have the capability to interconnect with external devices, actual satellites, testing equipment, and other physical entities to jointly build a twin verification environment, as shown in Figure 7. Based on different practical usage needs, the digital twin platform needs to investigate two connection modes: one is the direct connection mode based on multiple network interfaces, and the other is the label mode based on a single network interface. The designs of these two modes are as follows.

• In the direct connection mode based on multiple network interfaces, each physical device occupies one network interface of the digital twin platform and connects to the platform. The digital twin platform does not process the data transmission between virtual and actual nodes. This mode is simple but requires a large number of physical network interfaces.
• In the label mode based on a single network interface, VLAN tags are used to differentiate data packets on the same physical network interface of the digital twin platform. The platform adds VLAN tags to the data packets destined for external devices and removes the VLAN tags from the data packets received from external devices before sending them to the corresponding twin network nodes. This mode enables the reuse of physical network interfaces in the network testing cloud platform.

6. Simulation and Analysis

The satellite internet constellation system (low Earth orbit constellation) is a complex and large-scale system composed of a massive number of low Earth orbit satellites. It is different from both geostationary satellites and ground networks. It exhibits unique characteristics such as high dynamics in satellite interconnections, high-speed movements of satellite nodes, and limited payload platform capabilities on the satellites. At the same time, it needs to meet the requirements of large-scale operational networking applications. Therefore, the network protocols for such a constellation system are highly complex and require special considerations, posing significant challenges.

The development of a digital twin system for LEO constellations relies on the fundamental twinning techniques outlined in Section 3 of this paper, which include model construction and topology simulation. The model construction method involves transforming the constellation grouping network routing protocols of satellite terminals, satellites, and gateway stations operating within the low-orbit constellation system into network element mirrors. This process generates the broadband satellite terminal routing network element model, the star-carrying route switching network element model, and the gateway station protocol gateway network element model. Unlike the model construction method, the topology simulation method employs the SGP4 algorithm to calculate the positions of any two satellites within the LEO constellation at the current simulation time, thereby determining their visibility. The control plane instructs the forwarding plane of the topology simulation unit to transmit a flow table based on the state of visibility or invisibility, thus realizing the on–off switching of the interstellar link.

Additionally, due to the large scale of low Earth orbit constellations, their launch and deployment applications are typically carried out in phased stages. Therefore, considering both the protocol design requirements and the deployment implementation plan, the digital twin of the network protocol for low Earth orbit constellations also needs to be implemented in stages. Taking into account the twin verification requirements across the three stages of “pre-construction, construction, and post-construction” of the low Earth orbit constellation network, this research is based on the achievements in twin platform [30] construction, aiming to establish and test the digital twin scenarios of the network protocol for low Earth orbit constellation networks.

6.1. Twin Scenario Construction and Test Verification for “Phase 1”

Pre-construction focuses on the constellation-wide ground verification of networking protocols for undeployed LEO constellation networks. The performance of the networking protocol is tested and judged by collecting simulation data in a twin verification environment that is similar to the actual system.

To address the verification requirements of Phase 1, the pre-construction phase of the low Earth orbit constellation network protocol, a fully digital twin verification environment is constructed based on the research findings presented in Section 4. This verification environment simulates 50 low Earth orbit satellites, one gateway station, and several broadband terminals. Each low Earth orbit satellite is equipped with an onboard routing and switching node that runs inter-satellite routing protocols to enable data forwarding within and between satellites. The satellite terminals simulate the network layer and above functions of real user terminal devices. By running user-to-satellite routing protocols, they provide functionalities such as user access, service access, and inter-satellite handovers. The gateway station deploys a boundary gateway node that runs feederlink-to-ground routing protocols to handle the conversion and processing of low Earth feederlink layer protocols and ground-side protocols.

As shown in Figure 8, the satellite terminal 0106 is connected to the low Earth orbit satellite L0106, and the satellite terminal 0107 is connected to the low Earth orbit satellite L0107. The satellite terminals 0106 and 0107 achieve inter-constellation communication by accessing the low Earth orbit satellites L0106 and L0107, respectively. Ping packet connectivity testing is performed between the satellite terminals.

Based on the fully digital twin verification environment depicted in Figure 8, two testing and validation tasks were conducted.

• Testing and validating the performance of the low Earth orbit constellation network protocol when the inter-satellite topology undergoes predictable dynamic changes. Satellite terminal 0106 sends ping packets to satellite terminal 0107, with the IP address of 171.1.27.10. During ping packet transmission, the inter-satellite topology changes periodically based on the ephemeris data. Utilizing the functional model deployed in the low Earth orbit constellation twin verification environment, the ping packet display indicates normal business connectivity without packet loss. Additionally, the latency varies dynamically with the relative positions of the satellites, ranging from 31.17 to 39.86 milliseconds, as shown in Figure 9 and Figure 10.
• Testing and validating the adaptability of the designed low Earth orbit constellation network protocol when unpredictable abnormal disruptions occur in the inter-satellite links. Satellite terminal 0106 sends ping packets to satellite terminal 0107, with the IP address of 171.1.27.10. During ping packet transmission, a link abnormality interruption occurs between the low Earth orbit satellites L0106 and L0107. The routing convergence and business transmission conditions are illustrated in Figure 11. After conducting five repeated tests, the average business recovery time is determined to be 7.43 s.

The protocol testing results based on this environment demonstrate that by constructing a twin verification environment that closely resembles the actual system, various typical application scenarios can be created to conduct network architecture and protocol validation before satellite deployment.

6.2. Twin Scenario Construction and Test Verification for “Phase 2”

Simulation tests during construction are necessary to verify the effectiveness of the deployed constellation protocols as the LEO constellation is gradually deployed. Additionally, evaluating the performance of the fully operational semi-physical LEO constellation system based on semi-physical test validation methods for on-orbit scenarios is essential. In response to the verification requirements for the ongoing development of the low Earth orbit constellation network protocol in Phase 2, a semi-physical low Earth orbit constellation twin verification environment is established by introducing physical devices based on the foundation of the fully digital simulated nodes in Phase 1. This environment consists of two parts: a fully digital environment and physical prototypes of on-board routing and switching equipment.

In the fully digital environment, 48 simulated low Earth orbit satellites, one gateway station, several broadband terminals, and one controller are simulated. Each low Earth orbit satellite deploys an on-board routing and switching node to forward data within and between satellites by running inter-satellite routing protocols. The satellite terminals simulate the network layer and above functionalities of real user terminal devices, providing functions such as user access, service access, and inter-satellite handover through running user satellite–ground routing protocols. The gateway station deploys a border gateway node to handle the conversion and processing of low Earth orbit feeder link protocols and ground protocols by running feeder satellite–ground routing protocols. The controller is primarily used for the network control of the low Earth orbit constellation.

As shown in Figure 12, there are two physical prototypes of on-board switching equipment, each simulating two physical satellites in one orbital plane. Based on the research results of the twin platform virtual-to-physical interface presented in Section 5.4, the two physical satellites, L0106 and L0107, are connected to the different-orbit satellites L0206 and L0207 and the same-orbit satellites L0105 and L0108 through multiple network interfaces in the fully digital environment.

As shown in Figure 13, after initiating the controller and waiting for the convergence of the low Earth orbit constellation routing throughout the network, both the interface and the backend printout indicate that the controller can collect the complete constellation topology of the 50 satellites (including the two physical satellites).

Based on the virtual–physical interconnected fully digital low Earth orbit constellation twin verification environment shown in Figure 12, the main focus is on conducting functional tests for the interconnectivity of virtual and physical nodes. The satellite payload source 0106, connected to the physical satellite L0106, sends ping packets to the ground gateway (border gateway) with an IP address of 16.1.1.123. During ping packet transmission, the inter-satellite topology undergoes periodic changes based on the ephemeris. According to the ping packet display interface from the deployed functional model in the low Earth orbit constellation twin verification environment, the business communication is normal, without packet loss. Additionally, the latency varies dynamically with the relative positions of the satellites, ranging from 32.13 to 40.2 milliseconds, as shown in Figure 14 and Figure 15.

The protocol test results conducted in this environment indicate that by constructing a twin verification environment that converges with the actual system and supports virtual–physical interconnection, various virtual–physical interconnected testing and verification scenarios can be created. Building upon the first phase, this approach enables a higher level of maturity in validating the network protocol for low Earth orbit constellations. Furthermore, during the gradual construction of the constellation in the future, leveraging the designed and implemented digital twin system in this study will allow the simultaneous network authentication of satellites to be launched, the on-orbit testing of existing satellites, and the management of the bearer network and verification of the network protocol for the entire low Earth orbit constellation system composed of on-orbit satellites and digitally simulated satellites.

6.3. Twin Scenario Construction and Test Verification for “Phase 3”

The finalized LEO constellation digital twin system must undergo verification to ensure its capability to achieve the closed-loop control and optimization of the physical system. This verification process involves observing real-time changes in the twin system as the network state of the physical system fluctuates, through simulation data validation on the LEO constellation twin verification platform.

In order to meet the parallel formation flight requirements during the operational phase of the low Earth orbit constellation network in Phase 3, additional functionalities have been implemented based on the virtual–physical interconnected low Earth orbit constellation twin verification environment established in Phase 1. These new functionalities include the construction of a unified representation of the virtual–physical integrated network twin database, virtual–physical mapping interaction, and network digital twin visualization. These additions aim to fulfill the needs for the fine-grained monitoring of network elements and network operational situations, the visualization of low Earth orbit constellation network management, real-time closed-loop control, and the optimization of the network.

Regarding the Phase 3 digital twin prototype verification system shown in Figure 16, for the simulation of the physical low Earth orbit constellation network system, as the current stage is in the technical verification phase and there is no actual constellation system, it is not feasible to construct a physical low Earth orbit constellation scenario with such a large scale and frequent dynamic changes in network topology in a ground laboratory. Therefore, the simulation of the physical system directly utilizes the results obtained from the construction of the twin system in Phase 1, as shown in the right figure. The physical satellite network elements and protocol characteristics of the actual physical low Earth orbit constellation network are simulated through digitization. Similarly, for the simulation of the twin low Earth orbit constellation network system, a digitization approach is also employed, as shown in the left figure. The synchronization of network states in the virtual-physical environment is achieved through a database. A unified representation of the virtual-physical integrated network twin database is established between the physical system and the twin system. This database is used for the unified representation, storage, and cleansing of the data collected from the physical system. It also enables the twin system to read and use these data in near-real time to recreate the real network states, including the network topology, link latency changes, node failures, network traffic, and business conditions. Based on the reproduced network states, network prediction and optimization functionalities are realized in the digital twin environment.

Both the physical system and the twin system scenarios consist of 50 low Earth orbit satellites, 6 ground gateways, several satellite terminals, and 1 controller. Each low Earth orbit satellite deploys an onboard routing and switching node to forward data within and between satellites by running inter-satellite routing protocols. The satellite terminals simulate the network layer and above functionalities of real user terminal devices and achieve user access, service access, and inter-satellite handover functionalities by running user satellite-ground routing protocols. The ground gateways deploy border gateway nodes to handle the conversion and processing of low Earth orbit feeder link satellite-side link layer protocols and ground–side protocols by running feeder link satellite-ground routing protocols. Additionally, in the physical system, collection agent functional models are deployed at the satellites, ground gateways, and satellite terminals to collect information such as the device status, port rates, queue conditions, and specific business flow information from various network element nodes. The controller is primarily responsible for the network control of the low Earth orbit constellation. In addition, the controller in the physical system also deploys a collection and control module, which interacts with the collection agent modules deployed at the onboard routing, satellite terminals, and border gateways to collectively collect information on the device status, network situations, and business traffic in the low Earth orbit constellation network. The collected information can be stored in the database.

The database information exchange between the virtual and physical systems is illustrated in Figure 16. Leveraging this information, the twin system can provide near-real-time feedback on the network state from the physical system to the twin network, including the restoration of the network topology, node failures, and link anomalies, as shown in Figure 17, Figure 18 and Figure 19, respectively. In the synchronized collection of satellite node or inter-satellite link anomalies within the virtual-to-real LEO satellite constellation twin validation environment, the re-convergence of inter-satellite routing occurs, impacting the services passing through the affected nodes or links, as depicted in Figure 20, Figure 21, Figure 22 and Figure 23. Specifically, Figure 20 and Figure 22 illustrate the scenario wherein the business transmission delays vary due to node destruction or inter-satellite link anomalies, resulting in the switching of inter-satellite paths. Figure 21 and Figure 23 demonstrate that, on average, the convergence time for routing is 7.6 s in the case of node destruction and 7.48 s in the case of inter-satellite link anomalies, based on five test iterations.

The protocol testing conducted within this environment indicates that, subsequent to the twin system, the closed-loop control and optimization of the physical system can be achieved. Ultimately, this approach enables physical visualization, network simulation validation and inference, autonomous twin networking, and intelligent decision-making for the LEO satellite constellation network.

7. Conclusions

In this study, we develop a DT-enabled LEO satellite network to address the challenges of high trial-and-error costs and limited sensing capabilities. Specifically, we propose a network topology simulation method that dynamically analyzes the inter-satellite topology based on predefined ephemeris and orbit information. The proposed method allows for a deeper understanding of the structure and behavior of satellite constellations, enabling effective network design and optimization. Furthermore, we design a digital twin algorithm based on network virtualization, cloud platform management, and software-defined networking to validate and analyze the requirements of the twin system at different stages. It helps to identify potential issues and formulate optimized solutions. Finally, we construct a LEO satellite twin validation environment to verify the network protocols at various stages. Through extensive experimental evaluations, the performance of the twin system is demonstrated, showcasing its effectiveness in different scenarios.

The foundation for the creation of digital twins of low earth orbit constellations lies in establishing a low Earth orbit constellation twin system. Two primary mature technologies for this process are network simulation and physical entity simulation. However, neither of these two approaches can simultaneously meet the requirements for full-constellation high-fidelity simulation, low-cost implementation, and comprehensive lifecycle simulation. Therefore, our study innovatively introduces advanced methods such as network function virtualization, cloud platform management, and software-defined networking into the realm of network twinning. To achieve the twinning of the low Earth orbit constellation topology, network elements within the constellation are simulated using virtualization, and the network topology is simulated through SDN control flow tables. Subsequently, the low Earth orbit constellation twinning system is constructed based on these technical methods. In our future work, we will pursue the more accurate physical modeling of satellite activities by incorporating SAR images and change detection techniques into the digital twin formation procedure and considering more detailed parameters during state sampling and reconstruction [31].