An inter-satellite self-organizing communication network protocol design method, system and device

Abstract

The application relates to a kind of inter-satellite self-organizing communication network protocol design method, system and equipment, belongs to inter-satellite networking communication technical field.The method comprises the following steps: according to the dynamic change of the network environment and autonomous task scene where satellite cluster is located, the network protocol of each member node in the satellite cluster is defined to be switched between debug mode and active mode, which can ensure that the satellite cluster system can realize neighbor discovery, network topology formation, role configuration, fault handling and multi-hop real-time communication function independently without relying on ground intervention, ensure the satellite cluster in-orbit whole-process autonomous networking operation, and significantly improve the in-orbit survivability and networking communication reliability of the satellite cluster.

Description

Technical Field

[0001] This application relates to the field of inter-satellite networking communication technology, and in particular to a design method, system and device for an inter-satellite self-organizing communication network protocol. Background Technology

[0002] Satellite constellations, a typical form of distributed satellite systems, originated from the problem of co-positioning in geostationary satellite orbits. Unlike common satellite constellation concepts, satellite constellations do not require precise maintenance of the relative positions and attitudes of the satellites within a constellation. As long as the visibility of wireless communication links between member satellites can be guaranteed while collisions are avoided, inter-satellite relative distance drift caused by higher-order orbital perturbations is acceptable. Due to its advantages in robustness, flexibility, and control overhead, satellite constellation architectures are widely used in low-Earth orbit multi-point imaging, on-orbit servicing, and radio frequency signal positioning.

[0003] A flexible, efficient, and robust inter-satellite self-organizing communication network is a crucial prerequisite for the overall effectiveness of a satellite constellation system, especially when the data transmission link between satellite and ground is invisible. Self-organization refers to the ability of each network node in the satellite constellation communication network to autonomously perform routine network operations such as neighbor discovery, network topology formation, network role configuration, and network fault handling without ground personnel intervention. Furthermore, the inter-satellite self-organizing communication network should also support real-time (delay-bounded) data communication in multi-hop communication scenarios to support the scalability and distributed collaborative control loop requirements of the satellite constellation system.

[0004] However, most existing research on inter-satellite communication network protocols in the field of distributed satellites is based on predefined network topologies and fixed network member assumptions, often neglecting the issues of autonomy in network formation and autonomous handling and response in the event of network node failures. Secondly, the issue of ensuring real-time communication, which is crucial for on-orbit mission coordination in satellite constellation systems, especially real-time (delay-bounded) communication in multi-hop network environments, has generally not received sufficient attention. Summary of the Invention

[0005] Based on this, it is necessary to provide a design method, system, and device for an inter-satellite self-organizing communication network protocol that can realize autonomous discovery of neighbor nodes, autonomous formation of network topology, autonomous configuration of network roles, self-healing of node faults, and multi-hop real-time communication functions in low-Earth orbit satellite cluster communication networks, addressing the aforementioned technical problems.

[0006] A method for designing an inter-satellite self-organizing communication network protocol, the method comprising: Based on the dynamic changes in the network environment and autonomous mission scenario of the satellite cluster, the network protocols of each member node in the satellite cluster are defined to autonomously switch between debug mode and active mode. In the case of satellite cluster separate deployment, mission reconfiguration and node failure, the network protocol of each member node is defined to run in debug mode, and neighbor discovery, tree network topology formation and role configuration between member nodes are performed in debug mode; the tree network topology is configured from top to bottom according to network depth as coordinator node, forward and backward router nodes and terminal nodes. After the tree-like network topology is formed and the network protocol has been running in debug mode for the preset debugging time, the network protocol of each member node is defined to run in active mode. In active mode, the network synchronization, network topology maintenance and node fault self-healing of the satellite cluster are performed through Beacon frames and GTS command frames periodically sent between member nodes. At the same time, a sequential Beacon scheduling strategy based on network depth is executed to avoid frame conflicts, and a GTS time slot allocation scheme based on tree-like network topology is executed to ensure real-time communication between nodes.

[0007] In one embodiment, neighbor discovery, tree network topology formation, and role configuration among member nodes are performed in debug mode, including: Step 1: Each member node running the network protocol in debug mode first accesses the common channel cyclically and sends Beacon frames in a time-division multiple access manner with the assistance of the GNSS second pulse signal. The Beacon frame contains the current node ID, the number of nodes, and the list of satellite cluster orbit elements maintained locally by the current node. Step 2: After each member node collects the orbital element information of all member nodes within the satellite cluster through direct or indirect means, the orbital elements of all member nodes are uniformly extrapolated and aligned to the starting point of the current time slot. Based on the time-aligned orbital elements of each node, the relative longitude between each member node is calculated using the Brouwer transform and the definition of relative orbital elements. Step 3: Based on the relative longitudes between each member node, construct the adjacency matrix of the satellite cluster, and select the member node with the most direct communication links as the coordinator node according to the adjacency matrix; where multiple member nodes have the same number of direct communication links, select the member node that is closest to the center of the satellite cluster in the direction of satellite velocity as the coordinator node. Step 4: Using the coordinator node as the root node, perform forward role configuration in the +V bar direction and backward role configuration in the -V bar direction to obtain the coordinator node's forward and backward router nodes and end nodes. Then, using the newly configured forward and backward router nodes as the root node, iteratively perform forward and backward role configuration until all member nodes have completed role configuration, thus constructing the tree-like network topology of the satellite cluster. Here, the +V bar direction is the satellite velocity direction, and the -V bar direction is the negative direction of the satellite velocity direction. The forward role configuration process includes: Step 4.1.1, determining whether there are neighboring nodes within the Dmin range in the +V bar direction of the root node. If no neighboring nodes exist, proceed to Step 4.1.2; if there is one neighboring node, configure that neighboring node as an endpoint node and then proceed to Step 4.1.2; if there are two or more neighboring nodes, configure the neighboring node with the smallest relative distance to the root node in the trace direction as an endpoint node, configure the neighboring node with the second smallest relative distance in the trace direction as a forward router node, and end this round of iteration; Step 4.1.2, within the range Dmin to Dmax in the +V bar direction of the root node, configure the node with the smallest relative distance to the root node in the trace direction as a forward router node, and end this round of iteration; where Dmin is the subgroup communication range and Dmax is the satellite cluster communication range; The backward role configuration process includes: Step 4.2.1, determining whether there is a neighbor node within the Dmin range in the root node's -V bar direction. If no neighbor node exists, proceed to Step 4.2.2; if there is one neighbor node and the number of terminal nodes belonging to the current root node is 0, then after configuring the neighbor node as a terminal node, proceed to Step 4.2.2; otherwise, directly configure the neighbor node as a backward router node and end this round of iteration; if there are two or more neighbor nodes and the number of terminal nodes belonging to the current root node is 0, then configure the neighbor node with the smallest relative distance from the root node's trace direction as a terminal node, configure the neighbor node with the second smallest relative distance from the trace direction as a backward router node, and end this round of iteration; otherwise, directly configure the neighbor node with the smallest relative distance from the root node's trace direction as a backward router node and end this round of iteration; Step 4.2.2, within the range Dmin to Dmax in the root node's -V bar direction, configure the node with the smallest relative distance from the root node's trace direction as a backward router node and end this round of iteration.

[0008] In one embodiment, the method further includes: Each member node of the network protocol, running in debug mode, executes the neighbor discovery, tree-structured network topology formation, and role configuration processes cyclically once in each time slot to robustly cope with network topology changes caused by the relative motion of the satellite constellation.

[0009] In one embodiment, a preset debugging duration is provided. The size of the satellite constellation can be flexibly set according to its member size, and the setting rules are expressed as follows: ; in, The length of the TDMA cycle. This represents the number of member nodes in the satellite constellation.

[0010] In one embodiment, in active mode, network synchronization, network topology maintenance, and node fault self-healing of the satellite cluster are performed through Beacon frames and GTS command frames periodically sent between member nodes, including: Each member node operating in active mode of the network protocol periodically sends Beacon frames to its child nodes for network synchronization, based on its role in the tree-like network topology of the satellite constellation and the underlying standard of the network protocol. At the same time, it periodically sends GTS command frames to its parent node for network topology maintenance and node fault self-healing. The underlying standard of the network protocol is IEEE 802.15.4 / ZigBee. The GTS command frame is defined as a state_report command frame sent in the GTS time slot, and the Beacon frame and the state_report command frame are configured with the same payload field.

[0011] In one embodiment, node fault self-healing includes: Within each superframe period, the child node determines whether its parent node is working properly by listening to the Beacon frames sent by the parent node, and the parent node determines whether its child node is working properly by receiving the state_report command frames sent by the child node in its GTS time slot. If the parent node finds that a child node has not sent a state_report command frame for three consecutive superframe cycles, it determines that the child node is faulty, and the child node’s network protocol will automatically switch to debug mode. If a child node detects that its parent node has not sent Beacon frames for three consecutive superframe cycles, it determines that the parent node is faulty, and the parent node's network protocol will automatically switch to debug mode.

[0012] In one embodiment, the network depth-based sequential Beacon scheduling strategy includes: The BI and SD of each member node in the satellite cluster are defined to use the same configuration; where BI is the beacon interval, which represents the time period for sending Beacon frames; and SD is the superframe period, which represents the total time length occupied by a single superframe. In a tree-like network topology of a satellite constellation, each level of forward and backward router nodes sends their own Beacon frames sequentially after the coordinator node sends a Beacon frame, according to the network depth. The values ​​of BI and SD, the start time of Beacon frame transmission by forward and backward router nodes, and the maximum network depth are defined. The following requirements must be met: ; in, The start time for the forward router node to send Beacon frames. This is the start time for sending Beacon frames to subsequent router nodes. For network depth.

[0013] In one embodiment, the GTS time slot allocation scheme based on a tree network topology includes: Based on the fact that each parent node in the tree network topology of the satellite constellation has at most 2 router nodes and 1 terminal node among its child nodes, it is defined that each parent node allocates 2 receive GTS time slots and 2 transmit GTS time slots to each child router node, and that each parent node allocates 1 receive GTS time slot and 1 transmit GTS time slot to each child terminal node.

[0014] A system for designing an inter-satellite self-organizing communication network protocol, the system comprising: The protocol operation mode autonomous switching module is used to define the autonomous switching of the network protocol of each member node in the satellite cluster between debug mode and active mode according to the dynamic changes of the network environment and autonomous mission scenario in which the satellite cluster is located. The protocol operation mode autonomous switching module includes a debug mode operation module and an active mode operation module. The debug mode module is used to define the network protocols of each member node to run in debug mode under the circumstances of satellite cluster separate deployment, task reconstruction and node failure. In debug mode, neighbor discovery, tree network topology formation and role configuration between member nodes are performed. The tree network topology is configured from top to bottom according to the network depth as coordinator node, forward and backward router nodes and terminal nodes. The active mode operation module is used to define the network protocols of each member node to run in active mode after the tree network topology is formed and the network protocol has been running in debug mode for a preset debugging time. In active mode, the module performs network synchronization, network topology maintenance and node fault self-healing of the satellite cluster through Beacon frames and GTS command frames periodically sent between member nodes. At the same time, it executes a sequential Beacon scheduling strategy based on network depth to avoid frame conflicts and executes a GTS time slot allocation scheme based on tree network topology to ensure real-time communication between nodes.

[0015] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program performing the following steps: Based on the dynamic changes in the network environment and autonomous mission scenario of the satellite cluster, the network protocols of each member node in the satellite cluster are defined to autonomously switch between debug mode and active mode. In the case of satellite cluster separate deployment, mission reconfiguration and node failure, the network protocol of each member node is defined to run in debug mode, and neighbor discovery, tree network topology formation and role configuration between member nodes are performed in debug mode; the tree network topology is configured from top to bottom according to network depth as coordinator node, forward and backward router nodes and terminal nodes. After the tree-like network topology is formed and the network protocol has been running in debug mode for the preset debugging time, the network protocol of each member node is defined to run in active mode. In active mode, the network synchronization, network topology maintenance and node fault self-healing of the satellite cluster are performed through Beacon frames and GTS command frames periodically sent between member nodes. At the same time, a sequential Beacon scheduling strategy based on network depth is executed to avoid frame conflicts, and a GTS time slot allocation scheme based on tree-like network topology is executed to ensure real-time communication between nodes.

[0016] The aforementioned inter-satellite self-organizing communication network protocol design method, system, and device define that, based on the dynamic changes in the network environment and autonomous mission scenario of the satellite cluster, the network protocol of each member node within the satellite cluster autonomously switches between debug and active modes. Specifically, in cases of satellite cluster separation deployment, mission reconfiguration, and node failure, the protocol operates in debug mode to perform neighbor discovery, tree-structured network topology formation, and role configuration among member nodes, achieving autonomy in the construction of the satellite cluster communication network without relying on any ground operations. After the network topology is formed and the network protocol operates in debug mode for a preset debugging period, the protocol then runs... In active mode, the satellite cluster performs network synchronization, network topology maintenance, and node fault self-healing through periodically sent Beacon frames and GTS command frames between member nodes. This allows for timely response to network faults and enables fault self-healing by switching to debug mode via a protocol. Furthermore, in active mode, a sequential Beacon scheduling strategy based on network depth ensures that data frames between nodes share the channel in an orderly and conflict-free manner. Additionally, a GTS time slot allocation scheme based on a tree-like network topology guarantees real-time (delay-bounded) communication between multi-hop nodes in the satellite cluster. In summary, this application ensures that the satellite cluster system can autonomously achieve neighbor discovery, network topology formation, role configuration, fault handling, and multi-hop real-time communication without ground intervention, ensuring autonomous network operation throughout the entire on-orbit process and significantly improving the on-orbit survivability and network communication reliability of the satellite cluster. Attached Figure Description

[0017] Figure 1 A flowchart illustrating a design method for an inter-satellite self-organizing communication network protocol; Figure 2 This is a schematic diagram showing how satellite nodes share a channel via TDMA in debug mode. Figure 3 This is a schematic diagram of the Beacon frame structure of a satellite node in debug mode. Figure 4 A schematic diagram showing the time alignment of orbital elements for each node in a satellite constellation. Figure 5 A schematic diagram of the payload fields for Beacon frames and GTS command frames; Figure 6 A schematic diagram of a sequential Beacon scheduling strategy based on network depth; Figure 7 This is a schematic diagram of a GTS time slot allocation scheme based on a tree network topology. Figure 8This is a schematic diagram of the Monta Calo simulation results for the neighbor discovery time of each node in debug mode. Figure 9 This is a schematic diagram of the Cluster-tree network topology autonomously formed by each node in the cluster during a simulation lasting 2 minutes. Figure 10 This diagram illustrates the changes in network output load and GTS throughput during network simulation; where... Figure 10 (a) is a schematic diagram of network output load. Figure 10 (b) is a schematic diagram of the GTS throughput change of satellite 1; Figure 11 This is a schematic diagram of the Cluster-tree network topology autonomously formed by each node in the cluster during a simulation lasting 6 minutes. Figure 12 This is a schematic diagram illustrating the end-to-end latency variation of application layer data packets during the simulation process; where, Figure 12 (a) is a schematic diagram of the end-to-end delay variation of application layer data packets on satellite 4. Figure 12 (b) is a schematic diagram of the end-to-end delay variation of application layer data packets on satellite 5; Figure 13 This is a schematic diagram of the internal structure of a computer device. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] In one embodiment, such as Figure 1 As shown, a design method for an inter-satellite self-organizing communication network protocol is provided, including: Based on the dynamic changes in the network environment and autonomous mission scenarios of the satellite cluster, the network protocols of each member node within the satellite cluster are defined to autonomously switch between debug and active modes. Specifically, in cases of satellite cluster decoupling, mission reconfiguration, and node failure, the network protocols of each member node are defined to run in debug mode, performing neighbor discovery, tree-structured network topology formation, and role configuration among member nodes. The tree-structured network topology is configured from top to bottom according to network depth as follows: coordinator node, forward and backward routers... The system includes (er) nodes and (ED) nodes; after the tree network topology is formed and the network protocol has been running in debug mode for a preset debugging period, the network protocol of each member node is defined to run in active mode. In active mode, the system performs network synchronization, network topology maintenance and node fault self-healing of the satellite cluster through Beacon frames and GTS (Guaranteed Time Slot) command frames periodically sent between member nodes. At the same time, it executes a sequential Beacon scheduling strategy based on network depth to avoid frame conflicts, and executes a GTS time slot allocation scheme based on tree network topology to ensure real-time communication between nodes.

[0020] The aforementioned inter-satellite self-organizing communication network protocol design method can ensure that the satellite constellation system can autonomously complete the entire process of neighbor node discovery, network topology construction, node role allocation, abnormal fault handling, and multi-hop time-delay bounded real-time communication without the intervention of ground telemetry and control commands. This enables the satellite constellation to achieve autonomous networking operation throughout the entire process in orbit, significantly improving the constellation's on-orbit survivability and the reliability of networking communication.

[0021] In one embodiment, neighbor discovery, tree network topology formation, and role configuration among member nodes are performed in debug mode, including: Step 1: Each member node running the network protocol in debug mode first, with the assistance of GNSS (Global Navigation Satellite System) second pulse signals, cyclically accesses the common channel and sends Beacon frames using Time Division Multiple Access (TDMA), such as... Figure 2 As shown, each TDMA cycle contains 20 time slots, each time slot is 1 second long, and each node occupies the time slot corresponding to its satellite ID number independently. Figure 3The Beacon frame structure of satellite nodes in debug mode is shown. The Beacon frame contains the current node ID, the number of nodes, and the list of satellite cluster orbit elements maintained locally by the current node. This list includes timestamp, node ID, semi-major axis, eccentricity, orbital inclination, right ascension of the ascending node, perigee distance, mean perigee angle, and the number of orbit elements for each node.

[0022] It should be understood that by relying on the allocation mechanism of TDMA time slots and satellite IDs, each satellite node can exclusively occupy the corresponding time slot to access the public channel in a time-sharing manner. This can avoid channel conflicts and message collisions caused by multiple nodes sending Beacon frames at the same time, achieve conflict-free and orderly scheduling of the public channel, and lay a deterministic timing foundation for the autonomous networking of the cluster while ensuring the reliable transmission and reception of Beacon frames.

[0023] Step 2: After each member node collects the orbital element information of all member nodes within the satellite cluster through direct or indirect means, the orbital elements of all member nodes are uniformly extrapolated and aligned to the starting point of the current time slot. Based on the time-aligned orbital elements of each node, the relative longitude between each member node is calculated using the Brouwer transform and the definition of relative orbital elements.

[0024] Specifically, the orbital elements extrapolation considers the J2 perturbation model, and the numerical integration of the extrapolation process uses the Runge-Kutta-7 integrator. The orbital elements of each node in the satellite constellation are time-aligned as follows: Figure 4 As shown. Relative orbital elements are defined as a sequence of six parameters, where each element is a linear or nonlinear combination of the primary and secondary absolute orbital elements, including the relative semi-major axis, relative longitude, and relative eccentricity vector. x Quantity and y Components and relative inclination orbit vectors x Quantity and y Quantity.

[0025] It should be understood that by extrapolating and aligning the orbital elements of all member nodes to the starting point of the current time slot, the orbital data of each satellite at different sampling times can be normalized to the same unified epoch, eliminating the position calculation deviation caused by the inconsistent sampling times of orbital parameters. The relative orbital element information obtained based on this has a unified calculation benchmark, ensuring that the results of subsequent neighbor identification and topology inference based on this set of orbital data are true and reliable.

[0026] Step 3: Based on the relative longitudes between each member node, construct the adjacency matrix of the satellite cluster, and select the member node with the most direct communication links as the coordinator node according to the adjacency matrix (i.e., select the node corresponding to the row with the largest sum of elements in each row of the adjacency matrix as the coordinator node); when multiple member nodes have the same number of direct communication links, select the member node that is closest to the center of the satellite cluster in the direction of satellite velocity as the coordinator node.

[0027] Specifically, the construction logic of the adjacency matrix is ​​as follows: the absolute value of the relative mean longitude between each member of the satellite cluster is used as the basic basis for determining whether a direct communication link can be established between them. When the absolute value of the relative mean longitude between two members is less than the predefined parameter Dmax (the communication range of the satellite cluster), it is determined that the two are connected, that is, the corresponding element of the adjacency matrix is ​​1; otherwise, the corresponding element of the adjacency matrix is ​​0.

[0028] Step 4: Using the coordinator node as the root node, perform forward role configuration in the +V bar direction and backward role configuration in the -V bar direction to obtain the coordinator node's forward and backward router nodes and end nodes. Then, using the newly configured forward and backward router nodes as the root node, iterate through the forward and backward role configurations until all member nodes have completed their role configurations, thus constructing the cluster-tree network topology of the satellite cluster. Here, the +V bar direction represents the satellite velocity direction, and the -V bar direction represents the negative direction of the satellite velocity direction.

[0029] The forward role configuration and the backward role configuration are two parallel iterative processes.

[0030] The forward role configuration process includes: Step 4.1.1, determining whether there are neighboring nodes within the Dmin range in the +V bar direction of the root node. If no neighboring nodes exist, proceed to Step 4.1.2; if there is one neighboring node, configure that neighboring node as an end node and then proceed to Step 4.1.2; if there are two or more neighboring nodes, configure the neighboring node with the smallest relative distance to the root node as an end node, and configure the neighboring node with the second smallest relative distance as a forward router node, ending this iteration; Step 4.1.2, within the range from Dmin to Dmax in the +V bar direction of the root node, configure the node with the smallest relative distance to the root node as a forward router node, ending this iteration; where Dmin is the subgroup communication range and Dmax is the satellite constellation communication range. These two parameters are satellite constellation flight topology control parameters and can be defined according to specific mission requirements.

[0031] The backward role configuration process includes: Step 4.2.1, determining whether there is a neighbor node within the Dmin range in the root node's -V bar direction. If no neighbor node exists, proceed to Step 4.2.2; if there is one neighbor node and the number of terminal nodes belonging to the current root node is 0, then after configuring the neighbor node as a terminal node, proceed to Step 4.2.2; otherwise, directly configure the neighbor node as a backward router node and end this round of iteration; if there are two or more neighbor nodes and the number of terminal nodes belonging to the current root node is 0, then configure the neighbor node with the smallest relative distance from the root node's trace direction as a terminal node, configure the neighbor node with the second smallest relative distance from the trace direction as a backward router node, and end this round of iteration; otherwise, directly configure the neighbor node with the smallest relative distance from the root node's trace direction as a backward router node and end this round of iteration; Step 4.2.2, within the range Dmin to Dmax in the root node's -V bar direction, configure the node with the smallest relative distance from the root node's trace direction as a backward router node and end this round of iteration.

[0032] It should be understood that by configuring forward roles in the +V bar direction and backward roles in the -V bar direction through the coordinator node, routers and terminal nodes are hierarchically divided. The remaining satellite roles are then iteratively assigned by router nodes at each level. This configuration method leverages the natural orbital motion of the satellite constellation to achieve hierarchical networking. It prioritizes deploying backbone routing nodes at points on the periphery of the constellation along its flight direction. This utilizes the reliable communication characteristics of nearby nodes within the Dmin range to lock in the terminal access range, while also expanding the constellation's communication coverage boundary through routes at both ends. Ultimately, a tree-like constellation topology is generated with the coordinator as the root and bidirectional router nodes as the backbone. The entire role allocation logic conforms to the relative orbital motion of the satellite constellation. While achieving full coverage of satellite roles across the network, it shortens the access hops from terminal nodes to backbone routes, optimizes the inter-satellite multi-hop data forwarding path length, and effectively controls transmission latency fluctuations. This provides a well-structured network architecture to support autonomous topology operation and maintenance, fault isolation, and latency-bounded real-time multi-hop inter-satellite communication.

[0033] In one embodiment, the method further includes: each member node of the network protocol running in debug mode cyclically executes the neighbor discovery, tree network topology formation and role configuration process once in each time slot, so as to robustly cope with network topology changes caused by the relative motion of the satellite cluster.

[0034] In one embodiment, a preset debugging duration is provided. The size of the satellite constellation can be flexibly set according to its member size, and the setting rules are expressed as follows: ; in, The length of the TDMA cycle. This represents the number of member nodes in the satellite constellation.

[0035] In one embodiment, in active mode, network synchronization, network topology maintenance, and node fault self-healing of the satellite cluster are performed through Beacon frames and GTS command frames periodically sent between member nodes, including: Each member node operating in active mode of the network protocol periodically sends Beacon frames to its child nodes for network synchronization, based on its role in the tree-like network topology of the satellite constellation (coordinator node, router node, or end node) and the underlying network protocol standard. Simultaneously, it periodically sends GTS command frames to its parent node for network topology maintenance and node fault self-healing. The underlying network protocol standard is IEEE 802.15.4 / ZigBee. The GTS command frame is defined as a state_report command frame sent in a GTS time slot, and both the Beacon frame and the state_report command frame contain the same payload fields, such as... Figure 5 As shown, the payload field structure includes timestamp, network status, and the orbital elements of the current node (including semi-major axis, eccentricity, orbital inclination, right ascension of the ascending node, angle of perigee, and angle of abduction).

[0036] In one embodiment, node fault self-healing includes: Within each superframe period, child nodes determine whether their parent node is functioning correctly by listening to the Beacon frames sent by the parent node. The parent node, in turn, determines whether its child nodes are functioning correctly by receiving the state_report command frames sent by the child nodes within their GTS time slots. If the parent node detects that a child node has not sent a state_report command frame for three consecutive superframe periods, it determines that the child node is faulty, and the child node's network protocol automatically switches to debug mode. Similarly, if a child node detects that its parent node has not sent a Beacon frame for three consecutive superframe periods, it determines that the parent node is faulty, and the parent node's network protocol automatically switches to debug mode.

[0037] It should be understood that through the above fault location process, faulty nodes in the network can be detected and responded to in a timely manner. The fault self-healing of the satellite constellation network can be achieved by switching to debug mode through the protocol. This effectively isolates the adverse interference of faulty nodes on the overall network topology and channel scheduling, avoids the large-scale spread of single-point faults along multi-hop links, ensures that the remaining normal satellites maintain the established role division and tree-shaped network architecture, stabilizes the latency boundary of inter-satellite multi-hop real-time communication, and improves the reliability of satellite constellation autonomous operation in orbit and network survivability.

[0038] In one embodiment, a sequential Beacon scheduling strategy based on network depth, such as... Figure 6 As shown, this includes: defining that the BI and SD of each member node in the satellite cluster adopt the same configuration; where BI is the beacon interval, representing the time period for sending Beacon frames; SD is the superframe period, representing the overall time length occupied by a single superframe; defining that in the tree-like network topology of the satellite cluster, each level of forward and backward router nodes, according to network depth, sends their own Beacon frames sequentially after the coordinator node sends its Beacon frames; where the sizes of BI and SD, the start time of forward and backward router nodes sending Beacon frames, and the maximum network depth are specified. The following requirements must be met: ; in, The start time for the forward router node to send Beacon frames. This is the start time for sending Beacon frames to subsequent router nodes. For network depth. Figure 6 In this context, SD_Coordinator represents the SD of the coordinator node, and SD_RouterN_+V and SD_RouterN_-V represent the SDs of the forward router node and the backward router node at depth n, respectively.

[0039] It should be understood that this network depth-based sequential Beacon scheduling strategy can ensure that Beacon frames and other data frames among the nodes of the satellite cluster share the channel in an orderly and conflict-free manner, thereby avoiding data collisions and message loss caused by multiple nodes simultaneously vying for the common channel.

[0040] In one embodiment, a GTS time slot allocation scheme based on a tree network topology, such as Figure 7 As shown, this includes: based on the tree-like network topology of the satellite constellation, each parent node has at most 2 router nodes and 1 terminal node among its child nodes, defining that each parent node allocates 2 receive GTS time slots and 2 transmit GTS time slots to each child router node (corresponding to...). Figure 7 The GTS for Child Router +V bar and GTS for Child Router -V bar are defined, and each parent node is allocated one receive GTS time slot and one transmit GTS time slot for each child terminal node (corresponding to...). Figure 7 GTS for Child ED (in the context of GTS for Child ED). Figure 7 The non-contention period in the time slot is dedicated to carrying the GTS guaranteed time slot. Instead of competing for the channel, the coordinator node / router node pre-schedules to allocate dedicated time slots.

[0041] It should be understood that this GTS time slot allocation scheme based on tree network topology can reserve GTS time slots in the SD of each router node and terminal node, ensuring real-time (delay-bounded) communication between multi-hop nodes in the satellite constellation and continuously guaranteeing the stability of the constellation network architecture and the smooth operation of inter-satellite communication links. Furthermore, to support multi-hop routing between nodes in the satellite constellation network, the distributed address allocation mechanism defined in the Zigbee standard and the tree routing mechanism proposed by Motorola can be adopted.

[0042] Furthermore, in order to verify the effectiveness of the method proposed in this application, the inter-satellite self-organizing communication network protocol designed in this application was modeled and implemented in the OPNET Modeler environment, and simulation experiments were conducted based on the independently developed satellite cluster communication network joint simulation testbed.

[0043] The co-simulation testbed for satellite cluster communication networks constructed in this paper mainly consists of four parts: a network communication simulator, an orbital dynamics simulator, a navigation, guidance and control (GNC) simulator, and a co-simulation coordinator. These four simulators are integrated through the Esys module within OPNET Modeler, realizing the functional integration of three types of COTS simulation software—OPNET Modeler, Matlab, and STK.

[0044] Specifically, OPNET Modeler, as a network communication simulator, primarily performs network protocol modeling, co-simulation control, and simulation statistics acquisition and visualization. The GNC simulator, a DLL file developed in Matlab, mainly implements the satellite constellation flight control algorithm, achieving accurate simulation of the relative motion of the satellite constellation by calling STK. STKEngine is the actual implementer of the orbital dynamics simulator, performing corresponding orbit extrapolation calculations based on the received GNC call instructions. The execution controller, a DLL file developed in C, is responsible for switching simulation execution rights between different simulators.

[0045] To verify the functional performance of the inter-satellite self-organizing communication network protocol designed in this application in terms of autonomous neighbor discovery, autonomous configuration, fault self-healing and multi-hop real-time communication, a satellite cluster simulation scenario with 7 member satellites was designed, with a simulation duration of 10 minutes.

[0046] In terms of the simulation configuration for satellite cluster network communication, at the start of the simulation, it was assumed that each node in the satellite cluster was an isolated node without network interconnection. The transmitter output power on each node was set to 1W, and the default configuration was an omnidirectional antenna. After the simulation started, the network protocols in each node ran in debug mode, and the neighbor discovery process was initiated. After 2 minutes, the network protocols of each node switched to active mode, autonomously configured network roles, and formed a real-time communication network with a cluster-tree structure. After 5 minutes, node #7 simulated a failure, and other network nodes autonomously identified the failure according to the protocol design and gradually switched to debug mode, restarting the autonomous neighbor discovery process. To test the multi-hop real-time communication performance of the satellite cluster cluster-tree structure communication network, a real-time communication service flow sent from node #1 to the coordinator node (network address 0) was defined in the simulation scenario. The specific parameter configuration is shown in Table 1.

[0047] Table 1 Real-time data service flow in the simulation scenario

[0048] To evaluate and test the autonomous neighbor discovery capability of each node in the satellite constellation in debug mode, the neighbor discovery time index of a node is defined as: the time when the node first (directly or indirectly) receives the orbit information of all nodes in the constellation, that is, the time when each node first perceives the global connectivity graph of the satellite constellation. Figure 8 The image shows the results of 100 Monta Carlo simulations of neighbor discovery times for each node. Figure 8 As can be seen, the neighbor discovery time for each node is generally less than 30 seconds.

[0049] Once the neighbor discovery process is complete, each node in the satellite cluster immediately initiates the Cluster-tree network topology formation process. Figure 9 The study demonstrates the Cluster-tree network topology autonomously generated by each node in the satellite cluster during the first debug mode, proving that each node has the ability to autonomously configure network roles and autonomously allocate network addresses.

[0050] Figure 10 The diagram shows the changes in network output load and GTS time slot throughput of node 1 during the simulation process. Figure 10 It is evident that network data communication was interrupted between 4 and 6 minutes due to the failure of node 7. Fortunately, however, after 6 minutes, with the formation of a new cluster-tree network topology (see...),... Figure 11 The network data communication service returned to normal. This fully demonstrates that the satellite constellation network, using the network protocol designed in this application, possesses a self-healing function.

[0051] Figure 12 The image shows an end-to-end latency statistics chart for application layer data packets during the simulation process. For example... Figure 9 , Figure 11 It can be seen that before the failure of node 7, the real-time data service on satellite node 1 was relayed to node 4 (MAC address 0) via node 3 through multiple hops. After the failure of node 7, due to the reconstruction of the network topology, the real-time data service on satellite node 1 was relayed to node 5 (MAC address 0) via multiple hops via node 3. Despite the change in the destination node, the satellite constellation network can provide bounded communication latency of less than 1 second between multi-hop nodes both before and after the failure of node 7.

[0052] Based on the above simulation results and compared with existing technological achievements, the beneficial results of this application are: (1) To address the common neglect of autonomy in the inter-satellite communication network construction process in existing technologies, this application constructs an autonomous neighbor discovery mechanism based on TDMA and a Cluster-tree network topology formation mechanism and network role configuration mechanism based on satellite orbital element information. This enables the autonomous construction of satellite cluster communication networks without relying on any ground operations. The simulation results of the relevant processes are available. Figure 8 and Figure 9 .

[0053] (2) Addressing the issue of autonomous handling and response in the event of network node failures, which is generally neglected in existing technologies, this application achieves rapid location and timely response to communication network node failures through periodic monitoring of Beacon frames and GTS command frames of each node in the satellite constellation and autonomous switching of network protocol modes, thus realizing self-healing of the satellite constellation network. Simulation results of the relevant process are available. Figure 10 and Figure 11 .

[0054] (3) To address the issue that existing technologies do not adequately address real-time communication in multi-hop satellite constellation networks, this application designs a Beacon scheduling mechanism and a GTS time slot allocation mechanism adapted to the network topology, which can guarantee real-time (delay-bounded) communication between multi-hop nodes in a satellite constellation. Simulation results of the relevant processes are available. Figure 12 .

[0055] (4) Addressing the common shortcomings of existing technologies in verifying network protocols within a realistic satellite constellation dynamics environment and in considering adaptability to dynamic changes in network topology caused by relative motion of satellite constellations, this application models the designed network protocol in the OPNET Modeler environment and conducts simulation experiments using a self-developed satellite constellation communication network co-simulation testbed. The co-simulation testbed integrates an orbital dynamics simulator and a navigation, guidance, and control simulator, enabling high-precision simulation of the real relative motion process of satellite constellations. (Comparison) Figure 9 and Figure 11 It is evident that the inter-satellite self-organizing network protocol proposed in this application can robustly cope with network topology changes caused by relative motion of satellite clusters and node failures, and dynamically adjust the role configuration of network nodes in a timely manner.

[0056] In one embodiment, an inter-satellite self-organizing communication network protocol design system is provided, comprising: The protocol operation mode autonomous switching module is used to define the autonomous switching of the network protocol of each member node in the satellite cluster between debug mode and active mode according to the dynamic changes of the network environment and autonomous mission scenario in which the satellite cluster is located. The protocol operation mode autonomous switching module includes a debug mode operation module and an active mode operation module. The debug mode module is used to define the network protocols of each member node to run in debug mode under the circumstances of satellite cluster separate deployment, task reconstruction and node failure. In debug mode, neighbor discovery, tree network topology formation and role configuration between member nodes are performed. The tree network topology is configured from top to bottom according to the network depth as coordinator node, forward and backward router nodes and terminal nodes. The active mode operation module is used to define the network protocols of each member node to run in active mode after the tree network topology is formed and the network protocol has been running in debug mode for a preset debugging time. In active mode, the module performs network synchronization, network topology maintenance and node fault self-healing of the satellite cluster through Beacon frames and GTS command frames periodically sent between member nodes. At the same time, it executes a sequential Beacon scheduling strategy based on network depth to avoid frame conflicts and executes a GTS time slot allocation scheme based on tree network topology to ensure real-time communication between nodes.

[0057] Specific limitations regarding the design system of the inter-satellite ad hoc communication network protocol can be found in the limitations on the design method of the inter-satellite ad hoc communication network protocol mentioned above, and will not be repeated here. Each module in the above-mentioned inter-satellite ad hoc communication network protocol design system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0058] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 13 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a design method for an inter-satellite self-organizing communication network protocol.

[0059] Those skilled in the art will understand that Figure 13 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0060] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the following steps: Based on the dynamic changes in the network environment and autonomous mission scenario of the satellite cluster, the network protocols of each member node in the satellite cluster are defined to autonomously switch between debug mode and active mode. In the case of satellite cluster separate deployment, mission reconfiguration and node failure, the network protocol of each member node is defined to run in debug mode, and neighbor discovery, tree network topology formation and role configuration between member nodes are performed in debug mode; the tree network topology is configured from top to bottom according to network depth as coordinator node, forward and backward router nodes and terminal nodes. After the tree-like network topology is formed and the network protocol has been running in debug mode for the preset debugging time, the network protocol of each member node is defined to run in active mode. In active mode, the network synchronization, network topology maintenance and node fault self-healing of the satellite cluster are performed through Beacon frames and GTS command frames periodically sent between member nodes. At the same time, a sequential Beacon scheduling strategy based on network depth is executed to avoid frame conflicts, and a GTS time slot allocation scheme based on tree-like network topology is executed to ensure real-time communication between nodes.

[0061] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0062] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0063] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application.

Claims

1. A design method for an inter-satellite self-organizing communication network protocol, characterized in that, The method includes: Based on the dynamic changes in the network environment and autonomous mission scenario of the satellite cluster, the network protocols of each member node in the satellite cluster are defined to autonomously switch between debug mode and active mode. In the case of satellite cluster separate deployment, mission reconfiguration and node failure, the network protocol of each member node is defined to run in debug mode, and neighbor discovery, tree network topology formation and role configuration between member nodes are performed in debug mode; wherein, the tree network topology is configured from top to bottom according to network depth as coordinator node, forward and backward router nodes and terminal nodes. After the tree network topology is formed and the network protocol has been running in debug mode for a preset debugging period, the network protocol of each member node is defined to run in active mode. In active mode, the satellite cluster network synchronization, network topology maintenance and node fault self-healing are performed through Beacon frames and GTS command frames periodically sent between member nodes. At the same time, a sequential Beacon scheduling strategy based on network depth is executed to avoid frame conflicts, and a GTS time slot allocation scheme based on tree network topology is executed to ensure real-time communication between nodes. In debug mode, the processes of neighbor discovery, tree network topology formation, and role configuration among member nodes are performed, including: Step 1: Each member node running the network protocol in debug mode first accesses the common channel cyclically and sends Beacon frames in a time-division multiple access manner with the assistance of the GNSS second pulse signal. The Beacon frame contains the current node ID, the number of nodes, and the list of satellite cluster orbit elements maintained locally by the current node. Step 2: After each member node collects the orbital element information of all member nodes within the satellite cluster through direct or indirect means, the orbital elements of all member nodes are uniformly extrapolated and aligned to the starting point of the current time slot. Based on the time-aligned orbital elements of each node, the relative longitude between each member node is calculated using the Brouwer transform and the definition of relative orbital elements. Step 3: Based on the relative longitude between each member node, construct the adjacency matrix of the satellite cluster, and select the member node with the most direct communication links as the coordinator node according to the adjacency matrix; wherein, when multiple member nodes have the same number of direct communication links, select the member node that is closest to the center of the satellite cluster in the satellite velocity direction as the coordinator node. Step 4: Using the coordinator node as the root node, perform forward role configuration in the +V bar direction and backward role configuration in the -V bar direction to obtain the coordinator node's forward and backward router nodes and terminal nodes. Then, using the newly configured forward and backward router nodes as the root node, iteratively perform forward and backward role configuration until all member nodes have completed role configuration, thus constructing the tree-like network topology of the satellite cluster. Here, the +V bar direction is the satellite velocity direction, and the -V bar direction is the negative direction of the satellite velocity direction. The network depth-based sequential Beacon scheduling strategy includes: The BI and SD of each member node in the satellite cluster are defined to use the same configuration; where BI is the beacon interval, which represents the time period for sending Beacon frames; and SD is the superframe period, which represents the total time length occupied by a single superframe. In a tree-like network topology of a satellite constellation, each level of forward and backward router nodes sends their own Beacon frames sequentially after the coordinator node sends a Beacon frame, according to the network depth. The values ​​of BI and SD, the start time of Beacon frame transmission by forward and backward router nodes, and the maximum network depth are defined. The following requirements must be met: ； in, The start time for the forward router node to send Beacon frames. This is the start time for sending Beacon frames to subsequent router nodes. For network depth.

2. The inter-satellite self-organizing communication network protocol design method according to claim 1, characterized in that, The forward role configuration process includes: Step 4.1.1, determining whether there are neighboring nodes within the Dmin range in the +V bar direction of the root node; if no neighboring nodes exist, proceeding to Step 4.1.2; if there is one neighboring node, configuring that neighboring node as an end node and then proceeding to Step 4.1.2; if there are two or more neighboring nodes, configuring the neighboring node with the smallest relative distance to the root node in the trace direction as an end node, configuring the neighboring node with the second smallest relative distance in the trace direction as a forward router node, and ending this round of iteration; Step 4.1.2, within the range from Dmin to Dmax in the +V bar direction of the root node, configuring the node with the smallest relative distance to the root node in the trace direction as a forward router node, and ending this round of iteration; where Dmin is the subgroup communication range and Dmax is the satellite cluster communication range; The backward role configuration process includes: Step 4.2.1, determining whether there is a neighbor node within the Dmin range in the root node-V bar direction. If no neighbor node exists, proceed to Step 4.2.2; if there is one neighbor node and the number of terminal nodes belonging to the current root node is 0, then after configuring the neighbor node as a terminal node, proceed to Step 4.2.2; otherwise, directly configure the neighbor node as a backward router node and end this round of iteration; if there are two or more neighbor nodes and the number of terminal nodes belonging to the current root node is 0, then configure the neighbor node with the smallest relative distance from the root node in the trace direction as a terminal node, configure the neighbor node with the second smallest relative distance in the trace direction as a backward router node, and end this round of iteration; otherwise, directly configure the neighbor node with the smallest relative distance from the root node in the trace direction as a backward router node and end this round of iteration; Step 4.2.2, within the range Dmin to Dmax in the root node-V bar direction, configure the node with the smallest relative distance from the root node in the trace direction as a backward router node and end this round of iteration.

3. The inter-satellite self-organizing communication network protocol design method according to claim 2, characterized in that, The method further includes: Each member node of the network protocol, running in debug mode, executes the neighbor discovery, tree-structured network topology formation, and role configuration processes cyclically once in each time slot to robustly cope with network topology changes caused by the relative motion of the satellite constellation.

4. The inter-satellite self-organizing communication network protocol design method according to claim 1, characterized in that, The preset debugging time The size of the satellite constellation can be flexibly set according to its member size, and the setting rules are expressed as follows: ； in, The length of the TDMA cycle. This represents the number of member nodes in the satellite constellation.

5. The inter-satellite self-organizing communication network protocol design method according to claim 1, characterized in that, In active mode, network synchronization, network topology maintenance, and node fault self-healing of the satellite cluster are performed through Beacon frames and GTS command frames periodically sent between member nodes, including: Each member node operating in active mode of the network protocol periodically sends Beacon frames to its child nodes for network synchronization, based on its role in the tree-like network topology of the satellite constellation and the underlying standard of the network protocol. Simultaneously, it periodically sends GTS command frames to its parent node for network topology maintenance and node fault self-healing. The underlying standard of the network protocol is IEEE 802.15.4 / ZigBee. The GTS command frame is defined as a state_report command frame sent in a GTS time slot, and both the Beacon frame and the state_report command frame have the same payload field.

6. The inter-satellite self-organizing communication network protocol design method according to claim 5, characterized in that, The node fault self-healing includes: Within each superframe period, the child node determines whether its parent node is working properly by listening to the Beacon frames sent by the parent node, and the parent node determines whether its child node is working properly by receiving the state_report command frames sent by the child node in its GTS time slot. If the parent node finds that a child node has not sent a state_report command frame for three consecutive superframe cycles, it determines that the child node is faulty, and the child node’s network protocol will automatically switch to debug mode. If a child node detects that its parent node has not sent Beacon frames for three consecutive superframe cycles, it determines that the parent node is faulty, and the parent node's network protocol will automatically switch to debug mode.

7. The inter-satellite self-organizing communication network protocol design method according to claim 1, characterized in that, The GTS time slot allocation scheme based on tree network topology includes: Based on the fact that each parent node in the tree network topology of the satellite constellation has at most 2 router nodes and 1 terminal node among its child nodes, it is defined that each parent node allocates 2 receive GTS time slots and 2 transmit GTS time slots to each child router node, and that each parent node allocates 1 receive GTS time slot and 1 transmit GTS time slot to each child terminal node.

8. A design system for an inter-satellite self-organizing communication network protocol, characterized in that, The system includes: The protocol operation mode autonomous switching module is used to define the autonomous switching of the network protocol of each member node in the satellite cluster between debug mode and active mode according to the dynamic changes of the network environment and autonomous mission scenario in which the satellite cluster is located; the protocol operation mode autonomous switching module includes a debug mode operation module and an active mode operation module. The debug mode operation module is used to define the network protocol of each member node to run in debug mode under the circumstances of satellite cluster separate deployment, task reconstruction and node failure, and to perform neighbor discovery, tree network topology formation and role configuration among member nodes in debug mode; wherein, the tree network topology is configured from top to bottom according to network depth as coordinator node, forward and backward router nodes and terminal nodes. The active mode operation module is used to define the network protocol of each member node to run in active mode after the tree network topology is formed and the network protocol has been running in debug mode for a preset debugging time. In active mode, the module performs network synchronization, network topology maintenance and node fault self-healing of the satellite cluster through Beacon frames and GTS command frames periodically sent between member nodes. At the same time, it executes a sequential Beacon scheduling strategy based on network depth to avoid frame conflicts and executes a GTS time slot allocation scheme based on tree network topology to ensure real-time communication between nodes. In debug mode, the processes of neighbor discovery, tree network topology formation, and role configuration among member nodes are performed, including: Step 1: Each member node running the network protocol in debug mode first accesses the common channel cyclically and sends Beacon frames in a time-division multiple access manner with the assistance of the GNSS second pulse signal. The Beacon frame contains the current node ID, the number of nodes, and the list of satellite cluster orbit elements maintained locally by the current node. Step 2: After each member node collects the orbital element information of all member nodes within the satellite cluster through direct or indirect means, the orbital elements of all member nodes are uniformly extrapolated and aligned to the starting point of the current time slot. Based on the time-aligned orbital elements of each node, the relative longitude between each member node is calculated using the Brouwer transform and the definition of relative orbital elements. Step 3: Based on the relative longitude between each member node, construct the adjacency matrix of the satellite cluster, and select the member node with the most direct communication links as the coordinator node according to the adjacency matrix; wherein, when multiple member nodes have the same number of direct communication links, select the member node that is closest to the center of the satellite cluster in the satellite velocity direction as the coordinator node. Step 4: Using the coordinator node as the root node, perform forward role configuration in the +V bar direction and backward role configuration in the -V bar direction to obtain the coordinator node's forward and backward router nodes and terminal nodes. Then, using the newly configured forward and backward router nodes as the root node, iteratively perform forward and backward role configuration until all member nodes have completed role configuration, thus constructing the tree-like network topology of the satellite cluster. Here, the +V bar direction is the satellite velocity direction, and the -V bar direction is the negative direction of the satellite velocity direction. The network depth-based sequential Beacon scheduling strategy includes: The BI and SD of each member node in the satellite cluster are defined to use the same configuration; where BI is the beacon interval, which represents the time period for sending Beacon frames; and SD is the superframe period, which represents the total time length occupied by a single superframe. In a tree-like network topology of a satellite constellation, each level of forward and backward router nodes sends their own Beacon frames sequentially after the coordinator node sends a Beacon frame, according to the network depth. The values ​​of BI and SD, the start time of Beacon frame transmission by forward and backward router nodes, and the maximum network depth are defined. The following requirements must be met: ； in, The start time for the forward router node to send Beacon frames. This is the start time for sending Beacon frames to subsequent router nodes. For network depth.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

Images