Containerized high-fidelity inter-satellite link simulation method and system for geomagnetic storm phenomenon

Abstract

The invention relates to a containerized high-fidelity inter-satellite link simulation method and system for a geomagnetic storm phenomenon, and belongs to the technical field of satellite communication simulation. According to the method, distributed autonomous satellite nodes are constructed by adopting a container technology, orbit parameters of the nodes are corrected in real time by simulating disturbance of geomagnetic storm to the orbit, the spatial positions of the nodes are solved accordingly, and virtual inter-satellite links between the nodes are established. And the system dynamically calculates the link propagation delay and the packet loss rate based on the link budget model, and injects the result into the virtual link to realize the fine control of the link behavior. Meanwhile, the system supports link dual-channel shunting, neighbor discovery and state broadcasting, bit error rate-packet loss rate conversion and network adaptive scheduling, and can truly reflect the influence of space environment disturbance on the satellite network performance. The simulation method has high expansibility and accurate physical layer modeling capability, and is suitable for application scenes such as constellation design verification, protocol testing and anti-interference mechanism evaluation.

Description

Technical Field

[0001] This invention belongs to the field of satellite communication simulation technology, and relates to a containerized high-fidelity inter-satellite link simulation method and system for geomagnetic storm phenomena. Background Technology

[0002] With the large-scale deployment of low-Earth orbit satellite constellations, inter-satellite links have become a key supporting technology for improving satellite internet coverage and communication timeliness. However, the stability of inter-satellite links is limited by a variety of dynamic factors. First, the high speed of satellite operation and the periodic changes in orbit cause frequent changes in the link topology; second, the long space propagation distance and large free-space loss place high demands on the accuracy of link budgeting; third, geomagnetic storms, which are significantly affected by solar activity, often lead to atmospheric expansion, resulting in orbital decay and satellite reentry, severely interfering with link availability and latency stability. In particular, the "Cannon Super Geomagnetic Storm" event that occurred in May 2024 resulted in the failure or forced deorbiting of hundreds of satellites worldwide, further exposing the destructive impact of space environment disturbances on constellation network operation.

[0003] Figure 1 This diagram illustrates the centralized architecture of an existing satellite simulation system. To reduce costs and improve flexibility, simulation methods are widely used to evaluate the operational performance of constellation systems. However, existing simulation tools have significant limitations: on the one hand, network simulation platforms such as NS-3 and OMNeT++ experience a surge in computational resource consumption when faced with large-scale node deployments, making it difficult to support real-time simulations with tens of thousands of nodes; on the other hand, existing models mostly use static parameter settings, ignoring the dynamic evolution of link error rates and propagation delays, and especially lacking effective modeling of orbital disturbances and link degradation caused by geomagnetic storms, leading to discrepancies between simulation results and real-world operational scenarios.

[0004] In addition, most traditional tools adopt a centralized computing architecture, with satellite nodes relying on a central server to obtain link status. They lack autonomous awareness and real-time collaboration capabilities, which is not conducive to simulating complex network protocols and intelligent routing mechanisms.

[0005] In summary, existing inter-satellite link simulation schemes are insufficient to meet the high-precision, large-scale, and autonomous simulation requirements in dynamic space environments. There is an urgent need for a high-fidelity inter-satellite link simulation technology system with a distributed architecture, capable of simulating environmental disturbances and supporting dynamic link control, in order to support the verification and optimization of key technologies for future satellite internet. Summary of the Invention

[0006] In view of this, this invention addresses the problems of poor stability of inter-satellite links under geomagnetic storm disturbances, lack of environmental awareness in existing simulation methods, low simulation granularity, and weak scalability. It proposes a containerized high-fidelity inter-satellite link simulation method and system for geomagnetic storm environments, aiming to improve the modeling, evaluation, and disturbance rejection design capabilities of constellation networks in complex space environments.

[0007] One objective of this invention is to construct a simulation architecture that supports dynamic perception of space weather, simulation of autonomous node behavior, and precise injection of link damage, thereby solving the resource bottlenecks and behavior distortion problems existing in the current centralized simulation platform.

[0008] To achieve the above objectives, the present invention proposes the following technical solution:

[0009] A containerized high-fidelity inter-satellite link simulation method for geomagnetic storm phenomena, suitable for simulating satellite communication behavior under geomagnetic storm conditions, includes the following steps:

[0010] S1: Construct multiple container-based autonomous satellite nodes;

[0011] S2: Correct the orbital parameters of satellite nodes using a perturbation model;

[0012] S3: Based on the corrected orbital parameters, obtain the dynamic position of each node in real time and broadcast it;

[0013] S4: Establish virtual links between multiple satellite nodes;

[0014] S5: Based on node location and link budget model, dynamically calculate link propagation delay and packet loss rate, and configure them to the corresponding link.

[0015] Furthermore, the disturbance model calculates orbital disturbances based on space weather parameters, including but not limited to solar radio flux and geomagnetic index.

[0016] Furthermore, the calculation of the packet loss rate includes: obtaining the link received power, calculating the bit energy-to-noise ratio, and obtaining the corresponding bit error rate based on the modulation and demodulation method, thereby estimating the packet loss rate.

[0017] Furthermore, following S4, the following is also included:

[0018] A dual-channel link structure is established, separating the state control flow from the service data flow. The propagation delay and packet loss rate only apply to the service channel.

[0019] Furthermore, the virtual links are constructed through virtual network interfaces, and each virtual link is configured with an independent subnet. The IP addresses assigned to the two interfaces of each virtual link satisfy the following conditions: these two IP addresses maintain a fixed interval, and the last digit of one IP address is odd, while the last digit of the other IP address is even. These two IP addresses can be consecutive or non-consecutive, as long as they maintain a fixed interval. For example, with a fixed interval of 1, one IP address ends in 1 and the other in 2; with a fixed interval of 3, one IP address ends in 1 and the other in 4.

[0020] Furthermore, the simulation method further includes link awareness based on a neighbor discovery mechanism and synchronizing the status information of nodes through inter-node broadcasting.

[0021] Furthermore, the calculation of the packet loss rate includes the following steps:

[0022] a) Calculate the received power P based on the link budget model. R ;

[0023] b) According to the P R Calculate the bit energy-to-noise ratio E b / N0, its calculation formula is:

[0024] E b / N0=P R -10log 10 (kT s )-10log 10 (R b )

[0025] Where k is the Boltzmann constant, T s R represents the system noise temperature. b For bit rate;

[0026] c) Based on the preset modulation and demodulation method and the calculated E b / N0, calculate the corresponding bit error rate (BER);

[0027] d) Calculate the packet loss rate PLR ​​based on the BER and the number of bits N in the data frame, using the following formula:

[0028] PLR = 1 - (1 - BER) N .

[0029] Furthermore, after S4, it also includes:

[0030] The flow control (TC) tool is used to establish control and service channels on the virtual inter-satellite link.

[0031] Control traffic containing status information is directed to the control channel, and service data traffic is directed to the service channel;

[0032] The propagation delay and packet loss rate are injected into the service channel, while the control channel is unaffected by the injection.

[0033] Furthermore, the virtual inter-satellite links are established on VETH based on virtual Ethernet devices, and each virtual inter-satellite link is assigned an independent subnet.

[0034] Furthermore, the simulation method also includes:

[0035] Directly connected satellite nodes are identified through a periodic neighbor discovery mechanism;

[0036] State synchronization is achieved by broadcasting state information among the distributed autonomous nodes, and the state information includes at least the node position coordinates and velocity vectors.

[0037] A containerized high-fidelity inter-satellite link simulation system for geomagnetic storm phenomena includes:

[0038] A containerized satellite node cluster, consisting of multiple autonomous satellite nodes built on containers, each satellite node comprising:

[0039] The orbit calculation module is used to obtain the orbit parameters of this node and simulate the impact of geomagnetic disturbances on it, thereby correcting the orbit parameters;

[0040] The configuration module, connected to the track calculation module, is used to calculate the link propagation delay and packet loss rate based on the corrected track parameters and the status information of neighboring nodes, and to generate link parameter configuration instructions.

[0041] The link control engine, connected to the configuration module in the multiple satellite nodes, is used to receive the configuration instructions and configure the corresponding propagation delay and packet loss rate into the virtual inter-satellite link established between the nodes.

[0042] Furthermore, the orbit calculation module receives space weather parameters and calls an atmospheric physics model to obtain atmospheric density disturbances, thereby achieving dynamic correction of the orbit parameters.

[0043] Furthermore, the configuration module calculates the bit error rate based on the link budget model, node location relationships, and modulation scheme, and further derives the packet loss rate.

[0044] Furthermore, the link control engine supports dual-channel configuration of the link, wherein the propagation latency and packet loss rate are configured only for the service channel, and the control channel is unaffected.

[0045] Furthermore, the location calculation module simulates geomagnetic storm disturbances by inputting geomagnetic storm parameters, including the solar radio flux F10.7 and the three-hour geomagnetic index Ap, and calling an atmospheric physics model to calculate atmospheric density changes in order to correct the orbital parameters.

[0046] Furthermore, the dynamic configuration module calculates the packet loss rate in the following way: calculating the bit energy-to-noise ratio E. b / N0; according to the E b The bit error rate (BER) is calculated based on / N0 and the corresponding modulation / demodulation scheme; and the packet loss rate (PLR) is calculated based on the BER and the number of data frame bits N, using the following formula:

[0047] PLR = 1 - (1 - BER) N .

[0048] The beneficial effects of this invention are as follows:

[0049] (1) The containerized design allows each node to run independently and perform collaborative simulation, effectively solving the resource bottleneck of the centralized simulation platform in large-scale scenarios.

[0050] (2) For the first time, a geomagnetic storm disturbance modeling mechanism was introduced, which integrates atmospheric physical models and space weather data to construct a coupled model of orbital attenuation and link degradation, and realizes closed-loop modeling of damage transmission chain from the physical layer to the network layer.

[0051] (3) Supports dynamic behavior evolution of simulated links: propagation delay and packet loss rate can be updated in real time as the trajectory changes, significantly improving simulation accuracy and meeting the needs of protocol testing and intelligent routing algorithm verification.

[0052] (4) Enhance the robustness design capability of constellation system against interference, provide key support for the evaluation of anti-interference strategies and the development of emergency mechanisms for low-Earth orbit constellations, and reduce design risks and test costs before actual deployment.

[0053] Other advantages, objects, and features of the present invention will be described in part in the following description and, in part, will be apparent to those skilled in the art upon examination of the following description or may be learned from practice of the present invention. The objects and other advantages of the present invention may be realized and obtained through the following description. Attached Figure Description

[0054] To make the objectives, technical solutions, and advantages of the present invention clearer, the preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings, wherein:

[0055] Figure 1 A schematic diagram of the centralized architecture of an existing satellite simulation system;

[0056] Figure 2 This is a simulation structure model diagram used to construct the virtual link in this invention;

[0057] Figure 3 This is a schematic diagram of the point-to-point inter-satellite communication mechanism used in this invention;

[0058] Figure 4 This is a schematic diagram of the broadcast communication architecture used in this invention;

[0059] Figure 5 This is a functional framework diagram of the link budget and packet loss rate calculation mechanism of the present invention;

[0060] Figure 6 This is an overall flowchart of the containerized inter-satellite link simulation method of the present invention;

[0061] Figure 7 This is a structural diagram of the module composition of the containerized inter-satellite link simulation system of the present invention. Detailed Implementation

[0062] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0063] The accompanying drawings are for illustrative purposes only and are schematic diagrams, not actual pictures. They should not be construed as limiting the invention. To better illustrate the embodiments of the invention, some parts in the drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions. It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.

[0064] In the accompanying drawings of the embodiments of the present invention, the same or similar reference numerals correspond to the same or similar components. In the description of the present invention, it should be understood that if terms such as "upper," "lower," "left," "right," "front," and "rear" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms used to describe positional relationships in the drawings are only for illustrative purposes and should not be construed as limiting the present invention. For those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.

[0065] The containerized high-fidelity inter-satellite link simulation method described in this invention is designed for modeling the distributed communication behavior of large-scale satellite constellations, and is particularly suitable for dynamic evolution simulation of link damage effects under geomagnetic storm disturbances.

[0066] The method includes the following steps:

[0067] S1: Satellite Container Node Construction

[0068] Each satellite node is instantiated as an independently running autonomous node using Linux container technology. Each container contains a communication protocol stack, orbital position calculation capabilities, and link configuration interfaces, and is deployed on a host cluster to form a basic platform for satellite constellation simulation that supports high concurrency.

[0069] S2: Orbital correction driven by geomagnetic disturbance

[0070] To simulate orbital disturbances caused by geomagnetic storms during solar activity, the system incorporates space weather parameters, including solar radio flux (F10.7) and the three-hour geomagnetic index (Ap). The orbit correction module calculates the density changes after the disturbance based on an atmospheric model, derives the semi-major axis decay value, and corrects the TLE orbital elements of the satellite nodes, thus achieving dynamic orbit updates.

[0071] S3: Inter-satellite link construction and offloading configuration

[0072] A point-to-point virtual interface is built between different container nodes using the Linux VETH mechanism to simulate physical link connections. After the link is established, the system uses the TC flow control tool to split the traffic, building separate control and service channels. The control channel carries core information such as state synchronization and routing, while the service channel dynamically injects propagation latency and packet loss rate according to the link impairment model.

[0073] S4: Neighbor Discovery and Status Broadcasting Mechanism

[0074] Each node periodically traverses its own interface, identifies directly connected neighbor nodes, and constructs a neighbor dictionary. It then broadcasts node status information, including fields such as location, speed, and transmit power, at fixed intervals. The broadcast uses UDP or ZMQ mechanisms, and the receiver parses the neighbor data and updates its link configuration, achieving bidirectional dynamic coordination of link states between nodes.

[0075] S5: Link-budget-driven dynamic impairment injection

[0076] The system calculates received power and signal-to-noise ratio based on a link budget model, combined with physical parameters such as inter-node distance, antenna gain, and transmit power. It derives the bit error rate (BER) based on the modulation scheme and calculates the packet loss rate (PLR) based on the data frame structure. Simultaneously, it calculates the link distance based on the real-time node locations and converts this to the propagation delay (Delay).

[0077] The system injects the aforementioned Delay and PLR into the VETH interface between containers via the TC command to achieve simulated injection of link impairment.

[0078] Furthermore, the aforementioned S1 specifically includes:

[0079] S11: Satellite Container Image Customization. Builds images for the runtime environment of satellite container nodes, featuring satellite constellation simulation scenarios that mimic complex routing behavior.

[0080] 1) Network routing capability: Based on FRR, it can run routing protocols and simulate routing behavior in satellite networks.

[0081] 2) Orbit calculation: Calculate satellite positions using the Skyfield library.

[0082] 3) Network configuration: Use the Pyroute2 library to configure network interfaces (such as VETH devices), IP addresses, routes, flow control, etc. (TC sets latency and packet loss rate).

[0083] 4) Scientific computing: NumPy and SciPy are used for complex mathematical calculations (such as link budgets, energy models, etc.).

[0084] 5) Network testing: Ping is used for network performance testing, to dynamically verify latency and packet loss rate.

[0085] The underlying system of the image is based on Alpine Linux (a lightweight Linux distribution). The base image frrouting / frr:latest provides a complete FRRouting suite (an open-source network routing protocol stack), offering professional routing protocol stacks (OSPF / BGP, etc.), enabling routing functionality for multiple satellite container nodes, and simulating satellite internet routing behavior. A Python interpreter is installed on top of the base image for the design of subsequent satellite communication logic; the skyfield astronomical computing library is installed for the subsequent position module to calculate satellite orbital positions; and the pyroute2 library is installed, a Python library for Linux network configuration (used to configure network interfaces, routing, etc.).

[0086] S12: Based on the satellite container image already built in S11, it adopts an automated container orchestration mechanism to achieve rapid startup and deployment of multiple satellite nodes, and supports the simulation of large-scale satellite constellation networks.

[0087] 1) Node instantiation and namespace isolation: Multiple container instances are automatically generated based on the simulation configuration file using Docker or a similar container engine. Each instance represents an independent satellite with complete isolation of resources such as processes, networks, and file systems, ensuring that each satellite node has autonomous capabilities.

[0088] 2) Time Synchronization and Startup Scheduling: A unified startup clock is introduced for the containers to ensure that all satellite container nodes run synchronously according to the predetermined orbit time, guaranteeing the consistency of simulation logic. A standard time zone environment, such as environment:TZ:Asia / Shanghai, is also designed. During startup, batch scheduling and parallel deployment can be performed via Python scripts, improving the startup efficiency of large-scale simulations.

[0089] 3) Runtime monitoring and control interface: Each container node can expose a control interface (such as WebSocket or RESTAPI) to allow external control platforms to dynamically adjust node behavior, modify routing policies, inject link faults, or execute test commands, supporting real-time interaction and adjustment of experimental scenarios.

[0090] 4) Mounting shared data volumes between containers and the host: To enable dynamic loading and reusability of simulation configurations and business logic, a data volume mounting mechanism between containers and the host is supported. During service orchestration, in the container creation phase, application code and configuration files (such as TLE files, configuration parameters of satellite transmitters and receivers, bandwidth configurations, operating wavelengths in the communication system, and some convenient service function scripts, etc.) in the host directory are mounted to a specified path inside the container, enabling direct access and updates of external files during container runtime.

[0091] 5) Physical Cluster-Based Distributed Container Deployment Strategy: To support high-fidelity simulation and parallel processing capabilities for large-scale constellation systems, the container startup mechanism is optimized for distributed physical computing clusters. The system dynamically plans the deployment location of containers within the cluster based on the network interaction frequency, resource requirements (CPU / memory / network I / O), and actual geographical distribution characteristics of each satellite node in the simulation task, thereby improving simulation efficiency and network communication simulation accuracy.

[0092] Furthermore, the aforementioned S2 specifically includes

[0093] S21: Orbit Data Distribution and Identification Mechanism: The system uses a central server as the unified scheduling node for orbit data, responsible for managing the orbit parameter resources of each satellite node. During the node initialization phase, the central server issues a unique NORAD identifier and the corresponding TLE orbit data to each satellite container node.

[0094] After receiving orbit data, the node container persists it to a specified local directory. The naming convention for orbit data files includes satellite identifiers, facilitating automatic binding of identity and orbit parameters within the container. It also supports remote orbit database integration, incremental update mechanisms for central orbit data files, and on-demand configuration policy distribution, providing support for dynamic satellite deployment and orbit change simulation.

[0095] S22: Real-time calculation and update mechanism for orbital state. Each satellite node calculates its orbital state in real time based on the received TLE file using a self-developed position module. This module integrates the open-source orbital mechanics library Skyfield and the SGP4 algorithm, supporting high-precision calculation of three-dimensional position and velocity vectors in geocentric inertial (ECI) frames.

[0096] The module has the following capabilities:

[0097] 1) Real-time update mechanism: The satellite status at the current UTC time is calculated periodically at fixed time intervals (default every second) through an internal daemon thread;

[0098] 2) Multi-coordinate system support: Supports returning multiple types of satellite orbital status information, such as ECI coordinates, geographic latitude and longitude, altitude, and velocity vector;

[0099] 3) File-driven and track data self-discovery mechanism: The module supports periodic polling of the local track file directory. Once a new valid TLE file is found, it is automatically loaded, replacing the old track parameters and re-initializing. The track parameters are the TLE files.

[0100] 4) Fault self-recovery mechanism: When an anomaly occurs in the orbit calculation or data is interrupted, the module keeps the most recent valid solution result as a cache and continues to provide service response, ensuring the stability and robustness of the simulation system during operation.

[0101] S23: Geomagnetic storm satellite orbit decay mechanism based on atmospheric model (difference correction).

[0102] This system proposes a "TLE parameter differential correction mechanism" based on atmospheric modeling and orbit perturbation theory to simulate the direct disturbance effect of geomagnetic storm events on satellite orbits. It also performs fine-tuning corrections on existing TLE orbit data to generate orbit input data that more closely approximates real disturbance conditions.

[0103] This mechanism starts with a set of real or simulated TLE orbit data, extracting key parameters such as the orbit's semi-major axis (or average motion) as the reference orbit for disturbance calculation. The system simultaneously incorporates space weather data during geomagnetic storms as the disturbance source input, including:

[0104] F10.7 daily radio flux;

[0105] Ap three-hour geomagnetic index;

[0106] Duration of geomagnetic disturbance (e.g., 24 hours, 48 ​​hours);

[0107] Basic physical parameters of the satellite: mass m, cross-sectional area A along the satellite's flight direction. ref Drag coefficient C D wait.

[0108] Where the drag coefficient C D It is related to the satellite's geometry, panel material, atmospheric temperature at its altitude, and atmospheric composition; its expression is:

[0109]

[0110] k represents the total number of satellite panels, i represents the panel number in the decomposition, α is an adjustment coefficient that depends on the collision mode between atmospheric molecules and satellite panels (e.g., 0.93 provided by the SWARM satellite), and T w,i This refers to the temperature of each panel on the satellite.

[0111] The system calls atmospheric models (such as JB2008 or NRLMSISE-00) to calculate respectively:

[0112] 1. Under normal (quiet) atmospheric conditions, the target orbital altitude and atmospheric temperature and density ρ quiet

[0113] 2. Density ρ obtained after inputting disturbance parameters during a geomagnetic storm. strom

[0114] Based on this, the atmospheric density perturbation factor is constructed: Δρ=ρ strom -ρ quiet Furthermore, the system calculates the average semi-major axis of the track caused by the disturbance. in This is the average semi-major axis of the satellite under the original TLE.

[0115] This allows for the modification of satellite orbital characteristic data in TLE, and based on the file-driven and orbital data self-discovery mechanism in S22 (8), the modified .tle file can be dynamically loaded into the system model.

[0116] S24: Standardized service interface access mechanism. To achieve modular design and cross-component interoperability, the location module integrates the ZeroMQ lightweight messaging middleware (ZMQ for short), exposing a standard request interface to the outside. Other functional modules (such as link calculation, scheduling module, inter-satellite communication simulation module, etc.) can obtain the orbital status information of the current satellite node by sending specific commands.

[0117] The module supports instructions including but not limited to:

[0118] 1) pos: Get the current UTC timestamp and its corresponding 3D spatial coordinates (unit: meters).

[0119] 2) latlon: Gets the current geographic latitude and longitude information

[0120] 3) alti: Get the current altitude above the ground (unit: kilometers)

[0121] 4) vel: Obtain the three-dimensional velocity vector (unit: meters per second)

[0122] 5) Power: Get the current transmitter's transmit power (unit: watts)

[0123] 6) all: Retrieves a complete snapshot of all the above orbital status data.

[0124] The interface adopts a request-response structure, supports concurrent access and error handling, and retains the interface's extensibility, allowing for the flexible addition of other status query items or control commands according to the needs of the simulation scenario.

[0125] Furthermore, the aforementioned S3 specifically includes

[0126] S31: VETH Virtual Link Pair Construction and Naming Mechanism. The system creates a pair of VETH virtual Ethernet devices for each pair of satellite nodes on the Linux host machine, assigning both ends to the corresponding container namespaces, thereby achieving direct link connections between containers and forming simulated inter-satellite data channels. The naming rules for each link pair are as follows:

[0127] The naming format is: isl- <norad1> - <norad2>,in <norad1>and <norad2>The NORAD identifier for both satellites; for TLE, NORAD is... <norad1>The container node has a local device name of isl- <norad1> - <norad2>For the TLE on the other end, NORAD is <norad2>The satellite node, whose container contains the VETH interface is named isl- <norad2> - <norad1>This ensures that the naming is symmetrical and unique.

[0128] By using a unified naming convention, interface binding and container identification can be completed quickly, improving the automation and maintainability of link management.

[0129] S32: Virtual Link and Interface Address Configuration Mechanism. To simulate the point-to-point connection structure of real inter-satellite physical links, the system uses VETH virtual network interface cards to build independent communication channels for each pair of satellite nodes, and implements a unified IP address allocation strategy to facilitate the link communication and topology identification construction and configuration process. Figure 2 As shown.

[0130] 1) VETH Interface Naming and Mounting:

[0131] Each pair of ISL (Inter-Satellite Link) corresponds to a pair of virtual network interface cards (NICs) placed at opposite ends of two satellite containers, as shown in the diagram above. The naming convention is isl-NORAD1-NORAD2 and isl-NORAD2-NORAD1, where NORAD is a unique identifier for each satellite node. This naming strategy ensures naming symmetry and predictability, facilitating unified identification of interface correspondences both inside and outside the containers.

[0132] 2) Subnetting and IP address allocation strategies:

[0133] The system maintains a global address allocation counter and independently allocates a / 30 subnet (i.e., 4 IP addresses) for each ISL. The address usage rules in this subnet are as follows:

[0134] The first address (e.g., 10.0.0.0): subnet address, reserved;

[0135] The second address (e.g., 10.0.0.1): the interface address of satellite node A;

[0136] The third address (e.g., 10.0.0.2): Satellite node B interface address;

[0137] The fourth address (e.g., 10.0.0.3): broadcast address, used for control signaling broadcast mechanisms such as UDP broadcast or multicast messages / ZMQ publish-subscribe communication;

[0138] 3) Automatic derivation and peer address identification:

[0139] This address allocation rule has the following advantages:

[0140] Each virtual link uses only 4 IP addresses, saving IP overhead for the entire constellation. All link IPs fall within the starting address range that is an integer multiple of 4. The broadcast address is always the starting address + 3, making it mathematically deterministic to determine whether it is a broadcast address.

[0141] Moreover, the VETH interface address of the peer container can be derived from the IP address of any interface by simply adding or subtracting one (±1). (If the last digit of the IP address of this container is odd, such as 10.0.0.1, then the IP address of the peer container is increased by 1 to get 10.0.0.2. If the last digit of the IP address of this container container is even, such as 10.0.0.2, then the IP address of the peer container is decreased by 1 to get 10.0.0.1.) No additional table lookup or intermediate proxy is required.

[0142] When conducting satellite communication, the system can query the interface name through the NORAD number, and then deduce the local and peer IPs to achieve rapid resolution of operations such as pinging neighboring satellites and building adjacency lists.

[0143] S33: Initial flow control configuration and service diversion mechanism for the link. After the link is established, the system automatically calls the initialization script to configure the basic link status (such as bandwidth, latency, packet loss rate, etc.) for the corresponding interface, simulating the basic physical characteristics and service diversion strategy in the free space link.

[0144] The configuration logic is as follows:

[0145] 1) Bandwidth and latency settings:

[0146] Using the Linux.TC (Traffic Control) tool, set initial bandwidth limits (e.g., 500 Mbit), transmission delay (e.g., 10 ms), and packet loss rate (e.g., 5%) for the interface. Use the HTB queue scheduler and NetEM simulator to build the control path and achieve a realistic link load control effect.

[0147] 2) Dual-channel strategy:

[0148] The system predefines two types of traffic in the links: one is broadcast control traffic (such as location, routing, and ZMQ communication), and the other is traffic data flow based on link budget. First, a root queue 1 is created, and two sub-queues (1:20 and 1:10) are configured under the root queue. By configuring the TC filter, data passing through ports specifically used for state information propagation (such as 5005, 5555, and 5556) is allocated to the higher-priority, unrestricted "control" channel (1:10), while other default traffic is allocated to the traffic flow rate-limited channel (1:20), forming a dual-channel network structure with differentiated scheduling capabilities for control traffic diversion.

[0149] Link state cleanup and reconstruction:

[0150] Since the script will only be executed after the VETH is built for the first time, it will automatically clear the old qdisc configuration on the original interface before execution to avoid superimposed interference when the link is rebuilt or the parameters are updated, and to ensure the consistency of the link status.

[0151] Adapting to container dynamic network structures:

[0152] All configuration operations are executed through the host machine, which can adapt to the dynamic generation and destruction of containers without the need for internal container intervention, making it easy for the cluster management system to orchestrate uniformly.

[0153] This mechanism provides the foundation for subsequent dynamic adjustment of link status (such as updating latency / packet loss rate as distance changes) and QoS simulation. It can also be used to support functional modules such as link-state-based routing algorithm simulation and fault injection. Figure 3 This is a simulation architecture for point-to-point inter-satellite links.

[0154] Figure 4 S4 is a broadcast communication architecture, specifically including...

[0155] S41: Neighbor Discovery and Maintenance Mechanism. The system utilizes the VETH interface rules built in S3, scanning all local network interface names within each container using Linux network commands or the pyroute2 tool in Python, and filtering for those that conform to isl- <norad1> - <norad2>The interface with the specified naming format represents the direct connection link that has been established on this node.

[0156] For each ISL interface:

[0157] The local node can extract the NORAD number of the peer satellite by resolving the interface name;

[0158] All discovered interfaces form a neighbor dictionary structure, with the key being the peer node's NORAD and the value being the corresponding local interface name;

[0159] Neighbor interface information can be used for: selecting the target interface for status broadcasts; verifying the source of broadcast messages; and configuring link orientation after receiving messages.

[0160] The neighbor list structure is rebuilt each time the container starts, and new neighbor satellites and disconnected neighbor satellites are periodically scanned during communication to ensure that the neighbor list is true and reliable, thus adapting to dynamic link topology adjustments (such as simulation scenarios of dynamic changes in inter-satellite links).

[0161] S42: State Information Broadcast Mechanism. After the neighbor list is determined, each node iterates through all its ISL interfaces at a fixed interval (e.g., 1 second), broadcasting its current state information to each neighbor. The broadcast mechanism uses UDP unicast or broadcast send / publish-subscribe methods, and the receiver always listens on a fixed port for state synchronization.

[0162] The broadcast information field contains the following:

[0163] Timestamp: UTC format, used to identify the freshness of data;

[0164] Sending interface name (iface): such as isl-12345-67890, used by the receiver to identify the source;

[0165] Position coordinates: Geocentric inertial coordinates (unit: meters) obtained by calling the position module;

[0166] Velocity vector: Current 3D velocity (unit: meters per second);

[0167] Transmit power (tx_power): The current simulated signal transmit power of the node (unit: dBm or W);

[0168] Node identifier (norad_id): The NORAD number of the current broadcast node;

[0169] Link validity flag (optional): Used to mark whether the current link is valid, or for bandwidth estimation, etc.

[0170] S43: Broadcast message reception and link adaptation mechanism. To achieve dynamic awareness and adaptive configuration of link status between satellite nodes, each container node continuously listens to a fixed port (e.g., 5556), receives status information broadcast by its neighboring nodes in real time, and adjusts its local link parameters accordingly, realizing bidirectional peer-to-peer collaborative updates of point-to-point links in a distributed architecture.

[0171] The specific process includes the following key steps.

[0172] 1) Listening and message parsing mechanism

[0173] Each container node runs a persistent listening thread, bound to a specified UDP or ZMQ port (such as 5556), to continuously receive JSON status messages periodically broadcast by other nodes.

[0174] Based on the description of the broadcast information in S42, we know that the received broadcast message contains the following fields:

[0175] timestamp: Message timestamp

[0176] iface: The name of the sender's ISL interface (e.g., isl-NORAD2-NORAD1)

[0177] norad_id: Sender node number (NORAD2)

[0178] position, velocity, tx_power: Sender status information

[0179] 2) Reverse the interface name and match it with the local interface.

[0180] Since broadcast / subscribe messages carry the sender's interface name (i.e., the interface name within the sending container), its format is:

[0181] isl-NORAD2-NORAD1

[0182] The local interface name corresponding to this node (NORAD1) is:

[0183] isl-NORAD1-NORAD2

[0184] Therefore, when performing link configuration, the system needs to automatically reverse the received iface string, that is:

[0185] After receiving the interface name is isl-NORAD2-NORAD1 in the neighbor broadcast message, it is necessary to change the position of xy in isl-xy, thus obtaining isl-NORAD1-NORAD2.

[0186] In this way, the local node can accurately identify the VETH interface corresponding to the status message, and thus correctly find the corresponding VETH interface in the container to apply TC and other link configuration operations.

[0187] 3) The state injection link module performs self-configuration.

[0188] After the interface is parsed, the system will extract the following from the broadcast:

[0189] Neighbor position

[0190] Neighbor velocity

[0191] Neighbor transmit power (tx_power)

[0192] Local corresponding interface name (local_iface)

[0193] The data is encapsulated into structured data and then passed to the local ISL module (link management module) for processing. The ISL module will jointly calculate the link parameters based on the current state of the local node and the states of its neighbors.

[0194] This mechanism enables container nodes to adaptively adjust links solely through broadcasting without centralized scheduling. It features high decoupling and strong scalability, and is the core technical path for simulation systems to support complex self-organizing network behavior.

[0195] Furthermore, the aforementioned S5 specifically includes

[0196] S51: Propagation delay calculation and configuration mechanism. When simulating inter-satellite links between containers, the system converts the propagation delay of the actual physical link into transmission control configuration on the virtual network interface (VETH).

[0197] The calculation method is as follows:

[0198] Use the location module to obtain the current node's position;

[0199] Extract the location of the peer node from the received neighbor broadcast message;

[0200] Calculate the three-dimensional Euclidean distance d (unit / meter) between the two;

[0201] Calculate the propagation delay based on the speed of light c = 299,792,458 m / s:

[0202]

[0203] The above formula is used to generate a triple containing the IP address, latency (ms), and interface name, providing parameters for the TC tool to inject latency.

[0204] S52: Link budget and configuration mechanism for packet loss rate. The system further calculates the link bit error rate (BER) based on the communication theory model and inter-satellite link budget, and derives the packet loss rate (PLR) in combination with the data frame length, which is used to dynamically control the packet loss performance of the inter-container link.

[0205] Figure 5 This is the architecture for the link budget model.

[0206] The mechanism first calculates the effective equivalent isotropic power (PR) at the receiver based on the following power budget model:

[0207] 1) Transmitter equivalent isotropic radiated power (TxEIRP):

[0208] TxEIRP=P T +G t +L txother +L txfeeder

[0209] Where P T G is the transmit power (in dBW). t L is the transmit antenna gain (in dB). txother For other transmitter losses such as modulators, interfaces, etc. (in dB), L txfeeder Transmitter feeder loss (in dB).

[0210] 2) Equivalent isotropic power received by the receiver (RxEIRP):

[0211] RxEIRP=TxEIRP-L P -L Pol -L Int -L Mis

[0212] Among them L P L represents the free space path loss (in dB). Pol For polarization loss (in dB), L Int Interference loss (in dB), L Mis Loss caused by pointing error (in dB).

[0213] The specific free space path loss (FSPL) is used to characterize the energy attenuation caused by diffusion during the propagation of the transmitted signal in a vacuum. Its calculation formula is as follows:

[0214] (Unit: dB)

[0215] d: Distance between transmitter and receiver (in meters), λ: Signal wavelength (in meters), which can be derived from the wavelength formula:

[0216]

[0217] We can deduce that c is the speed of light, which is 299,792,458 m / s, and f is the carrier frequency (unit: Hz).

[0218] 3) Receiver receiving power:

[0219] P R =RxEIRP+G r -L rxoher -L rxfeeder

[0220] Where G is r Receive antenna gain, L rxoher For the loss within the receiver system, L rxfeeder This refers to the receiver feeder loss.

[0221] 4) Carrier noise density ratio and bit energy noise density ratio:

[0222] After obtaining P R Then, the system introduces noise power modeling to further calculate the signal-to-noise power density ratio (Carrier-to-Noise Ratio, C / N0):

[0223] Where the noise N0 can be considered, the thermal noise caused by the equivalent problem can be taken into account, and the overall...

[0224] C / N0 = P R -N0=P R -10log 10 (kT s )

[0225] Among them, P R The received power is expressed in dBW, where k is the Boltzmann constant, approximately 1.38 × 10⁻⁶. -23 J / K. T s The system's equivalent noise temperature (in Kelvin) is then considered. Next, the system incorporates the communication bit data rate R. b (Unit: bps), Derive the Energy per Bit to Noise Density Ratio (E b / N0):

[0226] E b / N0=C / N0-10log 10 (R b )

[0227] Where the data rate R b It directly affects the reliability of data transmission in the link and is the core determinant of bit error rate and modulation performance.

[0228] 5) Mechanism for deriving bit error rate and packet loss rate:

[0229] In obtaining E b After / N0, the system derives the bit error rate (BER) based on the currently used modulation scheme. In this embodiment, OOK (On-Off Keying) modulation is used as an example, and its theoretical BER is expressed as:

[0230]

[0231] Where erfc(·) represents the complementary error function, which reflects the bit error probability caused by the random bit energy error distribution in a Gaussian white noise channel.

[0232] Furthermore, based on the data link layer frame structure and the number of bits per frame N (i.e., frame_bits, for example, assuming each frame has 1460 bytes, representing N = 1460 * 8 = 11680 bits), the system derives the packet loss rate (PLR) of the frame under the current bit error rate:

[0233] PLR≈1-(1-P e ) N

[0234] This model assumes that any bit error is considered as an unusable data frame, and is suitable for laser communication or other low-redundancy fault-tolerant scenarios in high-speed inter-satellite links.

[0235] S53: Joint Configuration Injection Mechanism for Link Budget Results. After obtaining the link budget results, to improve link configuration efficiency and system response performance, the system designs a joint injection mechanism based on propagation delay and packet loss rate. This mechanism, after calculating the link distance and bit error rate, simultaneously injects two key link parameters through a single TC command, thereby achieving rapid configuration of the virtual interface transmission characteristics.

[0236] As shown in the following code:

[0237] TC qdisc change dev isl-12345-67890parent 1:20handle 20:netem delay5ms loss 1.2%

[0238] Avoid calling TC commands multiple times, reducing system context switching and control path burden; ensure that latency and packet loss rate configurations are always based on the link state at the same moment; simplify link control logic, facilitating debugging, reproduction, and maintenance; suitable for real-time configuration updates in frequently changing satellite constellation link environments.

[0239] Figure 6 This is a schematic diagram of the method flow of the present invention;

[0240] Figure 7 This is a system architecture diagram of the present invention.

[0241] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention. < / norad1> < / norad2> < / norad1> < / norad1>

Claims

1. A containerized high-fidelity inter-satellite link simulation method for geomagnetic storm phenomena, applicable to simulating satellite communication behavior under geomagnetic storm conditions, characterized in that: The steps include: S1: Construct multiple container-based autonomous satellite nodes; S2: Correct the orbital parameters of satellite nodes using a perturbation model; S3: Based on the corrected orbital parameters, obtain the dynamic position of each node in real time and broadcast it; S4: Establish virtual links between multiple satellite nodes; S5: Based on node location and link budget model, dynamically calculate link propagation delay and packet loss rate, and configure them to the corresponding link.

2. The containerized high-fidelity inter-satellite link simulation method for geomagnetic storm phenomena according to claim 1, characterized in that: The disturbance model calculates orbital disturbances based on space weather parameters, including but not limited to solar radio flux and geomagnetic index.

3. The containerized high-fidelity inter-satellite link simulation method for geomagnetic storm phenomena according to claim 1, characterized in that: The calculation of the packet loss rate includes: obtaining the link received power, calculating the bit energy-to-noise ratio, and obtaining the corresponding bit error rate based on the modulation and demodulation method, thereby estimating the packet loss rate.

4. The containerized high-fidelity inter-satellite link simulation method for geomagnetic storm phenomena according to claim 1, characterized in that: Following S4, it also includes: A dual-channel link structure is established, separating the state control flow from the service data flow. The propagation delay and packet loss rate only apply to the service channel.

5. The containerized high-fidelity inter-satellite link simulation method for geomagnetic storm phenomena according to claim 1, characterized in that: The virtual links are constructed through virtual network interfaces, and each virtual link is configured with an independent subnet. The IP addresses assigned to the two interfaces of each virtual link satisfy the following conditions: the two IP addresses are kept at a fixed interval, and the last digit of one IP address is odd and the last digit of the other IP address is even.

6. The containerized high-fidelity inter-satellite link simulation method for geomagnetic storm phenomena according to claim 5, characterized in that: The simulation method further includes link awareness based on a neighbor discovery mechanism and synchronizing the status information of nodes through inter-node broadcasting.

7. A containerized high-fidelity inter-satellite link simulation system for geomagnetic storm phenomena, characterized in that: include: A containerized satellite node cluster, consisting of multiple autonomous satellite nodes built on containers, each satellite node comprising: The orbit calculation module is used to obtain the orbit parameters of this node and simulate the impact of geomagnetic disturbances on it, thereby correcting the orbit parameters; The configuration module, connected to the track calculation module, is used to calculate the link propagation delay and packet loss rate based on the corrected track parameters and the status information of neighboring nodes, and to generate link parameter configuration instructions. The link control engine, connected to the configuration module in the multiple satellite nodes, is used to receive the configuration instructions and configure the corresponding propagation delay and packet loss rate into the virtual inter-satellite link established between the nodes.

8. The containerized high-fidelity inter-satellite link simulation system for geomagnetic storm phenomena according to claim 7, characterized in that: The orbit calculation module receives space weather parameters and calls an atmospheric physics model to obtain atmospheric density disturbances, thereby enabling dynamic correction of the orbit parameters.

9. The containerized high-fidelity inter-satellite link simulation system for geomagnetic storm phenomena according to claim 7, characterized in that: The configuration module calculates the bit error rate based on the link budget model, node location relationships, and modulation scheme, and further derives the packet loss rate.

10. The containerized high-fidelity inter-satellite link simulation system for geomagnetic storm phenomena according to claim 7, characterized in that: The link control engine supports dual-channel configuration of the link, wherein the propagation latency and packet loss rate are configured only for the service channel, and the control channel is not affected.

Images