Cross-satellite-ground IP network access system of LEO constellation

Abstract

The invention provides a cross-satellite-ground IP network access system of an LEO constellation, relates to the field of satellite computing, and aims to solve the problem of insufficient dynamic adaptability of a related cross-satellite-ground LEO constellation network access scheme in a complex satellite-ground network environment. The system comprises a control end deployed on a specific ground server for operation; the control end at least comprises a space-time routing control module and an equipment 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 and communication requirements of the ground station and the satellite; the equipment 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 via the relay end through the virtual network card driving module according to the routing configuration provided by the equipment management module.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of satellite computing, and in particular, to an inter-satellite-to-ground IP network access system for a LEO constellation. Background Art

[0002] Low Earth Orbit (LEO) satellites are closer to the ground, and their data transmission delay is smaller than that of other satellites operating in higher orbits. LEO constellations are composed of multiple LEO satellites, usually in cubic satellite or nanosatellite specifications, with the advantages of high coverage and low latency, suitable for real-time remote sensing, disaster monitoring and other tasks. The deployment, operation and data transmission of these tasks require the support of the inter-satellite LEO constellation network.

[0003] The relevant technical solutions for inter-satellite LEO constellation network access are mainly divided into IP network access and Ethernet access, but their specific implementation forms are based on pre-configured fixed paths and endpoints to realize inter-satellite data transmission network tunnels. These solutions are reliable in simple scenarios, but have 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] The embodiment of the present application is to provide a cross-satellite-ground IP network access system for a LEO constellation, aiming to solve the problems of insufficient dynamic adaptability, limited path optimization capability and poor system scalability of related technical solutions for cross-satellite-ground LEO constellation network access in a complex satellite-ground network environment.

[0005] A first aspect of an embodiment of the present application provides a LEO constellation inter-satellite-to-ground IP network access system, including: A plurality of clients deployed on a satellite payload to be connected to an inter-satellite-ground network, and a plurality of clients deployed on a ground server, each of which is deployed with a virtual network card driver module; Multiple relay terminals deployed at ground stations, multiple relay terminals deployed at satellite platforms, one satellite platform carries one or more satellite payloads; a relay terminal deployed at a ground station and a relay terminal deployed at a satellite platform are connected via satellite-to-ground link communication; A control terminal deployed and running on a specific ground server, the specific ground server is different from any ground server where the client is deployed; The control end at least includes: a spatiotemporal routing control module and a device management module; the spatiotemporal routing control module is used to calculate the optimal GSL establishment plan in real time according to 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 terminal according to the spatiotemporal routing data provided by the spatiotemporal routing control module; Each client accesses the inter-satellite-ground network via the relay terminal through the virtual network card driver module according to the routing configuration provided by the device management module.

[0006] In an optional implementation, a slave node module is deployed on each client, and the slave node module sends a registration request to the device management module in the control end via the relay end; The relay terminal sends a registration request to the device management module in the control terminal; The device management module, in response to the received registration request, obtains basic information of the device corresponding to the registration request and generates a unique identifier; performs identity authentication on the device according to the basic information of the device and the corresponding identifier, and registers the device to the inter-satellite-to-ground IP network access system of the LEO constellation if the identity authentication passes; and detects basic performance of the device to obtain performance parameters of the device, wherein the performance parameters include: bandwidth requirements, transmission delay, and processing capacity.

[0007] In an optional implementation, the device management module is further used to: Monitor the operating status of each device in the inter-satellite-to-ground IP network access system registered to the LEO constellation, and obtain status information of each device, wherein the status information includes: bandwidth utilization and transmission delay; Based on the status information of each device, determine whether the device has the risk of failure or performance degradation; When a device is at risk of failure or performance degradation, the spatiotemporal routing control module is instructed to reconfigure or switch the links involved in the device.

[0008] In an optional implementation, the control end further includes: a status monitoring module; the status monitoring module is used to: Monitor the real-time connection status of each device in the inter-satellite IP network access system registered to the LEO constellation in real time, and evaluate the network quality based on the real-time connection status of each device; When 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.

[0009] In an optional implementation, the spatiotemporal routing control module is further used to: Dynamically adjust access policies to switch or reconfigure links; The access strategy includes at least one of the following: The service time connected to the satellite with the longest remaining time until the satellite moves out of transmission range; Connect to the nearest satellite until it disappears out of transmission range; Always connected to the nearest satellite.

[0010] In an optional implementation, a slave node module and a master node module are deployed on each client, and one of all the master node modules is in an activated state; each client sends a cross-satellite-ground network creation request to the master node module in the activated state through the slave node module; The master node module in an activated state receives the inter-satellite-ground network configuration sent by the control terminal; upon receiving an inter-satellite-ground network creation request from a client, configures a virtual network card for the client and performs network initialization according to the inter-satellite-ground network configuration; After completing the network initialization for all clients to be connected, the active master node module replies to the control end with a message that the inter-satellite-ground network creation is completed; When the active master node module receives a cross-satellite-ground network disassembly request from a client, it deletes the virtual network card configured for the client; After completing the deletion of the virtual network cards of all connected clients, the active master node module replies to the control end with a message that the inter-satellite network disassembly is completed.

[0011] In an optional implementation, after configuring a virtual network card for the client and performing network initialization according to the inter-satellite-to-ground network configuration, determining a routing type corresponding to the inter-satellite-to-ground network configuration; In the case where the routing type is that the client and the target client are deployed on the same satellite platform, the 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, forward the data packet of the client to the virtual network card of the client; In the case where the routing type is that the client is deployed on a satellite platform and the target client is deployed on a ground station, the data packets between the client and the target client are forwarded via the relay end.

[0012] In an optional implementation, after the spatiotemporal routing control module completes link switching or reconfiguration, a routing update request is sent to each relay end; The relay end updates the routing configuration in response to the routing update request; after completing the routing configuration update, the relay end replies with an update completion message to the spatiotemporal routing control module.

[0013] In an optional implementation, after the relay terminal updates the routing configuration, the routing type corresponding to the routing configuration is determined; In the case where the routing type is that the relay end and the target client are deployed on the same satellite platform, the data packets between the relay end and the target client are forwarded within the same satellite platform; In the case where the routing type is that the relay end 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 end on the other satellite platform.

[0014] In an optional implementation, a first relay terminal deployed on the first satellite platform and a second relay terminal deployed on the second satellite platform are connected via an inter-satellite link communication; When the quality of the satellite-to-ground link directly connected between the relay end of the ground station and the second relay end does not meet the communication requirements, the space-time routing control module switches the communication link between the relay end of the ground station and the second relay end to a link using the inter-satellite link as a relay path.

[0015] The inter-satellite-ground IP network access system of the LEO constellation provided by the present application is provided with a plurality of clients deployed on a satellite payload to be accessed to the inter-satellite-ground network, and a plurality of clients deployed on a ground server, each of which is provided with a virtual network card driver module; a plurality of relay terminals deployed on a ground station, a plurality of relay terminals deployed on a satellite platform, and a satellite platform carrying one or more satellite payloads; a relay terminal deployed on a ground station and a relay terminal deployed on a satellite platform are connected through a satellite-ground link communication; a control terminal deployed and running on a specific ground server, and the specific ground server is different from any ground server on which the client is deployed; the control terminal at least includes: a spatiotemporal routing control module and a device management module; the spatiotemporal routing control module is used to calculate the optimal GSL establishment plan in real time according to 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 terminal according to the spatiotemporal routing data provided by the spatiotemporal routing control module; each client accesses the inter-satellite-ground network via the relay terminal through the virtual network card driver module according to the routing configuration provided by the device management module.

[0016] The optimal GSL establishment plan is calculated in real time through the space-time routing control module of the control end, and the space-time routing data is provided to the device management module of the control end to dynamically update the routing configuration of each client and each relay end; each client accesses the inter-satellite network through the relay end according to the routing configuration provided by the device management module. Through the collaborative work of the client, relay end and control end, dynamic routing calculation and real-time configuration update are realized, with good path optimization capabilities, and efficient data transmission can be carried out; and the configuration can be automatically adjusted through flexible network arrangement, which improves the scalability of the system, so that it can effectively cope with the dynamic environment and large-scale networking needs of the LEO constellation. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments of the present application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0018] Figure 1 It is a schematic diagram of the implementation principle of the satellite-to-ground IP network tunnel proposed in one embodiment of the present application; Figure 2 It is a schematic diagram of the structure of the inter-satellite-to-ground IP network access system of the LEO constellation proposed in one embodiment of the present application; Figure 3 This is an architecture diagram of an inter-satellite-to-ground IP network access system for a LEO constellation proposed in one embodiment of the present application; Figure 4 This is a core flow chart of a client master node module of a LEO constellation inter-satellite-to-ground IP network access system proposed in an embodiment of the present application; Figure 5 This is a core flow chart of a client slave node module of a LEO constellation inter-satellite-to-ground IP network access system proposed in an embodiment of the present application; Figure 6 This is a core flow chart of a relay terminal of a LEO constellation inter-satellite-to-ground IP network access system proposed in an embodiment of the present application; Figure 7 This is a functional architecture diagram of the inter-satellite-to-ground IP network access system for the LEO constellation proposed in one embodiment of the present application; Figure 8 It is a core flow chart of the control end of the inter-satellite-to-ground IP network access system of the LEO constellation proposed in one embodiment of the present application. DETAILED DESCRIPTION

[0019] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0020] In the drawings, the size of the constituent elements, the thickness of the layer or the area may be exaggerated for the sake of clarity. Therefore, any implementation of the present disclosure is not necessarily limited to the size shown in the drawings, and the shapes and sizes of the components in the drawings do not reflect the true proportions. In addition, the drawings schematically show ideal examples, and any implementation of the present disclosure is not limited to the shapes or values ​​shown in the drawings.

[0021] Low Earth Orbit (LEO) satellites refer to satellites with orbital altitudes below 2,000 kilometers. Due to the close distance between LEO satellites and the ground, their data transmission delay is smaller than that of other satellites operating in higher orbits (such as the minimum earth orbit and geosynchronous equatorial orbit), and the signal leaving the satellite can reach the visible ground station in about 0.05 seconds. LEO constellation refers to a constellation composed of multiple LEO satellites, and most of its single satellites use the specifications of cubic satellites and nanosatellites. LEO constellations have advantages such as high coverage and low latency, and are suitable for deployment tasks such as on-orbit data preprocessing, real-time remote sensing image analysis, and disaster monitoring. The deployment, operation, and data transmission of these tasks require the support of the inter-satellite LEO constellation network.

[0022] The existing technical solutions for inter-satellite LEO constellation network access can be roughly divided into IP network access and Ethernet access according to the OSI network layer of access, but their specific implementation forms are based on pre-configured fixed paths and endpoints to realize inter-satellite data transmission network tunnels. Take the inter-satellite IP network tunnel as an example. Figure 1 As shown, the specific implementation principle can be described as follows: During the network initialization phase, the network administrator manually configures the path of each tunnel based on the orbital parameters of the LEO satellite and the geographical location of the ground station. These paths define: the starting point (LEO satellite payload / ground server) and end point (LEO satellite payload / ground server) of the tunnel; the fixed IP address range of the tunnel, which is used to identify the data flow on the tunnel; the link timing required for data transmission, including the satellite's visible window and tunnel switching rules.

[0023] IP static tunnels achieve data transmission through encapsulation technology. After the data packet is generated from the application layer, it is encapsulated into the IP tunnel through the tunnel management module of the ground station, and the tunnel header information (LEO satellite payload / ground server IP) is attached. The data packet is transmitted to the target node on a fixed path. No matter how the link status changes, the path remains unchanged. At the target node, the tunnel header information is removed and the data packet is restored to its original format for subsequent processing.

[0024] When the ground station establishes a communication link with the target satellite, the tunnel is automatically started according to the path configuration. When the satellite is out of the coverage of the ground station, the tunnel is immediately disconnected and data transmission is interrupted. At this time, the ground station needs to wait to establish a new tunnel with the next covering satellite.

[0025] The existing technical solutions for inter-satellite LEO constellation network access have a certain degree of reliability in simple satellite-to-ground communication scenarios, but their technical defects are also obvious. Insufficient dynamic adaptability: LEO satellites move at high speeds, with short coverage windows. Static paths are interrupted after the satellites exceed the coverage range, and the paths cannot be dynamically adjusted to adapt to changes in link status. Transmission performance is difficult to optimize: The fixed path design cannot adapt to changes in link quality, cannot optimize the path using inter-satellite links (ISLs), and lacks load balancing capabilities. Limited scalability: As the number of satellites and ground stations increases, the complexity of path configuration increases exponentially. When adding new nodes or links, the path needs to be reconfigured, and the expansion process is slow and costly.

[0026] In view of the above problems, the embodiment of the present application proposes a LEO constellation inter-satellite-to-ground IP network access system, which aims to overcome the limitations of the traditional inter-satellite-to-ground network tunnel solution in a complex satellite-to-ground network environment, and solve the problems of insufficient dynamic adaptability, limited path optimization capability, and poor system scalability. In conjunction with the accompanying drawings, the inter-satellite-to-ground IP network access system for the LEO constellation provided by the embodiment of the present application is described in detail through some embodiments and their application scenarios.

[0027] Reference Figure 2 , Figure 2 Schematic diagram of the structure of the inter-satellite-to-ground IP network access system for the LEO constellation proposed in the first embodiment of the present application. Figure 2 As shown, the system includes: A plurality of clients deployed on a satellite payload to be connected to an inter-satellite-ground network, and a plurality of clients deployed on a ground server, each of which is deployed with a virtual network card driver module; Multiple relay terminals deployed at ground stations, multiple relay terminals deployed at satellite platforms, one satellite platform carries one or more satellite payloads; a relay terminal deployed at a ground station and a relay terminal deployed at a satellite platform are connected via satellite-to-ground link communication; A control terminal deployed and running on a specific ground server, the specific ground server is different from any ground server where the client is deployed; The control end at least includes: a spatiotemporal routing control module and a device management module; the spatiotemporal routing control module is used to calculate the optimal GSL establishment plan in real time according to 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 terminal according to the spatiotemporal routing data provided by the spatiotemporal routing control module; Each client accesses the inter-satellite-ground network via the relay terminal through the virtual network card driver module according to the routing configuration provided by the device management module.

[0028] In this embodiment, the client is the access point of the inter-satellite network, which is deployed on the ground server and the satellite payload, and is responsible for accessing the inter-satellite network through the relay end through the virtual network card driver module according to the routing configuration provided by the control end. The relay end is deployed in the satellite platform and the ground station, and is the relay and gateway between the satellite network and the ground network. The virtual network card driver module deployed on each client is used to realize the virtualization of the network interface and support dynamic routing configuration and data transmission. In the process of each client accessing the inter-satellite network, the spatiotemporal routing control module of the control end calculates the optimal GSL (Ground-to-Satellite Link) establishment plan according to the relative position and communication requirements of the ground station and the satellite, thereby establishing a communication link between the relay end of the ground station and the relay end of the satellite platform. The device management module of the control end updates the routing configuration of the client and the relay end according to the spatiotemporal routing data corresponding to the calculated optimal GSL. The client accesses the inter-satellite network through the virtual network card driver module according to the updated routing configuration, and then accesses the inter-satellite network through the relay end, thereby transmitting data. As the relative positions of the ground station and the satellite change, the control end can adjust the GSL establishment plan and routing configuration in real time to ensure the continuity and stability of network communications.

[0029] The optimal GSL establishment plan is calculated in real time through the space-time routing control module of the control end, and the space-time routing data is provided to the device management module of the control end to dynamically update the routing configuration of each client and each relay end; each client accesses the inter-satellite network through the relay end according to the routing configuration provided by the device management module. Through the collaborative work of the client, relay end and control end, dynamic routing calculation and real-time configuration update are realized, with good path optimization capabilities, and efficient data transmission can be carried out; and the configuration can be automatically adjusted through flexible network arrangement, which improves the scalability of the system, so that it can effectively cope with the dynamic environment and large-scale networking needs of the LEO constellation.

[0030] In an optional implementation, a slave node module is deployed on each client, and the slave node module sends a registration request to the device management module in the control end via the relay end; The relay terminal sends a registration request to the device management module in the control terminal; The device management module, in response to the received registration request, obtains basic information of the device corresponding to the registration request and generates a unique identifier; performs identity authentication on the device according to the basic information of the device and the corresponding identifier, and registers the device to the inter-satellite-to-ground IP network access system of the LEO constellation if the identity authentication passes; and detects basic performance of the device to obtain performance parameters of the device, wherein the performance parameters include: bandwidth requirements, transmission delay, and processing capacity.

[0031] like Figure 3 As shown, a slave node module is deployed on each client. The slave node module is the main communication module of the client, responsible for establishing inter-satellite network connections with slave node modules and master node modules of other clients, and performing data transmission and routing selection through inter-satellite IP addresses. In the inter-satellite IP network access of a LEO constellation, the slave node modules and virtual network card driver modules of the clients of all accessed devices are in an activated running state.

[0032] Each client can send a registration request to the device management module in the control end through its corresponding slave node module via the relay end. The registration request is the first step for the device to access the inter-satellite IP network. It contains basic information about the device (such as device type, IP address, MAC address, hardware configuration, etc.) to ensure that the device can be identified and managed by the system. In response to the received registration request, the device management module extracts the basic information of the device from the registration request and registers the device to the inter-satellite IP network access system of the LEO constellation. When each device is registered, the device management module will generate a unique identifier and ensure the legitimacy of the device through identity authentication. The registration process also includes basic testing of device performance, such as bandwidth requirements, transmission delay, processing power, etc., to ensure that the system can reasonably allocate resources according to the characteristics of the device.

[0033] In an optional implementation, the device management module is further used to: Monitor the operating status of each device in the inter-satellite-to-ground IP network access system registered to the LEO constellation, and obtain status information of each device, wherein the status information includes: bandwidth utilization and transmission delay; Based on the status information of each device, determine whether the device has the risk of failure or performance degradation; When a device is at risk of failure or performance degradation, the spatiotemporal routing control module is instructed to reconfigure or switch the links involved in the device.

[0034] In this embodiment, the device management module monitors the operating status of each device in the inter-satellite IP network access system registered to the LEO constellation in real time. The status information of each device can be obtained by regularly sending an operating status query request (such as SNMP protocol, custom heartbeat packet, etc.) to each device, and the status information includes bandwidth utilization, transmission delay, etc. The device management module determines whether the device is at risk of failure or performance degradation based on the status information of each device through threshold analysis and trend analysis. In the case of a risk of failure or performance degradation of the device, the device management module will immediately start the fault handling mechanism and instruct the space-time routing control module to reconfigure or switch the links involved in the device to ensure the continuity and stability of the network and avoid communication interruptions caused by device failure or performance degradation.

[0035] In an optional implementation, the control end further includes: a status monitoring module; the status monitoring module is used to: Monitor the real-time connection status of each device in the inter-satellite IP network access system registered to the LEO constellation in real time, and evaluate the network quality based on the real-time connection status of each device; When 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.

[0036] In this embodiment, the status monitoring module of the control end monitors the real-time connection status (such as online status, response time, packet loss rate, etc.) of each device in the inter-satellite-to-ground IP network access system registered to the LEO constellation in real time, that is, periodically collects the connection status of each client and relay device. According to the real-time connection status of the device, the network quality indicators (such as delay, jitter, packet loss rate, bandwidth utilization, etc.) are calculated, and the calculated network quality indicators are compared with the preset communication demand threshold to comprehensively evaluate the network quality. When the network quality does not meet the communication requirements, the status monitoring module instructs the space-time routing control module to reconfigure or switch the links involved in the device. The status monitoring module not only monitors the device in real time, but also evaluates the network quality of the GSL to ensure that the inter-satellite-to-ground network can always meet the communication requirements.

[0037] In an optional implementation, the spatiotemporal routing control module is further used to: Dynamically adjust access policies to switch or reconfigure links; The access strategy includes at least one of the following: The service time connected to the satellite with the longest remaining time until the satellite moves out of transmission range; Connect to the nearest satellite until it disappears out of transmission range; Always connected to the nearest satellite.

[0038] In this embodiment, the spatiotemporal routing control module can respond to the instructions of the device management module or the status monitoring module, select a suitable connection path and dynamically adjust it according to the relative position and communication requirements of the ground station and the satellite, that is, dynamically adjust the access strategy to switch or reconfigure the link. Due to the periodic changes in the orbit of the LEO satellite, the establishment and switching of the GSL need to be optimized based on real-time spatiotemporal data. The spatiotemporal routing control module selects the optimal satellite for access based on the orbital data of the satellite and the position change of the ground station. In order to cope with different mission requirements, the spatiotemporal routing control module provides several different satellite platform-ground station link binding strategies (access strategies), which can usually be divided into three categories according to their access satellite selection criteria: connecting to the satellite with the longest remaining time until it moves out of the transmission range of service time; connecting to the nearest satellite until it disappears outside the transmission range; always connecting to the nearest satellite, that is, if there is one, immediately switch to a closer satellite.

[0039] Due to the low-orbit characteristics of LEO satellites, the connection between satellites and ground stations is intermittent. The space-time 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 disconnection due to satellite failure or interruption. In the face of the new features of the LEO constellation compared to the GEO constellation: the exponential growth in the number of satellites and the relative scarcity of ground stations, the role of the space-time routing control module becomes particularly important. The space-time routing control module can adjust the access link in real time to ensure that the ground station can access the appropriate satellite, maximizing network quality and bandwidth utilization.

[0040] In an optional implementation, the control end further includes: an inter-satellite-ground network management module; the inter-satellite-ground network management module distributes configuration instructions to corresponding clients and relay ends according to the access strategy dynamically adjusted by the space-time routing control module to achieve link switching or reconfiguration.

[0041] In this embodiment, the inter-satellite-ground network management module can receive the access policy of the space-time routing control module, and distribute configuration instructions to the client and relay devices according to different needs, execute link switching or reconfiguration, so as to realize dynamic scheduling of network resources. The inter-satellite-ground network management module ensures that the network can be adjusted according to the real-time GSL status and needs through collaboration with other modules, ensuring the efficiency and stability of the inter-satellite-ground IP network, and being able to dynamically adapt to the complex satellite-ground communication environment.

[0042] In an optional implementation, a slave node module and a master node module are deployed on each client, and one of all the master node modules is in an activated state; each client sends a cross-satellite-ground network creation request to the master node module in the activated state through the slave node module; The master node module in an activated state receives the inter-satellite-ground network configuration sent by the control terminal; upon receiving an inter-satellite-ground network creation request from a client, configures a virtual network card for the client and performs network initialization according to the inter-satellite-ground network configuration; After completing the network initialization for all clients to be connected, the active master node module replies to the control end with a message that the inter-satellite-ground network creation is completed; When the active master node module receives a cross-satellite-ground network disassembly request from a client, it deletes the virtual network card configured for the client; After completing the deletion of the virtual network cards of all connected clients, the active master node module replies to the control end with a message that the inter-satellite network disassembly is completed.

[0043] like Figure 3 As shown in the figure, a slave node module and a master node module are deployed on each client. The main function of the client is to realize cross-satellite network access and data transmission in the orbit edge computing environment. In a network access system, the slave node modules and virtual network card driver modules of the clients of all accessed devices are in an activated running state, but only the master node module of the client of one device is in an activated running state. The slave node module is responsible for establishing a cross-satellite network connection with the slave node modules and master node modules of other clients, and performing data transmission and routing selection through cross-satellite IP addresses. The master node module is responsible for the centralized management of the cross-satellite network, responsible for the access and IP allocation of slave node module nodes, and maintains the routing within the network access system. The virtual network card driver module provides a virtual Ethernet interface for the system, enabling the client to receive and send data in the form of network frames. Through the virtual network card driver module, client data can be encapsulated as cross-satellite network traffic and isolated from the actual physical network.

[0044] In one embodiment, if Figure 4 As shown, Figure 4It is a core flow chart of the client master node module shown in an embodiment of the present application. Each client sends a cross-satellite network creation request to the master node module in an activated state through the slave node module. The master node module in an activated state can receive the cross-satellite network configuration sent by the control end. When receiving the cross-satellite network creation request from a client, it can configure the virtual network card for the client and perform network initialization according to the cross-satellite network configuration. After completing the network initialization for all clients to be connected, the master node module in an activated state replies to the control end with a cross-satellite network creation completion message and starts the cross-satellite network heartbeat. When the master node module in an activated state receives a cross-satellite network disassembly request from a client, it deletes the virtual network card configured for the client; after the master node module in an activated state completes the deletion of the virtual network card for all connected clients, it replies to the control end with a cross-satellite network disassembly 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 end and client control messages from other client slave nodes (slave node inquiry request, slave node exit notification). For the slave node query request, determine whether the corresponding slave node module is querying for the first time. If it is the first time, update the inter-satellite network creation progress. If it is not the first time, query the slave node query target route and reply to the corresponding client. For the slave node exit notification, update the inter-satellite network disassembly progress and reply to the corresponding client.

[0045] In an optional implementation, after configuring a virtual network card for the client and performing network initialization according to the inter-satellite-to-ground network configuration, determining a routing type corresponding to the inter-satellite-to-ground network configuration; In the case where the routing type is that the client and the target client are deployed on the same satellite platform, the 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, forward the data packet of the client to the virtual network card of the client; In the case where the routing type is that the client is deployed on a satellite platform and the target client is deployed on a ground station, the data packets between the client and the target client are forwarded via the relay end.

[0046] like Figure 5 As shown, Figure 5It is a core flow chart of the client slave node module shown in an embodiment of the present application. After the client completes the configuration of the virtual network card and the network initialization, the routing type corresponding to the cross-satellite network configuration is determined. When the routing type is that the client and the target client are deployed on the same satellite platform (target device), the 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 (the target device is this device), the data packet of the client is forwarded to the virtual network card of the client. When the routing type is that the client is deployed on a satellite platform and the target client is deployed on a ground station, the data packet between the client and the target client is forwarded via the relay end. The slave node module may also receive a message with the slave node as the destination ID, including a client control message from the control end, such as a registration request, which comes from the original registration request sent by the client and returned after the control end responds. After receiving the request, the slave node module initializes the routing configuration, performs a relay end connectivity test, replies to the control end registration completion message, and starts the device heartbeat. Each client sends a cross-satellite network creation request to the active master node module through the slave node module. In response to the inter-satellite network creation request, the slave node module inquires the master node module, creates the network card device, binds the virtual network card, replies to the control end after completing the inter-satellite network creation, and starts the inter-satellite network heartbeat. In response to the inter-satellite network disassembly request, the slave node module deletes the virtual network card binding and replies to the control end with an exit message.

[0047] In an optional implementation, after the spatiotemporal routing control module completes link switching or reconfiguration, a routing update request is sent to each relay end; The relay end updates the routing configuration in response to the routing update request; after completing the routing configuration update, the relay end replies with an update completion message to the spatiotemporal routing control module.

[0048] In this embodiment, the relay end serves as a transfer module between the on-board client and the ground client in the network access system and a controller of the satellite-ground station GSL, and is used to support data forwarding across the satellite and the ground, and between satellites, as well as the relay of control requests of the on-board client. The device on which the relay end is deployed is not used as a device for accessing the network access system and is transparent to other clients. The relay end uses the network topology of the specific inter-satellite-ground network derived from the control end to complete data forwarding within the same network access system, and completes the outer data encapsulation of the GSL communication of the satellite platform-ground station system data entry and exit. Based on the results of the control end's spatiotemporal routing control, the relay end controls the satellite platform and the ground station to complete the establishment and switching of the GSL at a specific time.

[0049] like Figure 6 As shown, Figure 6It is a core flow chart of the relay end shown in an embodiment of the present application. After the space-time routing control module completes the link switching or reconfiguration, the receiving space-time routing control module sends a routing update request to each relay end. The relay end responds to the routing update request and updates the routing configuration; after completing the update of the routing configuration, it replies to the space-time routing control module with an update completion message. The relay end may also receive a client control message from the control end, such as a registration request, which is a request returned from the original registration request sent by the relay end after the control end responds. After receiving the request, the relay end initializes the routing configuration, performs a relay end connectivity test, replies to the control end with a registration completion message, and starts the device heartbeat.

[0050] In an optional implementation, after the relay terminal updates the routing configuration, the routing type corresponding to the routing configuration is determined; In the case where the routing type is that the relay end and the target client are deployed on the same satellite platform, the data packets between the relay end and the target client are forwarded within the same satellite platform; In the case where the routing type is that the relay end 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 end on the other satellite platform.

[0051] like Figure 6 As shown, after the relay end updates the routing configuration, the routing type corresponding to the routing configuration is determined; when the routing type is that the relay end 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 end and the target client are forwarded in the local area network within the same satellite platform; when the routing type is that the relay end 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 end on another satellite platform, that is, forwarded to other relay ends.

[0052] In an optional implementation, a first relay terminal deployed on the first satellite platform and a second relay terminal deployed on the second satellite platform are connected via an inter-satellite link communication; When the quality of the satellite-to-ground link directly connected between the relay end of the ground station and the second relay end does not meet the communication requirements, the space-time routing control module switches the communication link between the relay end of the ground station and the second relay end to a link using the inter-satellite link as a relay path.

[0053] 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 by inter-satellite link communication. The space-time routing control module can monitor the device connection status in real time through the status monitoring module, and judge whether the quality of the satellite-to-ground link directly connected between the relay terminal of the ground station and the second relay terminal meets the communication requirements according to the current network topology, the relative position of the ground station and the satellite, the communication requirements and other factors. If the communication requirements are not met, the communication link between the relay terminal of the ground station and the second relay terminal is switched to a link with the inter-satellite link as the relay path. When the quality of the satellite-to-ground link between the ground station and the satellite does not meet the communication requirements, it can automatically switch to a link with the inter-satellite link as the relay path, thereby ensuring the continuity and reliability of communication.

[0054] Reference Figure 7 , Figure 7 1 is a functional architecture diagram of the inter-satellite-to-ground IP network access system for the LEO constellation proposed in one embodiment of the present application. Figure 7 As shown in the figure, the functions of the LEO constellation's inter-satellite IP network access system are: The inter-satellite-ground IP network access system of the LEO constellation 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 inter-satellite-ground network, multiple relays deployed on ground station systems and satellite platforms, and a control terminal that runs on a specific ground server as the control center of the network access system.

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

[0056] The relay terminal is deployed in the satellite platform and ground station system, acting as a relay and gateway between the satellite network and the ground network.

[0057] The control end is responsible for processing inter-satellite network control requests and overall management of the inter-satellite network. Its main functions include inter-satellite network construction control, space-time routing control, inter-satellite network status management, and client and relay status management. Through interaction with the client and relay, dynamic configuration and efficient management of the inter-satellite network can be achieved. Figure 8 .

[0058] The LEO constellation inter-satellite-ground IP network access system of the present application improves the dynamic adaptability and availability of the inter-satellite-ground network in the LEO constellation and the scalability in large-scale LEO constellation networking by integrating network access, inter-satellite-ground network management and access device management. Specifically: The spatial and temporal dimensions of routing calculation control across satellite-ground networks are combined to transform network access control from a static strategy at a certain moment to a dynamic strategy across time periods. Through satellite orbit prediction and real-time monitoring of link status, the system realizes intelligent switching and adjustment of paths, avoiding path redundancy and communication interruption problems. The system can complete routing switching before the satellite enters the coverage area of ​​a ground station to ensure the continuity of data flow.

[0059] Incorporate ground station access control into satellite-ground link optimization, and improve link availability through satellite-ground collaborative management. Combined with a variety of satellite-ground connection strategies (such as LRST, NSD, and NSH), the system can dynamically select the best link, maximize link utilization, and ensure transmission stability. For example, when multiple satellites cover a ground station at the same time, the system gives priority to satellites with lighter loads or longer service time, effectively solving the problem of insufficient link resource utilization in traditional solutions.

[0060] Incorporating relay nodes (such as LEO satellite platforms, ground stations) and network endpoints (such as satellite payloads, ground servers) into 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 the stability and scalability of the network.

[0061] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0062] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, devices, electronic devices, and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0063] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0064] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0065] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0066] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "including one..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0067] The above is a detailed introduction to the inter-satellite-to-ground IP network access system for a LEO constellation provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the ideas of the present application, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A LEO constellation inter-satellite IP network access system, characterized in that: include: A plurality of clients deployed on a satellite payload to be connected to an inter-satellite-ground network, and a plurality of clients deployed on a ground server, each of which is deployed with a virtual network card driver module; Multiple relay terminals deployed at ground stations, multiple relay terminals deployed at satellite platforms, and one satellite platform carries one or more satellite payloads; A relay terminal deployed at a ground station is connected to a relay terminal deployed at a satellite platform via a satellite-to-ground link communication; A control terminal deployed and running on a specific ground server, wherein the specific ground server is different from any ground server where the client is deployed; The control end at least includes: a spatiotemporal routing control module and a device management module; The spatiotemporal routing control module is used to calculate the optimal GSL establishment plan in real time according to the relative positions 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 terminal according to the spatiotemporal routing data provided by the spatiotemporal routing control module; Each client accesses the inter-satellite-ground network via the relay terminal through the virtual network card driver module according to the routing configuration provided by the device management module.

2. The LEO constellation inter-satellite IP network access system according to claim 1, characterized in that: A slave node module is deployed on each client, and the slave node module sends a registration request to the device management module in the control end via the relay end; The relay terminal sends a registration request to the device management module in the control terminal; The device management module, in response to the received registration request, obtains basic information of the device corresponding to the registration request and generates a unique identifier; performs identity authentication on the device according to the basic information of the device and the corresponding identifier, and registers the device to the inter-satellite-to-ground IP network access system of the LEO constellation if the identity authentication passes; And, detecting the basic performance of the device to obtain the performance parameters of the device, wherein the performance parameters include: bandwidth requirement, transmission delay, and processing capability.

3. The LEO constellation inter-satellite IP network access system according to claim 1, characterized in that: The device management module is also used for: Monitor the operating status of each device in the inter-satellite-to-ground IP network access system registered to the LEO constellation, and obtain status information of each device, wherein the status information includes: bandwidth utilization and transmission delay; Based on the status information of each device, determine whether the device has the risk of failure or performance degradation; When a device is at risk of failure or performance degradation, the spatiotemporal routing control module is instructed to reconfigure or switch the links involved in the device.

4. The inter-satellite-to-ground IP network access system of the LEO constellation according to claim 1, characterized in that: The control end further includes: a status monitoring module; the status monitoring module is used to: Monitor the real-time connection status of each device in the inter-satellite IP network access system registered to the LEO constellation in real time, and evaluate the network quality based on the real-time connection status of each device; When 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 inter-satellite-to-ground IP network access system of the LEO constellation according to claim 3 or 4, characterized in that: The spatiotemporal routing control module is also used for: Dynamically adjust access policies to switch or reconfigure links; The access strategy includes at least one of the following: The service time connected to the satellite with the longest remaining time until the satellite moves out of transmission range; Connect to the nearest satellite until it disappears out of transmission range; Always connected to the nearest satellite.

6. The LEO constellation inter-satellite-to-ground IP network access system according to claim 1, characterized in that: A slave node module and a master node module are deployed on each client, and one of the master node modules is in an activated state; each client sends a cross-satellite-ground network creation request to the activated master node module through the slave node module; The master node module in an activated state receives the inter-satellite-ground network configuration sent by the control terminal; upon receiving an inter-satellite-ground network creation request from a client, configures a virtual network card for the client and performs network initialization according to the inter-satellite-ground network configuration; After completing the network initialization for all clients to be connected, the active master node module replies to the control end with a message that the inter-satellite-ground network creation is completed; When the active master node module receives a request for disassembling the inter-satellite-ground network from a client, it deletes the virtual network card configured for the client; After completing the deletion of the virtual network cards of all connected clients, the active master node module replies to the control end with a message that the inter-satellite network disassembly is completed.

7. The LEO constellation inter-satellite-to-ground 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 inter-satellite-to-ground network configuration, determining a routing type corresponding to the inter-satellite-to-ground network configuration; In the case where the routing type is that the client and the target client are deployed on the same satellite platform, the 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, forward the data packet of the client to the virtual network card of the client; In the case where the routing type is that the client is deployed on a satellite platform and the target client is deployed on a ground station, the data packets between the client and the target client are forwarded via the relay end.

8. The inter-satellite-to-ground IP network access system of the LEO constellation according to claim 5, characterized in that: After the spatiotemporal routing control module completes link switching or reconfiguration, sending a routing update request to each relay end; The relay end updates the routing configuration in response to the routing update request; after completing the routing configuration update, the relay end replies with an update completion message to the spatiotemporal routing control module.

9. The LEO constellation inter-satellite-to-ground IP network access system according to claim 8, characterized in that: After the relay terminal updates the routing configuration, determining the routing type corresponding to the routing configuration; In the case where the routing type is that the relay end and the target client are deployed on the same satellite platform, the data packets between the relay end and the target client are forwarded within the same satellite platform; In the case where the routing type is that the relay end 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 end on the other satellite platform.

10. The inter-satellite-to-ground IP network access system for LEO constellation according to any one of claims 1 to 9, characterized in that: A first relay terminal deployed on a first satellite platform and a second relay terminal deployed on a second satellite platform are connected in communication via an intersatellite link; When the quality of the satellite-to-ground link directly connected between the relay end of the ground station and the second relay end does not meet the communication requirements, the space-time routing control module switches the communication link between the relay end of the ground station and the second relay end to a link using the inter-satellite link as a relay path.

Images