Simulation method and system for service link multi-beam system of low earth orbit satellite network

Abstract

The invention relates to a simulation method and system for a service link multi-beam system of a low-orbit satellite network, and belongs to the technical field of satellite communication network simulation. According to the invention, a multi-beam architecture is designed by fully utilizing a VLAN label technology, fine-grained network isolation of a beam level is realized through a VLAN filtering mechanism, each beam has independent VLAN ID, subnet, frequency point resources and power parameters, simultaneous work of a plurality of beams of a single satellite is supported, and dynamic IP address pool management and a configurable beam selection strategy are adopted, so that the multi-beam network isolation is realized. According to the invention, on-demand allocation and intelligent connection allocation of resources are realized, the problems of static container network configuration, resource pre-allocation waste and poor simulation accuracy due to lack of multi-beam support in satellite communication network simulation are solved, and the accuracy and resource utilization efficiency of satellite communication network simulation are improved. The method can be widely applied to the fields of low-orbit satellite communication system simulation, satellite internet simulation, satellite communication network performance evaluation and the like.

Description

Technical Field

[0001] This invention belongs to the field of satellite communication network simulation technology, and relates to a simulation method and system for a multi-beam system of low-orbit satellite network service links. Background Technology

[0002] Satellite communication network simulation is a crucial method for system design and verification. Simulation needs to accurately simulate the dynamic connection between user terminals and satellites, particularly the multi-beam characteristics of satellites and the dynamic switching of user terminals between different beams. However, existing container-based satellite communication network simulation schemes lack multi-beam support.

[0003] Existing research primarily employs methods based on specialized simulation software. While such software (e.g., STK) offers advantages in constellation topology planning and coverage area calculation, it cannot simulate the actual data packet transmission process and lacks realistic simulation of the network layer protocol stack. Furthermore, this approach cannot achieve fine-grained network isolation and resource management at the beam level, and struggles to simulate load balancing and dynamic resource allocation in multi-beam architectures, thus limiting its application in simulating complex multi-beam satellite communication networks.

[0004] Currently popular container-based simulation methods (such as SiT4NET, SiNET, and StarryNet) typically employ static network configuration, determining the network configuration during container creation. This approach offers advantages in flexibility and resource utilization efficiency. However, these methods lack support for satellite multi-beam architectures. Multi-beam systems are a core feature of satellite communication networks, where satellites simultaneously serve different geographical areas using multiple independent beams. Each beam has independent coverage and resource allocation capabilities, and user terminals need to dynamically switch their assigned beam based on satellite movement. Existing container-based simulation methods cannot accurately simulate this dynamic multi-beam switching mechanism, limiting their application in multi-beam satellite communication network simulations. In real-world complex satellite communication network simulation scenarios, due to the high-speed movement of satellites, the connection relationship between user terminals and satellites changes frequently. Connection establishment and disconnection operations require rapid response. Static configuration methods are highly likely to fail to respond promptly to connection changes, failing to accurately simulate the dynamic connection characteristics between user terminals and satellites in satellite communication systems, resulting in inaccurate simulation results. Furthermore, due to the multi-beam characteristics of satellite communication systems, each satellite typically has multiple beams to cover different areas. Existing solutions are based on an architecture design of "one container, one network" or "one container, one interface," which cannot support multiple beams working simultaneously in a single satellite container, cannot achieve independent network isolation and resource management at the beam level, and cannot accurately simulate the multi-beam architecture of satellites in satellite communication systems, thus severely affecting the accuracy of satellite communication network simulation. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a simulation method and system for a multi-beam system of low-Earth orbit satellite network service links. It utilizes container networking technology as an implementation tool to realize the simulation of satellite multi-beam architecture in satellite communication network simulation. It is suitable for large-scale satellite communication network simulation platforms and can be widely used in fields such as low-Earth orbit satellite communication system simulation, satellite Internet simulation, and satellite communication network performance evaluation.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A simulation method for a multi-beam system of low-Earth orbit satellite network service links, the method specifically includes the following steps: S1. Create a Linux bridge device on the host machine and enable VLAN filtering to build the core aggregation layer architecture of the container network; S2. Allocate multiple beam resources to the satellite container (the number of beams can be set according to requirements), create veth pairs (host-side interfaces and container-side interfaces appear in pairs), connect the host-side interfaces to the bridge, move the container-side interfaces into the satellite container's network namespace, configure the host-side interfaces in tagged mode to support multiple VLAN tags (each beam corresponds to one VLAN tag, and the number of VLAN tags is equal to the number of configured beams), create beam sub-interfaces for each beam on the container-side interfaces inside the satellite container and configure gateway IP addresses (the number of beam sub-interfaces is equal to the number of configured beams), configure independent frequency point parameters and transmit power parameters for each beam (the number of frequency point and power parameters is equal to the number of configured beams), and build a multi-beam network architecture for the satellite container. S3. Create veth pairs for user terminal containers (host-side interfaces and container-side interfaces appear in pairs), connect the host-side interfaces to the bridge, move the container-side interfaces into the network namespace of the user terminal containers, assign independent VLAN IDs to the host-side interfaces of the user terminal to initially isolate them, and build a dynamic connection architecture for the user terminal containers. S4. When a user terminal needs to connect to a satellite beam, check existing connections and select a target beam based on a configurable beam selection strategy (such as load balancing, random selection, priority, frequency matching, power optimization, etc.). The strategy can comprehensively consider factors such as beam load, frequency compatibility, and power coverage. Switch the VLAN configuration of the user terminal's host interface from the isolated VLAN to the target beam's VLAN, configure a bridge to allow the target beam's VLAN to pass through, dynamically allocate IP addresses from the target beam's IP address pool, configure IP addresses and routes on the user terminal's container interface, update connection records, and achieve dynamic connection establishment. S5. When a user terminal needs to disconnect, remove the beam VLAN configuration of the user terminal host interface, identify and clean up all IP addresses belonging to the target beam subnet on the user terminal container interface, return the cleaned IP addresses to the dynamic IP address pool of the corresponding beam, clean up the routing configuration pointing to the beam gateway on the user terminal container interface, and if the user terminal has no other connection, restore the original independent VLAN configuration of the user terminal host interface, update the connection relationship record, and realize dynamic connection disconnection. S6. Maintain an independent dynamic IP address pool for each beam of each satellite, dynamically allocate and reclaim VLAN IDs and subnet resources (the number of resources equals the number of configured beams), allocate and manage independent frequency resources and transmit power parameters for each beam, support dynamic allocation of frequency resources and dynamic adjustment of power parameters, maintain a bidirectional mapping relationship between user terminals and satellite beams (the number of mapping relationships equals the number of configured beams), monitor the container lifecycle and automatically clean up all related resources when the container is deleted, and build a resource management architecture.

[0007] Furthermore, in step S1, the creation of the Linux bridge device and the enabling of VLAN filtering specifically includes: creating a Linux bridge device on the host machine, activating the bridge to make it work, enabling the bridge to decide whether to forward data packets based on the VLAN tag of the data packets, realizing traffic isolation between different VLANs, configuring the bridge to support default VLANs and setting it to untagged mode, and building the core aggregation layer architecture of the container network.

[0008] Further, in step S2, allocating multiple beam resources to the satellite container specifically includes: allocating multiple beams to each satellite, the number of beams can be arbitrarily set according to requirements; assigning a unique VLAN ID to each beam starting from the initial VLAN ID (e.g., 10) (the number of allocated VLAN IDs equals the configured number of beams); allocating subnets starting from the initial subnet address (e.g., 172.16.0.0 / 28) ( / 28, i.e., 16 addresses) and incrementing (the number of allocated subnets equals the configured number of beams); setting the gateway IP address of each beam to the second address of that subnet (subnet address + 1); allocating independent frequency resources to each beam, with the frequency points increasing at set intervals (e.g., 100 MHz) starting from the initial frequency point (e.g., 14000 MHz) to ensure that different beams use different frequency points to avoid co-channel interference; configuring independent transmit power parameters for each beam, the power parameters can be dynamically set according to beam coverage requirements and load conditions (e.g., a range of 20-50 dBm); and checking VLANs before allocating resources. Ensure that the ID, subnet, and frequency point are already in use and that resources do not conflict; The creation of the veth pair connecting the satellite container and the bridge specifically includes: creating a pair of virtual Ethernet interfaces (veth pair) for each satellite container; the host interface and the container interface appear in pairs to form a bidirectional communication channel; activating the host interface and adding it to the bridge; establishing a connection between the host interface and the bridge; the host interface becoming part of the bridge and able to participate in the bridge's VLAN filtering and traffic forwarding; and the container interface establishing a connection with the host interface through the veth pair.

[0009] Furthermore, in step S2, configuring the satellite host interface to tagged mode specifically includes: removing the default VLAN configuration of the interface, adding a tagged tag to the interface for each beam's VLAN ID, enabling the interface to identify and forward data packets with these VLAN tags, and enabling a single physical interface to carry traffic from multiple VLANs (each VLAN corresponds to one beam, and the number of VLANs is equal to the number of configured beams), supporting a multi-beam architecture. The process of creating a beam sub-interface for each beam within the satellite container specifically includes: obtaining the container's process ID through a container management interface (such as the Docker API); moving the container-side interface from the host machine's network namespace to the container's network namespace to make the container-side interface available within the container; creating a beam sub-interface for each beam on the container-side interface (main interface) within the container, with the number of beam sub-interfaces equal to the configured number of beams; establishing a connection relationship between the beam sub-interfaces and the main interface as logical sub-interfaces of the main interface; and representing the beam sub-interface as `{satellite_name}-{beam_id}` (e.g., `03019-0`, `03019-1`, `03019-2`, etc., where beam_id increments from 0 to N-1, and N is the configured number of beams). Each beam sub-interface is associated with a corresponding VLAN. ID, configure an independent gateway IP address for each beam sub-interface, activate all beam sub-interfaces to make them work, build a multi-beam network architecture for satellite containers, in which the container-side interface is connected to the host-side interface through veth, the host-side interface is connected to the bridge, and all beam sub-interfaces establish a communication path with the bridge through the main interface (container-side interface).

[0010] Furthermore, in step S2, the initialization of a dynamic IP address pool for each beam specifically includes: maintaining an independent dynamic IP address pool for each beam. The IP address pool contains all available IP addresses within the subnet of that beam, excluding network addresses, broadcast addresses, and gateway addresses. For example, in subnet 172.16.0.0 / 28, the available IPs are 172.16.0.2-172.16.0.14. Thread-safe IP address allocation and reclamation operations are supported. The constructed satellite container multi-beam network architecture supports link delay simulation, specifically including: configuring a traffic control (TC) mechanism on the network interface of the satellite container; dynamically calculating and updating network delay parameters based on the real-time physical distance between satellites; the delay calculation formula is: delay = distance / speed of light, where the distance is calculated using the satellite's three-dimensional coordinates; achieving accurate simulation of signal propagation delay in the simulation of a multi-beam system for low-Earth orbit satellite network service links; supporting dynamic adjustment of delay during satellite motion; ensuring that the simulation system can accurately reflect the propagation delay characteristics in real satellite communication networks; and improving the realism and accuracy of satellite communication network simulation.

[0011] Furthermore, in step S3, the creation of veth pairs and connection to the bridge specifically includes: creating a pair of virtual Ethernet interfaces (veth pairs) for each user terminal container, with the host interface and container interface appearing in pairs to form a bidirectional communication channel, activating the host interface and adding it to the bridge, establishing a connection between the host interface and the bridge, making the host interface part of the bridge and able to participate in the bridge's VLAN filtering and traffic forwarding, and the container interface establishing a connection with the host interface through the veth pair; Moving the container-side interface into the container's network namespace specifically includes: obtaining the process ID of the user terminal container through a container management interface (such as the Docker API), moving the container-side interface from the host machine's network namespace into the container's network namespace, making the container-side interface visible and usable within the container, connecting the container-side interface to the host machine's interface through a veth pair, connecting the host machine's interface to the bridge, and establishing a communication path between the container-side interface and the bridge. The process of assigning an independent VLAN ID to the user terminal specifically includes: assigning VLAN IDs starting from a large initial value (such as 1000) to ensure that they do not conflict with the VLAN IDs of the satellite beam; configuring the host interface of the user terminal to the untagged mode and PVID (Port VLAN ID) of the VLAN; so that the data packets sent by the interface do not carry VLAN tags but are identified by the bridge as belonging to the VLAN; and so that the user terminal is initially unable to communicate with other containers and is in an isolated state.

[0012] Furthermore, in step S4, the selection of the target beam according to the load balancing strategy includes: counting the number of user terminals currently connected to each beam of the satellite, selecting the beam with the fewest connections from all beams, and if multiple beams have the same number of connections, selecting the beam with the smallest beam ID, so as to achieve a balanced distribution of traffic among all beams. The switching of VLAN configuration of the user terminal interface specifically includes: removing the original VLAN configuration of the user terminal host interface, disconnecting the association between the host interface and the isolated VLAN, adding the VLAN ID of the target beam to the user terminal host interface, setting it to untagged mode and PVID, so that the data packets sent by the host interface can be identified by the bridge as belonging to the VLAN of the target beam. Since the host interface is connected to the bridge, the bridge forwards the data packets to the host interface of the satellite container (which is configured to tagged mode to support the VLAN) according to the VLAN tag, thereby realizing the connection between the user terminal host interface and the satellite container host interface through the bridge, and thus realizing the network connection between the user terminal and the target beam. The dynamic allocation of IP addresses specifically includes: obtaining an available IP address from the IP address pool of the target beam; the IP address pool automatically excludes already allocated IP addresses to ensure that IP addresses do not conflict; the IP address pool contains all available IP addresses within the beam subnet except for network addresses, broadcast addresses, and gateway addresses. The configuration of IP address and routing within the user terminal container specifically includes: configuring the assigned IP address and subnet mask on the container-side interface of the user terminal container, activating the network interface, setting the default route to the gateway IP address of the target beam (this gateway IP address is configured on the beam sub-interface of the satellite container), synchronizing the frequency parameters and transmit power parameters of the target beam to the user terminal container, configuring the operating frequency of its radio frequency interface according to the assigned frequency parameters, adjusting its transmit power according to the assigned power parameters to match the power requirements of the beam, establishing a communication path between the user terminal container-side interface and the satellite container beam sub-interface, enabling all outbound traffic to reach the host interface from the user terminal container-side interface via the veth pair, then forwarding it to the host interface of the satellite container via the bridge, and finally reaching the beam sub-interface of the satellite container, thus realizing communication with the external network.

[0013] Furthermore, in step S5, the identification and cleanup of IP addresses specifically includes: querying all IP addresses configured on the user terminal container interface, obtaining a complete list of IP addresses, determining whether each IP address belongs to the subnet range of the target beam, matching the subnet mask and network address, deleting all IP addresses belonging to the target beam subnet, and releasing these IP address resources.

[0014] Furthermore, in step S6, maintaining an independent dynamic IP address pool for each beam specifically includes: maintaining an independent IP address pool for each beam of each satellite, wherein the number of IP address pools maintained for each satellite is equal to the number of configured beams, and the key value `{satellite_name}_beam{beam_id}` can be used as the unique identifier of the pool (such as `03019_beam0`, `03019_beam1`, etc., where beam_id increments from 0 to N-1, and N is the number of configured beams). The IP address pool automatically excludes network addresses, broadcast addresses, and gateway addresses, and only contains available IP addresses. It supports thread-safe IP address allocation and reclamation operations, prevents concurrent access conflicts, and provides an IP address usage query interface to support statistics and monitoring. The dynamic allocation and reclamation of VLAN IDs and subnet resources specifically includes: dynamically allocating and reclamating VLAN IDs, maintaining a set of used VLAN IDs, allocating VLAN IDs for satellite beams starting from an initial value (e.g., 10) and incrementing the allocation, with the number of VLAN IDs allocated to each satellite equal to the configured number of beams (each beam corresponds to one VLAN ID), and allocating VLAN IDs for user terminals starting from a larger initial value (e.g., 1000) to ensure no conflict, supporting VLAN ID conflict detection and automatic reallocation; allocating an independent subnet for each beam of each satellite, with the number of subnets allocated to each satellite equal to the configured number of beams, such as setting the subnet size to / 28 (16 addresses), with subnets incrementing from the initial subnet address, calculated using the formula: Subnet address = Initial subnet address + (Satellite index × Number of beams per satellite + Beam ID) × Subnet size: Maintains the allocated subnet set to ensure non-overlapping subnets and support large-scale deployment; allocates and manages independent frequency resources for each beam of each satellite. The number of frequency points allocated to each satellite is equal to the number of configured beams. Frequency points are allocated incrementally at set intervals (e.g., 100 MHz) starting from the initial frequency point (e.g., 14000 MHz), calculated as: Frequency point = Initial frequency point + (Satellite index × Number of beams per satellite + Beam ID) × Frequency interval. Maintains the allocated frequency point set to ensure different beams use different frequencies to avoid co-channel interference, supporting frequency conflict detection and automatic reallocation; configures and manages independent transmit power parameters for each beam. The number of power parameters configured for each satellite is equal to the number of configured beams. Power parameters can be dynamically adjusted (e.g., within a 20-50 dBm range) based on beam coverage requirements, load conditions, and user terminal distance, supporting dynamic updates and optimization of power parameters to achieve intelligent allocation and management of power resources. Maintaining the bidirectional mapping relationship between user terminals and satellite beams specifically includes: maintaining the mapping from user terminals to satellite beams `{terminal_name: (satellite_name, beam_id)}`; maintaining the mapping from satellite beams to user terminals `{satellite_name: {beam_id: {terminal_name, ...}}}`; and maintaining the mapping from satellites to user terminals `{satellite_name: {terminal_name, ...}}`, supporting satellite-level connection management; providing a fast query interface, supporting multiple query methods such as by user terminal, by satellite, and by beam.

[0015] The monitoring of container lifecycle and automatic cleanup of all related resources when a container is deleted specifically includes: monitoring container status, and automatically cleaning up all related resources when a container is deleted, including deleting veth pairs, reclaiming VLAN IDs, clearing connection records, and returning IP addresses to the IP address pool to prevent resource leakage.

[0016] This invention also provides a simulation system for a low-orbit satellite network service link multi-beam system, which consists of four parts: (1) a core aggregation layer: realizing traffic aggregation and isolation between containers based on Linux bridge and VLAN filtering; (2) a satellite multi-beam network layer: creating satellite containers and configuring multiple beam sub-interfaces for satellite containers to support concurrent multi-beam services; (3) a user terminal dynamic connection layer: creating user terminal containers and providing dynamic connection and beam switching capabilities for user terminal containers; and (4) a resource management layer: managing network resources such as VLAN ID, subnet and IP address pool; the system executes the methods described above.

[0017] The beneficial effects of this invention are as follows: Compared with existing technologies, this invention fully utilizes VLAN tagging technology to design a multi-beam architecture. It not only achieves fine-grained network isolation at the beam level through VLAN filtering mechanisms, giving each beam an independent VLAN ID, subnet, frequency resources, and power parameters, supporting multiple beams working simultaneously on a single satellite, but also employs dynamic IP address pool management and configurable beam selection strategies (such as load balancing, frequency matching, and power optimization strategies) to achieve on-demand resource allocation and intelligent connection allocation. This solves the problems of poor simulation accuracy in satellite communication network simulation caused by static container network configuration, wasted resource pre-allocation, and lack of multi-beam support, thereby improving the accuracy and resource utilization efficiency of satellite communication network simulation.

[0018] Other advantages, objectives, and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination, or may be learned from practice of the invention. The objectives and other advantages of the invention can be realized and obtained through the following description. Attached Figure Description

[0019] 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: Figure 1 This is a schematic flowchart of the method of the present invention; Figure 2 This is a schematic diagram of the system architecture of the present invention. Detailed Implementation

[0020] 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.

[0021] 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.

[0022] 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.

[0023] like Figure 1 and Figure 2As shown, this example provides a method for dynamic connection management of container networks based on VLANs and multi-beams. The specific implementation steps are as follows: Step 1: Bridge Initialization Create a Linux bridge device on the host machine, activate the bridge to make it operational, and enable the bridge's VLAN filtering function. This allows the bridge to decide whether to forward data packets based on their VLAN tags, achieving traffic isolation between different VLANs. Configure the bridge to support default VLANs by setting it to untagged mode.

[0024] Step 2: Satellite Container Registration When a satellite container needs to join a network, perform the following operations: 1) Allocate multiple beam resources to the satellite; the number of beams can be arbitrarily set according to requirements. Allocation starts from the initial VLAN ID (e.g., 10) and increments, assigning a unique VLAN ID to each beam (the number of allocated VLAN IDs equals the configured number of beams). For example, if 8 beams are configured, VLAN IDs 11-18 are assigned. Subnets are allocated starting from the initial subnet address (e.g., 172.16.0.0 / 28) and incrementing (the number of allocated subnets equals the configured number of beams). For example, if 4 beams are configured, beam 0 for the first satellite is assigned 172.16.0.0 / 28, beam 1 is assigned 172.16.0.16 / 28, beam 2 is assigned 172.16.0.32 / 28, and beam 3 is assigned 172.16.0.48 / 28. The gateway IP address for each beam is set to the second address of the subnet of that beam (subnet address + 1). For example, the gateway IP for subnet 172.16.0.0 / 28 is 172.16.0.1.

[0025] 2) Allocate independent frequency resources to each beam (the number of frequency resources equals the number of configured beams). Frequency resources are allocated incrementally at set intervals (e.g., 100 MHz) starting from the initial frequency (e.g., 14000 MHz) to ensure that different beams use different frequencies to avoid co-channel interference. Configure independent transmit power parameters for each beam (the number of power parameters equals the number of configured beams). Power parameters can be dynamically set (e.g., within a 20-50 dBm range) according to beam coverage requirements, load conditions, and user terminal distance, supporting dynamic adjustment and optimization of power parameters.

[0026] 3) Create a veth pair for the satellite container, with the host-side interface and container-side interface appearing as a pair. Activate the host-side interface and add it to the bridge.

[0027] 4) Configure the satellite host interface to tagged mode, remove the default VLAN configuration of the interface, and add a tagged tag to the interface for each beam's VLAN ID, enabling the interface to identify and forward packets with these VLAN tags. The VLAN ID range is determined based on the number of configured beams.

[0028] 5) Obtain the container's process ID through a container management interface (such as the Docker API) and move the container-side interface from the host machine's network namespace to the container's network namespace.

[0029] 6) Create a beam sub-interface for each beam on the main interface inside the satellite container. The number of beam sub-interfaces is equal to the number of configured beams. Each beam sub-interface is associated with a corresponding VLAN ID, configured with an independent gateway IP address, and activated.

[0030] 7) Initialize an independent dynamic IP address pool for each beam. The IP address pool contains all available IP addresses within the subnet of that beam, excluding network addresses, broadcast addresses, and gateway addresses. For example, in subnet 172.16.0.0 / 28, the available IPs are 172.16.0.2-172.16.0.14.

[0031] 8) Supports link delay simulation, i.e., configuring a traffic control (TC) mechanism on the network interface of the satellite container. Network delay parameters are dynamically calculated and updated based on the real-time physical distance between satellites. The delay calculation formula is: Delay = Distance / Speed ​​of Light, where the distance is calculated using the satellite's three-dimensional coordinates (longitude, latitude, and altitude). The system monitors satellite position changes in real time. When satellite movement causes a change in distance, the system automatically updates the delay parameters of the corresponding network interface, achieving dynamic delay adjustment and ensuring that the simulation system accurately reflects the propagation delay characteristics in real satellite communication networks.

[0032] Step 3: User terminal container registration When a user terminal container needs to join the network, perform the following operations: 1) Create a veth pair for the user terminal container, with the host-side interface and container-side interface appearing in pairs. Activate the host-side interface and add it to the bridge.

[0033] 2) Assign a unique VLAN ID to the user terminal, starting with a large initial value (e.g., 1000) to ensure no conflict with the satellite beam's VLAN ID. Configure the user terminal's host interface to the untagged mode and PVID of that VLAN, so that data packets sent by the interface do not carry VLAN tags, but are still recognized by the bridge as belonging to that VLAN.

[0034] 3) Obtain the process ID of the user terminal container and move the container-side interface from the host machine's network namespace to the container's network namespace.

[0035] At this point, the user terminal is in an isolated state, unable to communicate with other containers, and is waiting for a dynamic connection to be established.

[0036] Step 4: Establishing dynamic links When a user terminal needs to connect to a specific beam of a satellite, the following operations are performed: 1) Check if the user terminal is already connected to other satellites or beams. Query the connection relationship records; if the user terminal is already connected to other satellites, first invoke the disconnect procedure to disconnect the existing connection.

[0037] 2) If no beam ID is specified, the target beam is selected. Alternatively, the number of currently connected user terminals for each beam can be automatically counted based on a load balancing strategy, and the beam with the fewest connections can be selected from all beams. For example, if four beams are configured, and the current connection counts for the four satellite beams are: beam 0 = 5, beam 1 = 3, beam 2 = 4, and beam 3 = 2, then beam 3 is selected. For example, frequency matching strategies (selecting compatible beams based on the user terminal's frequency capabilities, querying the frequency range supported by the user terminal, selecting beams with matching frequencies from all beams, prioritizing beams with perfect frequency matching to avoid connection failures caused by frequency mismatch. For example, if the user terminal supports the 14000-14500 MHz frequency band, beams within this range are prioritized) and power optimization strategies (selecting beams with optimal power coverage based on the user terminal's location and distance, calculating the distance from the user terminal to each beam, selecting beams with sufficient power to cover the user terminal, prioritizing beams with optimal power coverage to improve connection quality and signal strength. For example, if the user terminal is far away, a beam with higher power is selected). These strategies can comprehensively consider multiple factors such as beam load, frequency compatibility, power coverage, and signal quality, allowing users to select or customize different strategies according to their actual needs.

[0038] 3) Switch the VLAN configuration of the user terminal host interface. Remove the original VLAN configuration of the user terminal host interface, add the VLAN ID of the target beam to the user terminal host interface, and set it to untagged mode and PVID.

[0039] 4) Configure VLAN filtering for the bridge. Check if the bridge has the VLAN configured. If not, add the VLAN of the target beam to the bridge's VLAN table.

[0040] 5) Dynamically allocate an available IP address to the user terminal from the IP address pool of the target beam. For example, allocate IP address 172.16.0.50 from the IP address pool of beam 3.

[0041] 6) Configure network parameters on the container-side interface of the user terminal container. Configure the assigned IP address and subnet mask (e.g., 172.16.0.50 / 28) on the container-side interface, activate the network interface, and set the default route to the gateway IP address of the target beam (e.g., 172.16.0.49).

[0042] 7) Synchronize the target beam's frequency and transmit power parameters to the user terminal container. Query the target beam's frequency parameters (e.g., 14300 MHz) and transmit power parameters (e.g., 45 dBm), and transmit these parameters to the user terminal container via the container management interface. The user terminal container configures its RF interface's operating frequency according to the assigned frequency parameters and adjusts its transmit power according to the assigned power parameters to match the beam's power requirements, ensuring that the user terminal matches the beam's frequency and power parameters, thus improving connection quality and signal strength.

[0043] 8) Update connection relationship records. Record the mapping from the user terminal to the satellite beam, the mapping from the satellite beam to the user terminal, the connection from the satellite to the user terminal, and the mapping relationship of frequency and power parameters between the user terminal and the beam.

[0044] Step 5: Dynamic connection disconnected When a user terminal needs to disconnect from the satellite, perform the following operations: 1) Remove the beam VLAN configuration from the user terminal's host interface. Delete the beam VLAN configuration from the user terminal's host interface, so that the host interface no longer belongs to the target beam's VLAN.

[0045] 2) Identify and clean up all IP addresses belonging to the target beam subnet on the user terminal container interface. Query all IP addresses configured on the container interface, determine whether each IP address belongs to the target beam subnet range (e.g., 172.16.0.48 / 28), match them by subnet mask and network address, and delete all IP addresses belonging to the target beam subnet.

[0046] 3) Return the cleaned-up IP addresses to the dynamic IP address pool of the corresponding beam. Call the IP address pool's recycling interface, pass in the beam identifier and IP address, and mark the IP address as available.

[0047] 4) Clean up the routing configuration on the user terminal's container interface that points to the beam gateway. Determine if the user terminal has any other connections. If this is the only connection, delete the default route on the container interface; otherwise, leave the other routes unchanged.

[0048] 5) If the user terminal has no other connections, restore the original independent VLAN configuration of the user terminal's host interface. Determine if the user terminal has any other connections. If not, reconfigure the user terminal's host interface to its original independent VLAN (e.g., 1000) to put it back into isolation.

[0049] 6) Update connection relationship records. Delete the mapping from the user terminal to the satellite beam, remove the user terminal from the mapping from the satellite beam to the user terminal, and remove the user terminal from the mapping from the satellite to the user terminal.

[0050] Step 6: Resource Management Maintain the following resource management mechanisms: 1) Dynamic IP Address Pool Management: An independent IP address pool is maintained for each beam, using a key-value pair as the pool's unique identifier. The IP address pool automatically excludes network addresses, broadcast addresses, and gateway addresses, containing only available IP addresses. Thread-safe IP address allocation and recycling operations are supported to prevent concurrent access conflicts. An IP address usage query interface is provided, supporting statistics and monitoring.

[0051] 2) VLAN ID Management: Dynamically allocates and reclaims VLAN IDs, and maintains a set of used VLAN IDs. VLAN IDs for satellite beams are allocated incrementally starting from an initial value (e.g., 10). VLAN IDs for user terminals are allocated starting from a larger initial value (e.g., 1000) to ensure no conflict. VLAN ID conflict detection and automatic reallocation are supported.

[0052] 3) Subnet Management: Each beam is assigned an independent subnet, such as a subnet size of / 28 (16 addresses). Subnets are allocated incrementally in fixed increments starting from the initial subnet address, calculated as: `Subnet Address = Initial Subnet Address + (Satellite Index × Number of Beams per Satellite + Beam ID) × Subnet Size`. The allocated subnet set is maintained to ensure no overlap. Large-scale deployment is supported, allowing management of multiple subnets.

[0053] 4) Frequency Resource Management: Independent frequency resources are allocated and managed for each beam of each satellite. The number of frequency points allocated to each satellite equals the number of configured beams. Frequency points are allocated incrementally in intervals (e.g., 100MHz) starting from an initial frequency point (e.g., 14000 MHz), calculated using the formula: `Frequency Point = Initial Frequency Point + (Satellite Index × Number of Beams per Satellite + Beam ID) × Frequency Interval`. The system maintains a set of allocated frequency points to ensure different beams use different frequencies to avoid co-channel interference. Frequency conflict detection and automatic reallocation are supported. A frequency usage query interface is provided for statistical analysis and monitoring.

[0054] 5) Power Parameter Management: Independent transmit power parameters are configured and managed for each beam. Power parameters can be dynamically adjusted (e.g., within a 20-50 dBm range) based on beam coverage requirements, load conditions, and user terminal distance, supporting dynamic updates and optimization. The system dynamically adjusts the beam's transmit power based on factors such as beam coverage, current load, and user terminal distance, achieving intelligent allocation and management of power resources. A power parameter query and update interface is provided, supporting real-time power parameter adjustment. Automatic power parameter optimization is supported, automatically adjusting power parameters based on connection quality and signal strength to improve overall system performance.

[0055] 6) Connection Status Management: Maintain the bidirectional mapping relationship between user terminals and satellite beams. The mapping from user terminals to satellite beams has a time complexity of O(1) lookup. Maintain the mapping relationship between user terminals and beam frequency and power parameters, supporting fast lookup of frequency and power parameters.

[0056] 7) Container lifecycle management: Monitor container status and automatically clean up all related resources when a container is deleted, including deleting veth pairs, reclaiming VLAN IDs, clearing connection records, returning IP addresses to the IP address pool, reclaiming frequency resources, and clearing power parameter configurations.

[0057] This invention provides a method and system for dynamic connection management of container networks that supports multiple beams. It improves upon previous methods of static configuration and manual management of container networks. It adopts VLAN tagging technology to design a multi-beam architecture and utilizes Linux bridge VLAN filtering function combined with dynamic IP address pool management, configurable beam selection strategies (such as load balancing strategies), and beam-level frequency and transmit power allocation mechanisms. This effectively solves the problem of poor simulation accuracy in satellite communication network simulation due to the lack of multi-beam support, and improves the simulation accuracy of satellite communication network simulation.

[0058] 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.

Claims

1. A simulation method for a multi-beam system of low-Earth orbit satellite network service links, characterized in that, The method specifically includes the following steps: S1. Create a Linux bridge device on the host machine and enable VLAN filtering to build the core aggregation layer architecture of the container network; S2. Allocate multiple beam resources to the satellite container, connect the host interface to the bridge, move the container interface into the network namespace of the satellite container, configure the host interface in tagged mode to support multiple VLAN tags, create a beam sub-interface for each beam on the container interface inside the satellite container and configure the gateway IP address, configure independent frequency point parameters and transmit power parameters for each beam, and build a multi-beam network architecture for the satellite container. S3. Create a veth pair for the user terminal container, connect the host interface to the bridge, move the container interface into the network namespace of the user terminal container, assign an independent VLAN ID to the host interface of the user terminal to make it initially isolated, and build a dynamic connection architecture for the user terminal container. S4. When a user terminal needs to connect to a satellite beam, check the existing connections and select the target beam according to the configurable beam selection strategy; switch the VLAN configuration of the user terminal's host interface from the isolated VLAN to the target beam's VLAN, configure the bridge to allow the target beam's VLAN to pass through, dynamically allocate IP addresses from the target beam's IP address pool, configure IP addresses and routes on the user terminal's container interface, update connection relationship records, and realize dynamic connection establishment. S5. When a user terminal needs to disconnect, remove the beam VLAN configuration of the user terminal host interface, identify and clean up all IP addresses belonging to the target beam subnet on the user terminal container interface, return the cleaned IP addresses to the dynamic IP address pool of the corresponding beam, clean up the routing configuration pointing to the beam gateway on the user terminal container interface, and if the user terminal has no other connection, restore the original independent VLAN configuration of the user terminal host interface, update the connection relationship record, and realize dynamic connection disconnection. S6 maintains an independent dynamic IP address pool for each beam of each satellite, dynamically allocates and reclaims VLAN IDs and subnet resources, allocates and manages independent frequency resources and transmit power parameters for each beam, supports dynamic allocation of frequency resources and dynamic adjustment of power parameters, maintains a bidirectional mapping relationship between user terminals and satellite beams, monitors container lifecycles and automatically cleans up all related resources when a container is deleted, and builds a resource management architecture.

2. The simulation method for a multi-beam system of a low-Earth orbit satellite network service link according to claim 1, characterized in that, In step S1, creating a Linux bridge device and enabling VLAN filtering specifically includes: creating a Linux bridge device on the host machine, activating the bridge to make it work, enabling the bridge to decide whether to forward data packets based on the VLAN tag of the data packets, achieving traffic isolation between different VLANs, configuring the bridge to support default VLANs and setting it to untagged mode, and building the core aggregation layer architecture of the container network.

3. The simulation method for a multi-beam system of a low-Earth orbit satellite network service link according to claim 2, characterized in that, In step S2, allocating multiple beam resources to the satellite container specifically includes: allocating multiple beams to each satellite, the number of beams can be arbitrarily set according to requirements; allocating a unique VLAN ID to each beam starting from the initial VLAN ID; allocating subnets starting from the initial subnet address; setting the gateway IP address of each beam to the second address of that beam's subnet; allocating independent frequency resources to each beam, with frequency points allocated incrementally at set intervals starting from the initial frequency point to ensure that different beams use different frequency points to avoid co-channel interference; configuring independent transmit power parameters for each beam, the power parameters can be dynamically set according to beam coverage requirements and load conditions; and checking whether the VLAN ID, subnet, and frequency point have been used before allocating resources to ensure that resources do not conflict. The creation of the veth pair connecting the satellite container and the bridge specifically includes: creating a pair of virtual Ethernet interfaces for each satellite container; the host interface and the container interface appear in pairs to form a bidirectional communication channel; activating the host interface and adding it to the bridge; establishing a connection between the host interface and the bridge; the host interface becoming part of the bridge and being able to participate in the bridge's VLAN filtering and traffic forwarding; and the container interface establishing a connection with the host interface through the veth pair.

4. The simulation method for a multi-beam system of a low-Earth orbit satellite network service link according to claim 3, characterized in that, In step S2, configuring the satellite host interface to tagged mode specifically includes: removing the default VLAN configuration of the interface, adding a tagged tag to the interface for each beam's VLAN ID, enabling the interface to identify and forward data packets with these VLAN tags, realizing that a single physical interface can carry traffic from multiple VLANs, and supporting multi-beam architecture; The process of creating a beam sub-interface for each beam within the satellite container specifically includes: obtaining the container's process ID through the container management interface; moving the container-side interface from the host network namespace to the container's network namespace to make the container-side interface available within the container; creating a beam sub-interface for each beam on the container-side interface within the container, with the number of beam sub-interfaces equal to the number of configured beams; establishing a connection relationship between the beam sub-interface and the main interface as logical sub-interfaces of the main interface; associating each beam sub-interface with a corresponding VLAN ID; configuring an independent gateway IP address for each beam sub-interface; activating all beam sub-interfaces to make them operational; and constructing a multi-beam network architecture for the satellite container, wherein the container-side interface connects to the host-side interface via a veth pair, the host-side interface connects to the bridge, and all beam sub-interfaces establish a communication path with the bridge through the main interface.

5. The simulation method for a multi-beam system of a low-Earth orbit satellite network service link according to claim 4, characterized in that, In step S2, the initialization of a dynamic IP address pool for each beam specifically includes: maintaining an independent dynamic IP address pool for each beam. The IP address pool contains all available IP addresses within the beam subnet except for network addresses, broadcast addresses, and gateway addresses, and supports thread-safe IP address allocation and recycling operations. The constructed satellite container multi-beam network architecture supports link delay simulation, specifically including: configuring a flow control mechanism on the network interface of the satellite container, dynamically calculating and updating network delay parameters based on the real-time physical distance between satellites, with the delay calculation formula being: delay = distance / speed of light, where the distance is calculated using the satellite's three-dimensional coordinates. This enables accurate simulation of signal propagation delay in the multi-beam system simulation of low-Earth orbit satellite network service links, supports dynamic adjustment of delay during satellite motion, ensures that the simulation system can accurately reflect the propagation delay characteristics in real satellite communication networks, and improves the realism and accuracy of satellite communication network simulation.

6. The simulation method for a multi-beam system of a low-Earth orbit satellite network service link according to claim 5, characterized in that, In step S3, the creation of veth pairs and connection to the bridge specifically includes: creating a pair of virtual Ethernet interfaces for each user terminal container, with the host interface and container interface appearing in pairs to form a bidirectional communication channel, activating the host interface and adding it to the bridge, establishing a connection between the host interface and the bridge, making the host interface part of the bridge and able to participate in the bridge's VLAN filtering and traffic forwarding, and the container interface establishing a connection with the host interface through the veth pair; Moving the container-side interface into the container's network namespace specifically includes: obtaining the process ID of the user terminal container through the container management interface, moving the container-side interface from the host network namespace into the container's network namespace, making the container-side interface visible and usable within the container, connecting the container-side interface to the host interface through a veth pair, connecting the host interface to the bridge, and establishing a communication path between the container-side interface and the bridge. The process of allocating an independent VLAN ID to the user terminal specifically includes: allocating VLAN IDs starting from a larger initial value to ensure that they do not conflict with the VLAN IDs of the satellite beam; configuring the host interface of the user terminal to the untagged mode and PVID of the VLAN, so that the data packets sent by the interface do not have VLAN tags but are identified by the bridge as belonging to the VLAN, so that the user terminal cannot communicate with other containers in the initial state and is in an isolated state.

7. The simulation method for a multi-beam system of a low-Earth orbit satellite network service link according to claim 6, characterized in that, In step S4, the selection of target beams according to the load balancing strategy includes: counting the number of user terminals currently connected to each beam of the satellite, selecting the beam with the fewest connections from all beams, and if multiple beams have the same number of connections, selecting the beam with the smallest beam ID, so as to achieve a balanced distribution of traffic among all beams. The switching of VLAN configuration of the user terminal interface specifically includes: removing the original VLAN configuration of the user terminal host interface, disconnecting the association between the host interface and the isolated VLAN, adding the VLAN ID of the target beam to the user terminal host interface, setting it to untagged mode and PVID, so that the data packets sent by the host interface can be identified by the bridge as belonging to the VLAN of the target beam. Since the host interface is connected to the bridge, the bridge forwards the data packets to the host interface of the satellite container according to the VLAN tag, realizing the connection between the user terminal host interface and the satellite container host interface through the bridge, thereby realizing the network connection between the user terminal and the target beam. The dynamic allocation of IP addresses specifically includes: obtaining an available IP address from the IP address pool of the target beam; the IP address pool automatically excludes already allocated IP addresses to ensure that IP addresses do not conflict; the IP address pool contains all available IP addresses within the beam subnet except for network addresses, broadcast addresses, and gateway addresses. The configuration of IP address and routing within the user terminal container specifically includes: configuring the assigned IP address and subnet mask on the container-side interface of the user terminal container, activating the network interface, setting the default route to the gateway IP address of the target beam, synchronizing the frequency parameters and transmit power parameters of the target beam to the user terminal container, configuring the operating frequency of its radio frequency interface according to the assigned frequency parameters, adjusting its transmit power according to the assigned power parameters to match the power requirements of the beam, establishing a communication path between the user terminal container-side interface and the satellite container beam sub-interface, enabling all outbound traffic to reach the host interface from the user terminal container-side interface via the veth pair, then forwarding it to the host interface of the satellite container via the bridge, and finally reaching the beam sub-interface of the satellite container, thus realizing communication with the external network.

8. The simulation method for a multi-beam system of a low-Earth orbit satellite network service link according to claim 7, characterized in that, In step S5, identifying and cleaning up IP addresses specifically includes: querying all IP addresses configured on the user terminal container interface, obtaining a complete list of IP addresses, determining whether each IP address belongs to the subnet range of the target beam, matching the subnet mask and network address, deleting all IP addresses belonging to the target beam subnet, and releasing these IP address resources.

9. A simulation method for a multi-beam system of a low-Earth orbit satellite network service link according to claim 8, characterized in that, In step S6, maintaining an independent dynamic IP address pool for each beam specifically includes: maintaining an independent IP address pool for each beam of each satellite, the number of IP address pools maintained for each satellite being equal to the number of configured beams, the IP address pools automatically excluding network addresses, broadcast addresses, and gateway addresses, containing only available IP addresses, supporting thread-safe IP address allocation and reclamation operations, preventing concurrent access conflicts, and providing an IP address usage query interface to support statistics and monitoring; The dynamic allocation and reclamation of VLAN IDs and subnet resources specifically includes: dynamically allocating and reclamating VLAN IDs, maintaining a set of used VLAN IDs, allocating VLAN IDs for satellite beams incrementally starting from an initial value, ensuring the number of VLAN IDs allocated to each satellite equals the configured number of beams, and allocating VLAN IDs for user terminals starting from a larger initial value to ensure no conflict between the two, supporting VLANs. ID conflict detection and automatic reallocation; independent subnets are allocated to each beam of each satellite, with the number of subnets allocated to each satellite equal to the number of configured beams. Subnets are allocated incrementally starting from the initial subnet address, maintaining the set of allocated subnets to ensure no overlap and supporting large-scale deployment; independent frequency resources are allocated and managed to each beam of each satellite, with the number of frequency points allocated to each satellite equal to the number of configured beams. Frequency points are allocated incrementally at set intervals starting from the initial frequency point, maintaining the set of allocated frequency points to ensure different beams use different frequencies to avoid co-channel interference, supporting frequency conflict detection and automatic reallocation; independent transmit power parameters are configured and managed for each beam, with the number of power parameters configured for each satellite equal to the number of configured beams, supporting dynamic updates and optimization of power parameters, achieving intelligent allocation and management of power resources; The monitoring of container lifecycle and automatic cleanup of all related resources when a container is deleted specifically includes: monitoring container status, and automatically cleaning up all related resources when a container is deleted, including deleting veth pairs, reclaiming VLAN IDs, clearing connection records, and returning IP addresses to the IP address pool to prevent resource leakage.

10. A simulation system for a multi-beam system of low-Earth orbit satellite network service links, characterized in that, The system consists of four parts: (1) Core aggregation layer: realizes traffic aggregation and isolation between containers based on Linux bridge and VLAN filtering; (2) Satellite multi-beam network layer: creates satellite containers and configures multiple beam sub-interfaces for satellite containers, supporting multi-beam concurrent services; (3) User terminal dynamic connection layer: creates user terminal containers and provides dynamic connection and beam switching capabilities for user terminal containers; (4) Resource management layer: manages network resources such as VLAN ID, subnet and IP address pool; the system executes the method as described in any one of claims 1 to 9.

Images