A cross-satellite IP network access system of LEO constellation

Abstract

The application provides a LEO constellation cross-satellite-ground IP network access system, relates to the field of satellite computing, and aims to solve the problem of insufficient dynamic adaptability of related cross-satellite-ground LEO constellation network access schemes in a complex satellite-ground network environment. The system comprises a control end deployed on a specific ground server; the control end comprises at least a space-time routing control module and a device management module; the space-time routing control module is used for calculating an optimal GSL establishment plan in real time according to the relative position of a ground station and a satellite and communication requirements; the device management module dynamically updates the routing configuration of each client and each relay end according to the space-time routing data provided by the space-time routing control module; and each client accesses the cross-satellite-ground network through a relay end via a virtual network card driver module according to the routing configuration provided by the device management module.

Description

Technical Field

[0001] This application relates to the field of satellite computing, and more specifically, to a cross-satellite-to-ground IP network access system for the LEO constellation. Background Technology

[0002] Low Earth Orbit (LEO) satellites are closer to the ground, resulting in lower data transmission latency compared to satellites operating in higher orbits. LEO constellations consist of multiple LEO satellites, typically in CubeSat or nanosatellite format, offering high coverage and low latency, making them suitable for tasks such as real-time remote sensing and disaster monitoring. The deployment, operation, and data transmission of these tasks require the support of a cross-satellite-to-ground LEO constellation network.

[0003] Related cross-satellite LEO constellation network access technologies are mainly divided into IP network access and Ethernet access, but their specific implementation forms are all based on pre-configured fixed paths and endpoints to realize cross-satellite data transmission network tunnels. These solutions are reliable in simple scenarios, but they exhibit obvious defects in complex and large-scale networks, such as insufficient dynamic adaptability, limited path optimization capabilities, and poor system scalability. Summary of the Invention

[0004] This application provides a cross-satellite-to-ground IP network access system for LEO constellations, aiming to solve the problems of insufficient dynamic adaptability, limited path optimization capability, and poor system scalability of related cross-satellite-to-ground LEO constellation network access technologies in complex satellite-to-ground network environments.

[0005] The first aspect of this application provides a cross-satellite-to-ground IP network access system for the LEO constellation, comprising:

[0006] Multiple clients are deployed on satellite payloads that need to access the cross-satellite-to-ground network, and multiple clients are deployed on ground servers, each client having a virtual network interface card driver module deployed on it;

[0007] Multiple relay terminals deployed at ground stations, multiple relay terminals deployed on satellite platforms, and one satellite platform carrying one or more satellite payloads; a relay terminal deployed at a ground station and a relay terminal deployed on a satellite platform are connected via a satellite-to-ground link for communication.

[0008] A control terminal deployed on a specific ground server, which is different from any ground server on which the client is deployed;

[0009] The control terminal includes at least: a spatiotemporal routing control module and an equipment management module; the spatiotemporal routing control module is used to calculate the optimal GSL establishment plan in real time based on the relative position of the ground station and the satellite and the communication requirements.

[0010] The device management module dynamically updates the routing configuration of each client and each relay based on the spatiotemporal routing data provided by the spatiotemporal routing control module.

[0011] Each client accesses the inter-satellite network via the relay terminal through the virtual network card driver module, according to the routing configuration provided by the device management module.

[0012] In one alternative implementation, each client is equipped with a slave node module, which sends a registration request to the device management module in the control terminal via a relay.

[0013] The relay terminal sends a registration request to the device management module in the control terminal;

[0014] The device management module, in response to a received registration request, obtains the basic information of the device corresponding to the registration request and generates a unique identifier; based on the basic information of the device and the corresponding identifier, it performs identity authentication on the device, and if the identity authentication is successful, it registers the device to the LEO constellation's cross-satellite IP network access system; and it detects the basic performance of the device to obtain the device's performance parameters, which include: bandwidth requirements, transmission latency, and processing capacity.

[0015] In an optional implementation, the device management module is further configured to:

[0016] The system monitors the operational status of each device registered to the LEO constellation's cross-satellite-to-ground IP network access system, and obtains the status information of each device, including: bandwidth utilization and transmission latency.

[0017] Based on the status information of each device, determine whether the device is at risk of malfunction or performance degradation;

[0018] In the event of a device malfunction or performance degradation, the spatiotemporal routing control module is instructed to reconfigure or switch the links involved in that device.

[0019] In one optional implementation, the control terminal further includes: a status monitoring module; the status monitoring module is used for:

[0020] Real-time monitoring of the real-time connection status of each device registered to the LEO constellation's cross-satellite IP network access system, and assessment of network quality based on the real-time connection status of each device;

[0021] If the network quality does not meet the communication requirements, the spatiotemporal routing control module is instructed to reconfigure or switch the links involved in the device.

[0022] In an optional implementation, the spatiotemporal routing control module is further configured to:

[0023] Dynamically adjust access policies to switch or reconfigure links;

[0024] The access policy includes at least one of the following:

[0025] Connect to the satellite with the longest remaining service time until the satellite moves out of the transmission range;

[0026] Connect to the nearest satellite until the satellite disappears out of range;

[0027] Always connect to the nearest satellite.

[0028] In one alternative implementation, each client has a slave node module and a master node module deployed on it, with one of the master node modules being active; each client sends a cross-satellite network creation request to the active master node module through the slave node module.

[0029] The active master node module receives the cross-satellite network configuration sent by the control terminal; when it receives a cross-satellite network creation request from a client, it configures a virtual network card for the client and performs network initialization according to the cross-satellite network configuration.

[0030] After completing network initialization for all clients to be connected, the active master node module replies to the control terminal with a message indicating that the cross-satellite-to-ground network creation is complete.

[0031] When the active master node module receives a cross-satellite-to-ground network disassembly request from a client, it deletes the virtual network interface card configured for that client.

[0032] After deleting the virtual network cards from all connected clients, the active master node module replies to the control terminal with a message indicating that the cross-satellite-to-ground network dismantling is complete.

[0033] In one optional implementation, after configuring a virtual network card for the client and performing network initialization according to the cross-satellite-to-ground network configuration, the routing type corresponding to the cross-satellite-to-ground network configuration is determined.

[0034] When the routing type is such that the client and the target client are deployed on the same satellite platform, data packets between the client and the target client are forwarded within the same satellite platform;

[0035] If the routing type is set to target client, the client's data packets are forwarded to the client's virtual network interface card.

[0036] When the routing type is such that the client is deployed on a satellite platform and the target client is deployed on a ground station, data packets between the client and the target client are forwarded via a relay.

[0037] In one optional implementation, after the spatiotemporal routing control module completes the link switching or reconfiguration, it sends a route update request to each relay terminal.

[0038] The relay terminal responds to the route update request by updating the route configuration; after completing the route configuration update, it replies with an update completion message to the spatiotemporal route control module.

[0039] In one optional implementation, after the relay updates the routing configuration, the routing type corresponding to the routing configuration is determined.

[0040] When the relay and the target client are deployed on the same satellite platform, data packets between the relay and the target client are forwarded within the same satellite platform.

[0041] When the routing type is such that the relay is deployed on a satellite platform and the target client is deployed on another satellite platform, data packets between the client and the target client are forwarded via the relay on the other satellite platform.

[0042] In one alternative implementation, a first relay terminal deployed on a first satellite platform and a second relay terminal deployed on a second satellite platform are connected via an inter-satellite link.

[0043] When the quality of the direct satellite-to-ground link between the ground station's relay terminal and the second relay terminal does not meet the communication requirements, the spatiotemporal routing control module switches the communication link between the ground station's relay terminal and the second relay terminal to a link with the inter-satellite link as the relay path.

[0044] The LEO constellation cross-satellite-to-ground IP network access system provided in this application comprises multiple clients deployed on satellite payloads to access the cross-satellite-to-ground network, and multiple clients deployed on ground servers, each client having a virtual network interface card (NIC) driver module; multiple relays deployed on ground stations, and multiple relays deployed on satellite platforms, each satellite platform carrying one or more satellite payloads; a relay deployed on a ground station and a relay deployed on a satellite platform are connected via a satellite-to-ground link; and a control terminal deployed on a specific ground server, which is different from any of the ground servers with clients deployed. The control terminal includes at least a spatiotemporal routing control module and a device management module. The spatiotemporal routing control module calculates the optimal GSL establishment plan in real time based on the relative position and communication requirements of the ground station and the satellite. The device management module dynamically updates the routing configuration of each client and each relay based on the spatiotemporal routing data provided by the spatiotemporal routing control module. Each client accesses the cross-satellite-to-ground network via the relay through the virtual NIC driver module, according to the routing configuration provided by the device management module.

[0045] The spatiotemporal routing control module at the control end calculates the optimal GSL establishment plan in real time and provides spatiotemporal routing data to the device management module at the control end to dynamically update the routing configuration of each client and each relay. Each client accesses the cross-satellite-to-ground network via the relay according to the routing configuration provided by the device management module. Through the collaborative work of the client, relay, and control end, dynamic routing calculation and real-time configuration updates are achieved, providing excellent path optimization capabilities and efficient data transmission. Furthermore, the system can automatically adjust its configuration through flexible network orchestration, improving system scalability and effectively addressing the dynamic environment and large-scale networking requirements of the LEO constellation. Attached Figure Description

[0046] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 This is a schematic diagram illustrating the implementation principle of a satellite-to-ground IP network tunnel according to an embodiment of this application;

[0048] Figure 2 This is a schematic diagram of the structure of a cross-satellite IP network access system for the LEO constellation proposed in one embodiment of this application;

[0049] Figure 3This is an architecture diagram of a cross-satellite IP network access system for the LEO constellation proposed in one embodiment of this application;

[0050] Figure 4 This is a core flowchart of the client master node module of the LEO constellation cross-satellite IP network access system proposed in one embodiment of this application;

[0051] Figure 5 This is a core flowchart of the client slave node module of the LEO constellation cross-satellite IP network access system proposed in one embodiment of this application;

[0052] Figure 6 This is a core flowchart of the relay end of the LEO constellation cross-satellite IP network access system proposed in one embodiment of this application;

[0053] Figure 7 This is a functional architecture diagram of a cross-satellite IP network access system for the LEO constellation proposed in one embodiment of this application;

[0054] Figure 8 This is a core flowchart of the control terminal of the LEO constellation cross-satellite IP network access system proposed in one embodiment of this application. Detailed Implementation

[0055] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0056] In the accompanying drawings, the size of constituent elements, the thickness of layers, or areas may sometimes be exaggerated for clarity. Therefore, any implementation of this disclosure is not necessarily limited to the dimensions shown in the drawings, and the shapes and sizes of the components in the drawings do not reflect true proportions. Furthermore, the drawings schematically illustrate ideal examples, and any implementation of this disclosure is not limited to the shapes or values ​​shown in the drawings.

[0057] Low Earth Orbit (LEO) satellites are Earth satellites orbiting at altitudes below 2000 kilometers. Due to their shorter distance from the ground, LEO satellites experience significantly less data transmission latency compared to satellites operating in higher orbits (such as minimum Earth orbit and geostationary equatorial orbit). Signals leaving the satellite can reach a visible ground station within approximately 0.05 seconds. An LEO constellation is a constellation of multiple LEO satellites, typically CubeSats or nanosatellites. LEO constellations offer advantages such as high coverage and low latency, making them suitable for missions such as on-orbit data preprocessing, real-time remote sensing image analysis, and disaster monitoring. The deployment, operation, and data transmission of these missions require the support of a cross-satellite-to-ground LEO constellation network.

[0058] Existing cross-satellite LEO constellation network access technologies can be broadly categorized into IP network access and Ethernet access based on the OSI network layer used. However, their specific implementations all rely on pre-configured fixed paths and endpoints to create cross-satellite data transmission network tunnels. Taking a cross-satellite IP network tunnel as an example... Figure 1 As shown, its specific implementation principle can be described as follows:

[0059] During the network initialization phase, network administrators manually configure the path for each tunnel based on the orbital parameters of the LEO satellites and the geographical locations of the ground stations. These paths define: the tunnel's starting point (LEO satellite payload / ground server) and ending point (LEO satellite payload / ground server); the fixed IP address range for the tunnel, used to identify data flows over the tunnel; and the link timing required for data transmission, including the satellite's view window and tunnel switching rules.

[0060] IP static tunnels achieve data transmission through encapsulation technology. After data packets are generated at the application layer, they are encapsulated into IP tunnels by the ground station's tunnel management module, with tunnel header information (LEO satellite payload / ground server IP) appended. The data packets are transmitted to the target node along a fixed path, which remains unchanged regardless of link status changes. At the target node, the tunnel header information is removed, and the data packets are restored to their original format for subsequent processing.

[0061] When a ground station establishes a communication link with a target satellite, the tunnel automatically starts according to the path configuration. When the satellite moves out of the ground station's coverage area, the tunnel immediately disconnects, and data transmission is interrupted. At this point, the ground station must wait to establish a new tunnel with the next satellite it can cover.

[0062] Existing cross-satellite LEO constellation network access technologies offer a degree of reliability in simple satellite-to-ground communication scenarios, but their technical shortcomings are also evident. Insufficient dynamic adaptability: LEO satellites move at high speeds, have short coverage windows, and static paths interrupt coverage when satellites exceed their range, making it impossible to dynamically adjust paths to adapt to changes in link status. Difficulty in optimizing transmission performance: Fixed path designs cannot adapt to changes in link quality, cannot utilize inter-satellite links (ISL) to optimize paths, and lack load balancing capabilities. Limited scalability: As the number of satellites and ground stations increases, the complexity of path configuration grows exponentially. Adding new nodes or links requires reconfiguring paths, resulting in a slow and costly expansion process.

[0063] In view of the above problems, this application proposes a cross-satellite-to-ground IP network access system for the LEO constellation, aiming to overcome the limitations of traditional cross-satellite-to-ground network tunneling schemes in complex satellite-to-ground network environments, and solve their problems of insufficient dynamic adaptability, limited path optimization capabilities, and poor system scalability. The following, in conjunction with the accompanying drawings, provides a detailed description of the cross-satellite-to-ground IP network access system for the LEO constellation provided by this application through some embodiments and application scenarios.

[0064] Reference Figure 2 , Figure 2 This is a schematic diagram of the structure of the LEO constellation cross-satellite IP network access system proposed in Embodiment 1 of this application. Figure 2 As shown, the system includes:

[0065] Multiple clients are deployed on satellite payloads that need to access the cross-satellite-to-ground network, and multiple clients are deployed on ground servers, each client having a virtual network interface card driver module deployed on it;

[0066] Multiple relay terminals deployed at ground stations, multiple relay terminals deployed on satellite platforms, and one satellite platform carrying one or more satellite payloads; a relay terminal deployed at a ground station and a relay terminal deployed on a satellite platform are connected via a satellite-to-ground link for communication.

[0067] A control terminal deployed on a specific ground server, which is different from any ground server on which the client is deployed;

[0068] The control terminal includes at least: a spatiotemporal routing control module and an equipment management module; the spatiotemporal routing control module is used to calculate the optimal GSL establishment plan in real time based on the relative position of the ground station and the satellite and the communication requirements.

[0069] The device management module dynamically updates the routing configuration of each client and each relay based on the spatiotemporal routing data provided by the spatiotemporal routing control module.

[0070] Each client accesses the inter-satellite network via the relay terminal through the virtual network card driver module, according to the routing configuration provided by the device management module.

[0071] In this embodiment, the client is the access point for the cross-satellite network, deployed on both the ground server and the satellite payload. It is responsible for accessing the cross-satellite network via a virtual network interface card (NIC) driver module and relays, according to the routing configuration provided by the control terminal. The relays are deployed on both the satellite platform and the ground station, serving as relays and gateways between the satellite and ground networks. The virtual NIC driver module deployed on each client virtualizes the network interface, supporting dynamic routing configuration and data transmission. During each client's access to the cross-satellite network, the spatiotemporal routing control module of the control terminal calculates the optimal GSL (Ground-to-Satellite Link) establishment plan based on the relative positions of the ground station and the satellite and communication requirements, thereby establishing a communication link between the relays at the ground station and the satellite platform. The device management module of the control terminal updates the routing configurations of the client and relays based on the calculated optimal GSL spatiotemporal routing data. The client then accesses the cross-satellite network via the relays through the virtual NIC driver module, following the updated routing configuration, to transmit data. As the relative positions of the ground station and the satellite change, the control terminal can adjust the GSL establishment plan and routing configuration in real time to ensure the continuity and stability of network communication.

[0072] The spatiotemporal routing control module at the control end calculates the optimal GSL establishment plan in real time and provides spatiotemporal routing data to the device management module at the control end to dynamically update the routing configuration of each client and each relay. Each client accesses the cross-satellite-to-ground network via the relay according to the routing configuration provided by the device management module. Through the collaborative work of the client, relay, and control end, dynamic routing calculation and real-time configuration updates are achieved, providing excellent path optimization capabilities and efficient data transmission. Furthermore, the system can automatically adjust its configuration through flexible network orchestration, improving system scalability and effectively addressing the dynamic environment and large-scale networking requirements of the LEO constellation.

[0073] In one alternative implementation, each client is equipped with a slave node module, which sends a registration request to the device management module in the control terminal via a relay.

[0074] The relay terminal sends a registration request to the device management module in the control terminal;

[0075] The device management module, in response to a received registration request, obtains the basic information of the device corresponding to the registration request and generates a unique identifier; based on the basic information of the device and the corresponding identifier, it performs identity authentication on the device, and if the identity authentication is successful, it registers the device to the LEO constellation's cross-satellite IP network access system; and it detects the basic performance of the device to obtain the device's performance parameters, which include: bandwidth requirements, transmission latency, and processing capacity.

[0076] like Figure 3 As shown, each client has a slave node module deployed on it. The slave node module is the main communication module of the client, responsible for establishing cross-satellite-to-ground network connections with the slave node modules and master node modules of other clients, and for data transmission and routing selection through cross-satellite-to-ground IP addresses. Within a cross-satellite-to-ground IP network access of a LEO constellation, the slave node modules and virtual network card driver modules of all connected devices are active and running.

[0077] Each client can send a registration request to the device management module in the control unit via its corresponding slave node module through the relay end. The registration request is the first step for a device to access the inter-satellite IP network and includes basic device information (such as device type, IP address, MAC address, hardware configuration, etc.) to ensure the device can be recognized and managed by the system. In response to the received registration request, the device management module extracts the basic device information and registers the device to the LEO constellation's inter-satellite IP network access system. During registration, the device management module generates a unique identifier for each device and verifies its legitimacy through authentication. The registration process also includes basic device performance checks, such as bandwidth requirements, transmission latency, and processing capacity, to ensure the system can allocate resources reasonably based on device characteristics.

[0078] In an optional implementation, the device management module is further configured to:

[0079] The system monitors the operational status of each device registered to the LEO constellation's cross-satellite-to-ground IP network access system, and obtains the status information of each device, including: bandwidth utilization and transmission latency.

[0080] Based on the status information of each device, determine whether the device is at risk of malfunction or performance degradation;

[0081] In the event of a device malfunction or performance degradation, the spatiotemporal routing control module is instructed to reconfigure or switch the links involved in that device.

[0082] In this embodiment, the device management module monitors the operational status of each device registered in the LEO constellation's cross-satellite-to-ground IP network access system in real time. It obtains status information for each device, including bandwidth utilization and transmission latency, by periodically sending operational status query requests (such as SNMP protocol or custom heartbeat packets). Based on the status information of each device, the device management module uses threshold analysis and trend analysis to determine whether the device is at risk of failure or performance degradation. If a device is at risk of failure or performance degradation, the device management module immediately activates the fault handling mechanism, instructing the spatiotemporal routing control module to reconfigure or switch the links involved in the device to ensure network continuity and stability and avoid communication interruptions caused by device failure or performance degradation.

[0083] In one optional implementation, the control terminal further includes: a status monitoring module; the status monitoring module is used for:

[0084] Real-time monitoring of the real-time connection status of each device registered to the LEO constellation's cross-satellite IP network access system, and assessment of network quality based on the real-time connection status of each device;

[0085] If the network quality does not meet the communication requirements, the spatiotemporal routing control module is instructed to reconfigure or switch the links involved in the device.

[0086] In this embodiment, the status monitoring module at the control end monitors the real-time connection status (such as online status, response time, packet loss rate, etc.) of each device registered in the cross-satellite-to-ground IP network access system of the LEO constellation, that is, periodically collecting the connection status of each client and relay device. Based on the real-time connection status of the devices, network quality indicators (such as latency, jitter, packet loss rate, bandwidth utilization, etc.) are calculated, and the calculated network quality indicators are compared with preset communication requirement thresholds to comprehensively evaluate the network quality. If the network quality does not meet the communication requirements, the status monitoring module instructs the spatiotemporal routing control module to reconfigure or switch the links involved in the device. The status monitoring module not only monitors the devices in real time, but also evaluates the network quality of GSL to ensure that the cross-satellite-to-ground network can always meet the communication requirements.

[0087] In an optional implementation, the spatiotemporal routing control module is further configured to:

[0088] Dynamically adjust access policies to switch or reconfigure links;

[0089] The access policy includes at least one of the following:

[0090] Connect to the satellite with the longest remaining service time until the satellite moves out of the transmission range;

[0091] Connect to the nearest satellite until the satellite disappears out of range;

[0092] Always connect to the nearest satellite.

[0093] In this embodiment, the spatiotemporal routing control module can respond to instructions from the device management module or the status monitoring module, and dynamically adjust the appropriate connection path based on the relative position of the ground station and the satellite and communication requirements. This means dynamically adjusting the access strategy to switch or reconfigure the link. Due to the periodic changes in the orbits of LEO satellites, the establishment and switching of GSLs require optimization based on real-time spatiotemporal data. The spatiotemporal routing control module selects the optimal satellite for access based on the satellite's orbital data and the changes in the ground station's position. To address different mission requirements, the spatiotemporal routing control module provides several different satellite platform-ground station link binding strategies (access strategies), which can generally be categorized into three types based on their satellite selection criteria: connecting to the satellite with the longest remaining service time until it moves out of the transmission range; connecting to the nearest satellite until it disappears out of the transmission range; and always connecting to the nearest satellite, i.e., immediately switching to the nearest satellite if available.

[0094] Due to the low-Earth orbit characteristics of LEO satellites, the connection between satellites and ground stations is intermittent. The spatiotemporal routing control module can monitor the device connection status in real time through the status monitoring module and dynamically adjust the access strategy based on real-time data to avoid communication interruptions caused by satellite failures or outages. Given the new characteristics of the LEO constellation compared to the GEO constellation—the exponential increase in the number of satellites and the relative scarcity of ground stations—the role of the spatiotemporal routing control module becomes particularly important. The spatiotemporal routing control module can adjust the access link in real time to ensure that ground stations can access suitable satellites, maximizing network quality and bandwidth utilization.

[0095] In one optional implementation, the control terminal further includes a cross-satellite-to-ground network management module; the cross-satellite-to-ground network management module distributes configuration instructions to the corresponding clients and relays according to the access policy dynamically adjusted by the spatiotemporal routing control module, so as to realize the switching or reconfiguration of the link.

[0096] In this embodiment, the cross-satellite-to-ground network management module can receive access policies from the spatiotemporal routing control module and distribute configuration instructions to client and relay devices according to different needs, performing link switching or reconfiguration to achieve dynamic scheduling of network resources. Through collaboration with other modules, the cross-satellite-to-ground network management module ensures that the network can adjust according to real-time GSL status and needs, guaranteeing the efficiency and stability of the cross-satellite-to-ground IP network and enabling it to dynamically adapt to complex satellite-to-ground communication environments.

[0097] In one alternative implementation, each client has a slave node module and a master node module deployed on it, with one of the master node modules being active; each client sends a cross-satellite network creation request to the active master node module through the slave node module.

[0098] The active master node module receives the cross-satellite network configuration sent by the control terminal; when it receives a cross-satellite network creation request from a client, it configures a virtual network card for the client and performs network initialization according to the cross-satellite network configuration.

[0099] After completing network initialization for all clients to be connected, the active master node module replies to the control terminal with a message indicating that the cross-satellite-to-ground network creation is complete.

[0100] When the active master node module receives a cross-satellite-to-ground network disassembly request from a client, it deletes the virtual network interface card configured for that client.

[0101] After deleting the virtual network cards from all connected clients, the active master node module replies to the control terminal with a message indicating that the cross-satellite-to-ground network dismantling is complete.

[0102] like Figure 3 As shown, each client deploys a slave node module and a master node module. The main function of the client is to realize cross-satellite-to-ground network access and data transmission in the orbital edge computing environment. Within a network access system, the slave node modules and virtual network interface card (NIC) driver modules of all connected devices are active, but only the master node module of one device is active. The slave node module is responsible for establishing cross-satellite-to-ground network connections with the slave node modules and master node modules of other clients, and for data transmission and routing selection through cross-satellite-to-ground IP addresses. The master node module undertakes centralized management of the cross-satellite-to-ground network, is responsible for the access and IP allocation of slave node modules, and maintains routing within the network access system. The virtual NIC driver module provides a virtual Ethernet interface for the system, enabling clients to receive and send data in the form of network frames. Through the virtual NIC driver module, client data can be encapsulated as cross-satellite-to-ground network traffic, isolated from the actual physical network.

[0103] In one embodiment, such as Figure 4 As shown, Figure 4This is a core flowchart of the client master node module illustrated in one embodiment of this application. Each client sends a cross-satellite network creation request to the active master node module through the slave node module. The active master node module can receive cross-satellite network configuration sent by the control terminal. Upon receiving a cross-satellite network creation request from a client, it can configure a virtual network interface card (NIC) for that client and perform network initialization according to the cross-satellite network configuration. After completing network initialization for all clients to be connected, the active master node module replies to the control terminal with a cross-satellite network creation completion message and starts the cross-satellite network heartbeat. When the active master node module receives a cross-satellite network dismantling request from a client, it deletes the virtual NIC configured for that client; after deleting the virtual NICs for all connected clients, the active master node module replies to the control terminal with a cross-satellite network dismantling completion message. The master node module may also receive messages with the master node as the destination ID, including client control messages from the control terminal and client control messages (slave node query requests, slave node exit notifications) from other client slave nodes. For slave node query requests, determine if the corresponding slave node module is making its first query. If it is, update the cross-satellite-to-ground network creation progress. If it is not, query the slave node's query target route and reply to the corresponding client. For slave node exit notifications, update the cross-satellite-to-ground network dismantling progress and reply to the corresponding client.

[0104] In one optional implementation, after configuring a virtual network card for the client and performing network initialization according to the cross-satellite-to-ground network configuration, the routing type corresponding to the cross-satellite-to-ground network configuration is determined.

[0105] When the routing type is such that the client and the target client are deployed on the same satellite platform, data packets between the client and the target client are forwarded within the same satellite platform;

[0106] If the routing type is set to target client, the client's data packets are forwarded to the client's virtual network interface card.

[0107] When the routing type is such that the client is deployed on a satellite platform and the target client is deployed on a ground station, data packets between the client and the target client are forwarded via a relay.

[0108] like Figure 5 As shown, Figure 5This is a core flowchart of the client slave node module shown in one embodiment of this application. After the client completes the virtual network interface card configuration and network initialization, it determines the routing type corresponding to the cross-satellite-to-ground network configuration. When the routing type is that the client and the target client are deployed on the same satellite platform (target device), data packets between the client and the target client are forwarded within the same satellite platform. When the routing type is that the client is the target client (target device is this device), the client's data packets are forwarded to the client's virtual network interface card. When the routing type is that the client is deployed on a satellite platform and the target client is deployed on a ground station, data packets between the client and the target client are forwarded via a relay. The slave node module may also receive messages with the slave node as the destination ID, including client control messages from the control end, such as registration requests. These registration requests originate from the original registration request sent by the client and are returned by the control end. After receiving the request, the slave node module initializes the routing configuration, performs a relay connectivity test, replies to the control end with a registration completion message, and starts the device heartbeat. Each client sends a cross-satellite-to-ground network creation request to the active master node module through the slave node module. For cross-satellite network creation requests, the slave node module queries the master node module to create a network interface card (NIC) device, binds the virtual NIC, and replies to the control terminal after completing the cross-satellite network creation, initiating the cross-satellite network heartbeat. For cross-satellite network dismantling requests, the slave node module deletes the virtual NIC binding and replies to the control terminal with an exit message.

[0109] In one optional implementation, after the spatiotemporal routing control module completes the link switching or reconfiguration, it sends a route update request to each relay terminal.

[0110] The relay terminal responds to the route update request by updating the route configuration; after completing the route configuration update, it replies with an update completion message to the spatiotemporal route control module.

[0111] In this embodiment, the relay terminal acts as a relay module between on-board clients and ground clients in the network access system, and as the controller of the satellite-to-ground station GSL. It supports cross-satellite and inter-satellite data forwarding and relays control requests from on-board clients. The device deploying the relay terminal is not considered part of the network access system and is transparent to other clients. The relay terminal, originating from the network topology of a specific cross-satellite network from the control terminal, completes data forwarding within the same network access system and performs outer data encapsulation for GSL communication at the satellite platform-to-ground station system data entry and exit points. Based on the spatiotemporal routing control results from the control terminal, the relay terminal controls the satellite platform and ground station to establish and switch GSLs at specific times.

[0112] like Figure 6 As shown, Figure 6This is a core flowchart of a relay terminal illustrated in one embodiment of this application. After the spatiotemporal routing control module completes link switching or reconfiguration, it receives route update requests sent by the spatiotemporal routing control module to each relay terminal. The relay terminal responds to the route update request, updates its routing configuration, and after completing the update, replies with an update completion message to the spatiotemporal routing control module. The relay terminal may also receive client control messages from the control terminal, such as registration requests. These registration requests originate from the original registration request sent by the relay terminal and are returned by the control terminal. Upon receiving this request, the relay terminal initializes its routing configuration, performs a relay terminal connectivity test, replies with a registration completion message to the control terminal, and initiates a device heartbeat.

[0113] In one optional implementation, after the relay updates the routing configuration, the routing type corresponding to the routing configuration is determined.

[0114] When the relay and the target client are deployed on the same satellite platform, data packets between the relay and the target client are forwarded within the same satellite platform.

[0115] When the routing type is such that the relay is deployed on a satellite platform and the target client is deployed on another satellite platform, data packets between the client and the target client are forwarded via the relay on the other satellite platform.

[0116] like Figure 6 As shown, after the relay updates the routing configuration, it determines the routing type corresponding to the routing configuration. When the routing type is that the relay and the target client are deployed on the same satellite platform (the target device is a device on the same satellite platform), the data packets between the relay and the target client are forwarded within the local area network of the same satellite platform. When the routing type is that the relay is deployed on a satellite platform and the target client is deployed on another satellite platform, the data packets between the client and the target client are forwarded via the relay on the other satellite platform, that is, forwarded to other relays.

[0117] In one alternative implementation, a first relay terminal deployed on a first satellite platform and a second relay terminal deployed on a second satellite platform are connected via an inter-satellite link.

[0118] When the quality of the direct satellite-to-ground link between the ground station's relay terminal and the second relay terminal does not meet the communication requirements, the spatiotemporal routing control module switches the communication link between the ground station's relay terminal and the second relay terminal to a link with the inter-satellite link as the relay path.

[0119] like Figure 3As shown, the first relay terminal deployed on the first satellite platform and the second relay terminal deployed on the second satellite platform are connected via an inter-satellite link. The spatiotemporal routing control module can monitor the device connection status in real time through the status monitoring module. Based on factors such as the current network topology, the relative positions of the ground station and the satellite, and communication requirements, it determines whether the quality of the direct satellite-to-ground link between the ground station's relay terminal and the second relay terminal meets the communication requirements. If the communication requirements are not met, the communication link between the ground station's relay terminal and the second relay terminal is switched to a link using the inter-satellite link as the relay path. This automatic switching to an inter-satellite link when the quality of the satellite-to-ground link between the ground station and the satellite does not meet the communication requirements ensures the continuity and reliability of communication.

[0120] Reference Figure 7 , Figure 7 This is a functional architecture diagram of a cross-satellite IP network access system for the LEO constellation proposed in one embodiment of this application. Figure 7 As shown, the functions of the LEO constellation's cross-satellite IP network access system are:

[0121] The LEO constellation's cross-satellite IP network access system consists of three subsystems: client, relay, and control. Specifically, it includes multiple clients deployed on satellite payloads and ground servers to be connected to the cross-satellite network, multiple relays deployed on ground station systems and satellite platforms, and a control terminal that operates as the network access system control center on a specific ground server.

[0122] The client is responsible for cross-satellite network access and local management within the network (such as IP allocation and network routing), and provides cross-satellite network interfaces for orbital edge computing tasks. It is responsible for packet encapsulation and decapsulation, converting traffic into standard IP traffic, and transmitting it through the network access system via the client.

[0123] Relay terminals are deployed within satellite platforms and ground station systems, serving as relays and gateways between satellite networks and terrestrial networks.

[0124] The control unit is responsible for processing cross-satellite-to-ground network control requests and managing the overall cross-satellite-to-ground network. Its main functions include cross-satellite-to-ground network construction control, spatiotemporal routing control, cross-satellite-to-ground network status management, and client and relay status management. Through interaction with clients and relays, dynamic configuration and efficient management of the cross-satellite-to-ground network can be achieved. (See...) Figure 8 .

[0125] This application's LEO constellation cross-satellite-to-ground IP network access system improves the dynamic adaptability, availability, and scalability of cross-satellite-to-ground networks in LEO constellations and in large-scale LEO constellation networking by integrating network access, cross-satellite-to-ground network management, and access device management. Specifically:

[0126] By combining the spatial and temporal dimensions of routing calculation and control across satellite-to-ground networks, the system transforms network access control from a static strategy at a specific moment into a dynamic strategy spanning time periods. Through satellite orbit prediction and real-time link status monitoring, the system achieves intelligent path switching and adjustment, avoiding path redundancy and communication interruptions. The system can complete route switching before a satellite enters the coverage area of ​​a ground station, ensuring the continuity of data flow.

[0127] By incorporating ground station access control into satellite-to-ground link optimization, the system enhances link high availability through satellite-to-ground collaborative management. Combining various satellite-to-ground connection strategies (such as LRST, NSD, and NSH), the system can dynamically select the optimal link, maximizing link utilization and ensuring transmission stability. For example, when multiple satellites simultaneously cover a ground station, the system prioritizes satellites with lighter loads or longer service times, effectively solving the problem of insufficient link resource utilization in traditional solutions.

[0128] Including relay nodes (such as LEO satellite platforms and ground stations) and network endpoints (such as satellite payloads and ground servers) in status monitoring and lifecycle management expands the scope of equipment management. By collecting equipment operation data in real time and dynamically adjusting configurations, the system enhances network stability and scalability.

[0129] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0130] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, electronic devices, and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0131] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1The function specified in one or more boxes.

[0132] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0133] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0134] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0135] The above provides a detailed description of a cross-satellite IP network access system for the LEO constellation provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A cross-satellite IP network access system for the LEO constellation, characterized in that, include: Multiple clients are deployed on satellite payloads that need to access the cross-satellite-to-ground network, and multiple clients are deployed on ground servers, each client having a virtual network interface card driver module deployed on it; Multiple relay terminals deployed at ground stations, multiple relay terminals deployed on satellite platforms, and one or more satellite payloads carried on a single satellite platform; A relay station deployed at a ground station and a relay station deployed on a satellite platform are connected via a satellite-to-ground link. A control terminal deployed on a specific ground server, which is different from any ground server on which the client is deployed; The control terminal includes at least: a spatiotemporal routing control module and an equipment management module; the spatiotemporal routing control module is used to calculate the optimal GSL establishment plan in real time based on the relative position of the ground station and the satellite and the communication requirements. The device management module dynamically updates the routing configuration of each client and each relay based on the spatiotemporal routing data provided by the spatiotemporal routing control module. Each client accesses the cross-satellite-to-ground network via a relay terminal through the virtual network card driver module, according to the routing configuration provided by the device management module. Each client also deploys a slave node module and a master node module. All slave node modules and virtual network interface card (NIC) driver modules are active and running. One master node module is active among all master node modules. The slave node modules are responsible for establishing cross-satellite network connections with the slave node modules and master node modules of other clients, and for data transmission and routing through cross-satellite IP addresses. The master node modules are responsible for the centralized management of the cross-satellite network, including slave node access, IP allocation, and maintaining routing within the network access system. The virtual NIC driver module provides a virtual Ethernet interface for the system, enabling the clients to receive and send data in the form of network frames.

2. The LEO constellation cross-satellite IP network access system according to claim 1, characterized in that, Each client has a slave node module deployed on it, and the slave node module sends a registration request to the device management module in the control terminal via a relay terminal. The relay terminal sends a registration request to the device management module in the control terminal; The device management module, in response to a received registration request, obtains the basic information of the device corresponding to the registration request and generates a unique identifier; based on the basic information of the device and the corresponding identifier, it performs identity authentication on the device, and if the identity authentication is successful, it registers the device to the LEO constellation's cross-satellite IP network access system; In addition, the basic performance of the device is tested to obtain the device's performance parameters, which include: bandwidth requirements, transmission latency, and processing capacity.

3. The LEO constellation cross-satellite IP network access system according to claim 1, characterized in that, The device management module is also used for: The system monitors the operational status of each device registered to the LEO constellation's cross-satellite-to-ground IP network access system, and obtains the status information of each device, including: bandwidth utilization and transmission latency. Based on the status information of each device, determine whether the device is at risk of malfunction or performance degradation; In the event of a device malfunction or performance degradation, the spatiotemporal routing control module is instructed to reconfigure or switch the links involved in that device.

4. The LEO constellation cross-satellite IP network access system according to claim 1, characterized in that, The control terminal further includes a status monitoring module; the status monitoring module is used for: Real-time monitoring of the real-time connection status of each device registered to the LEO constellation's cross-satellite IP network access system, and assessment of network quality based on the real-time connection status of each device; If the network quality does not meet the communication requirements, the spatiotemporal routing control module is instructed to reconfigure or switch the links involved in the device.

5. The LEO constellation cross-satellite IP network access system according to claim 4, characterized in that, The spatiotemporal routing control module is also used for: Dynamically adjust access policies to switch or reconfigure links; The access policy includes at least one of the following: Connect to the satellite with the longest remaining service time until the satellite moves out of the transmission range; Connect to the nearest satellite until the satellite disappears out of range; Always connect to the nearest satellite.

6. The LEO constellation cross-satellite IP network access system according to claim 1, characterized in that, Each client sends a cross-satellite network creation request to the active master node module via the slave node module; The active master node module receives the cross-satellite network configuration sent by the control terminal; when it receives a cross-satellite network creation request from a client, it configures a virtual network card for the client and performs network initialization according to the cross-satellite network configuration. After completing network initialization for all clients to be connected, the active master node module replies to the control terminal with a message indicating that the cross-satellite-to-ground network creation is complete. When the active master node module receives a cross-satellite-to-ground network disassembly request from a client, it deletes the virtual network interface card configured for that client. After deleting the virtual network cards from all connected clients, the active master node module replies to the control terminal with a message indicating that the cross-satellite-to-ground network dismantling is complete.

7. The LEO constellation cross-satellite IP network access system according to claim 6, characterized in that, After configuring a virtual network card for the client and initializing the network according to the cross-satellite-to-ground network configuration, determine the routing type corresponding to the cross-satellite-to-ground network configuration; When the routing type is such that the client and the target client are deployed on the same satellite platform, data packets between the client and the target client are forwarded within the same satellite platform; If the routing type is set to target client, the client's data packets are forwarded to the client's virtual network interface card. When the routing type is such that the client is deployed on a satellite platform and the target client is deployed on a ground station, data packets between the client and the target client are forwarded via a relay.

8. The LEO constellation cross-satellite IP network access system according to claim 5, characterized in that, After the spatiotemporal routing control module completes the link switching or reconfiguration, it sends a route update request to each relay terminal. The relay terminal responds to the route update request by updating the route configuration; after completing the route configuration update, it replies with an update completion message to the spatiotemporal route control module.

9. The LEO constellation cross-satellite IP network access system according to claim 8, characterized in that, After updating the routing configuration at the relay end, determine the routing type corresponding to the routing configuration; When the relay and the target client are deployed on the same satellite platform, data packets between the relay and the target client are forwarded within the same satellite platform. When the routing type is such that the relay is deployed on a satellite platform and the target client is deployed on another satellite platform, data packets between the client and the target client are forwarded via the relay on the other satellite platform.

10. The LEO constellation cross-satellite IP network access system according to any one of claims 1-9, characterized in that, The first relay terminal deployed on the first satellite platform and the second relay terminal deployed on the second satellite platform are connected via an inter-satellite link. When the quality of the direct satellite-to-ground link between the ground station's relay terminal and the second relay terminal does not meet the communication requirements, the spatiotemporal routing control module switches the communication link between the ground station's relay terminal and the second relay terminal to a link with the inter-satellite link as the relay path.

Images