A low-overhead OSPF protocol improvement method for large-scale polar orbit constellations

Abstract

A low-overhead OSPF protocol improvement method for large-scale polar orbiting constellations utilizes the existing OSPF / OSPF+ protocol mechanism with the following improvements: 1) "Orbital Zone" division to reduce routing computational resource overhead; 2) a pre-configured link state database to reduce unnecessary message transmission; and 3) a new link "Test State" to ensure link reliability. In addition to the "Leave State" already present in the existing OSPF+ neighbor state machine, a new "Test State" is added. Regardless of whether a link is within or between "Orbital Zones," the link and its corresponding neighbors have four deterministic states: Connected, Leave, Test, and Closed. Predictable link interruptions and restorations are no longer communicated via Link State Update messages, accelerating route reconvergence in the event of predictable link interruptions and restorations and reducing unnecessary use of inter-satellite link resources.

Description

Technical Field

[0001] The present invention belongs to the field of satellite communications, and in particular relates to a low-overhead OSPF protocol improvement method for large-scale polar orbit constellations. Background Art

[0002] The OSPF protocol, developed by the IETF, is an intra-domain routing protocol based on a link-state algorithm. It features wide adaptability, no loops, rapid response to link changes, and ease of hierarchical network design. In low-orbit satellite networks, factors such as link switching, failures, and environmental interference can lead to frequent link interruptions or failures, and topology changes. Therefore, dynamic routing is necessary to address these topology changes. However, while a significant portion of topology changes in low-orbit satellite networks are predictable, the OSPF protocol cannot effectively address these predictable link connectivity changes. After periodic link disconnections, a certain period of time is required to determine the link is disconnected and recalculate the route. To address this issue, Xu Mingwei et al. (Xu Mingwei, Xia Anqing, Yang Yuan, Wang Yuliang, Sang Meng. OSPF+, a space-ground integrated network domain routing protocol [J]. Journal of Tsinghua University (Science and Technology), 2017, 57(01):12-17) proposed an integrated space-ground domain routing protocol OSPF+ based on the OSPF protocol. This protocol introduces a link prediction mechanism. When a predictable link interruption occurs, it skips the original OSPF protocol neighbor relationship establishment or failure judgment process and directly broadcasts the link status information, thereby achieving rapid updating of the routing table.

[0003] For small or medium-sized satellite communication systems, the OSPF+ protocol can achieve rapid convergence when predictable topology changes occur. However, when using OSPF+ in large-scale low-orbit satellite communication systems, there are two drawbacks:

[0004] First, in large-scale low-orbit satellite communication systems, the OSPF+ protocol retains the existing OSPF region division mechanism, which cannot effectively reduce the number of nodes within a single region. This results in high routing recalculation overhead and increases onboard processor load. Specifically, during the OSPF region division process, non-backbone regions must be directly connected to the backbone region, and backbone regions must be logically contiguous. In the case of logically discontinuous backbone regions, virtual links are configured to connect the separated backbone regions. Large-scale low-orbit satellite communication systems generally exhibit a mesh topology, and connections between satellites in the same orbital plane are relatively stable. Therefore, during the region division process, satellites in the same orbital plane are preferably assigned to the same region. In this case, without virtual links, the system can be divided into a maximum of three regions (a central backbone region and two flanking non-backbone regions). While using virtual links allows for multiple regions, a backbone region is still required between each region, and these backbone regions must be logically contiguous, ultimately preventing the effective reduction of the backbone region size. Therefore, this region division method is less effective in satellite networks.

[0005] Secondly, redundant link state announcement messages consume a large amount of onboard resources. When inter-satellite links have high bit error rates and long transmission delays, they will squeeze inter-satellite link bandwidth, resulting in resource waste and impacting the transmission of service data streams. Specifically, every time a link experiences a predictable link outage and restoration, a Link State Update (LSU) message is still needed to notify the user. This message contains Link State Advertisement (LSA). After receiving an LSU from another node, each node stores the LSA in its Link State Database (LSDB) and floods all LSAs to all other ports. Due to the large number of nodes within the network, when a large number of links undergo periodic up / down cycles, the volume of LSU messages generated is enormous, consuming a significant amount of link bandwidth resources.

[0006] In large-scale low-orbit satellite communication systems, inclined and polar orbit constellations are commonly used. In inclined orbit constellations, satellite connections are relatively stable, resulting in fewer inter-satellite routing updates and recalculations, making the drawbacks of the OSPF+ protocol less pronounced. However, in polar orbit constellations, a typical link establishment scenario involves each satellite establishing links with two adjacent satellites in the same orbit, as well as with satellites with the same number in adjacent orbital planes. At the reverse seam, due to the satellites' opposing directions of travel, a stable link cannot be established and no further links are established. When satellites reach higher latitudes, the rapid relative motion of satellites in adjacent orbits also hinders link establishment. Consequently, intra-orbit link connectivity fluctuates as satellites enter and exit polar regions. In this scenario, if the system has a large number of satellites, link connectivity fluctuates continuously, significantly exacerbating the two drawbacks of the OSPF+ protocol. Therefore, an improved dynamic routing protocol is needed to adapt to large-scale polar-orbit low-orbit satellite communication systems. Summary of the Invention

[0007] The purpose of the present invention is to provide a low-overhead OSPF improved protocol and its implementation method for large-scale polar orbit constellations, aiming to utilize fewer on-board resources to effectively run dynamic routing protocols in large-scale polar orbit low-orbit satellite communication systems, and to solve the defects of existing dynamic routing protocols such as OSPF / OSPF+ in the operation of large-scale polar orbit satellite communication systems, namely, the problem of waste of computing resources due to high computing overhead (routing recalculation overhead) and the problem of waste of resources due to a large number of redundant messages crowding out inter-satellite links.

[0008] The technical solution of the present invention is a low-overhead OSPF protocol improvement method for large-scale polar orbit constellations. Based on the original mechanism of the OSPF / OSPF+ protocol, the present invention provides the following improvements:

[0009] (1) Divide the track area to reduce the routing computing resource overhead.

[0010] The existing network partitioning mechanism is changed, dividing the entire spatial network into multiple "track zones." Each "track zone" contains several tracks and is assigned a fixed IP network segment. All links within a "track zone" will be assigned a separate IP subnet segment under the "track zone" network segment.

[0011] Routing information within a track area is calculated using Router-LSAs, the first type of LSAs defined by the OSPF protocol, generated by each node within the area. Routing information outside the track area is calculated using AS-External-LSAs, the fifth type of LSAs defined by the OSPF protocol, generated by nodes at the edge of the track area. At the same time, nodes at the edge of the track area and adjacent nodes in another track area will send Hello messages to each other to detect the validity of the inter-track link between them. If either node detects that the link has failed, it will broadcast a fifth type of LSA via an LSU message to notify the remaining nodes within its respective track area.

[0012] (2) Pre-set the link state database to reduce unnecessary message sending.

[0013] The entire orbital cycle of satellites within the system is divided into several time slots. During each time slot, unless an unexpected failure occurs, the connectivity between satellites within the entire system remains stable. However, when a time slot switches, links within the entire system must undergo predictable connectivity changes, and routing switches must occur simultaneously. For specific polar orbiting constellation scenarios, the number of time slots and switching intervals must be determined based on the topology and link planning of the polar orbiting constellation in which the protocol is actually running.

[0014] A link state database is pre-set for each track zone, and all nodes within that zone maintain this database. This pre-set database contains Type I and Type V LSA information for all nodes within that track zone throughout its entire operating cycle, along with information about the connectivity and disconnection of all links within that zone during all time slots. When a time slot switch occurs, if a node detects through Hello messages that the status of all its connected links after the time slot switch matches the pre-set information, it will not send an LSU message, even if the connectivity of its adjacent links changes. This means that any predictable link disruption or recovery will no longer be communicated via LSU messages, and each node will autonomously calculate the route after the time slot switch. However, if a node detects an unpredictable link disruption, it will notify the other nodes within its track zone via an LSU message. If the link recovers after a period of time, it will also notify the other nodes via an LSU message.

[0015] When a time slot switch occurs, all nodes must also manage their own link state databases. LSAs related to unpredictable link outages, obtained via LSU messages, do not carry time slot information, making them easily distinguishable from pre-set LSAs. For LSAs that have been restored to be consistent with the pre-set information, the original pre-set LSAs with time slot information are restored. For LSAs that are still inconsistent with the pre-set information, check whether any of them involve links that will be disconnected in the next time slot. If so, label them so that they do not participate in the shortest path calculation for the next time slot. After management is completed, route recalculation is performed to adapt to the topology within the new time slot.

[0016] (3) Added link "test status" to ensure link connection reliability.

[0017] Due to the relatively harsh communication environment in space, satellite nodes are unable to accurately establish links at the preset time points. For this reason, a new "test state" is added to the original OSPF+ neighbor state machine on the basis of adding the "leave state". Regardless of whether a link is located within the "orbital area" or between "orbital areas", the link and the neighbor corresponding to the link have four deterministic states: connected, left, tested, and closed. Each node will independently set up a neighbor state machine for all its adjacent neighbor nodes, and each neighbor node will have a corresponding link. During operation, for each node, the states of all its links and neighbor nodes are converted as described below:

[0018] For any node in the system, before starting operation, all its connected links and neighbors are placed in the "closed state". When entering the first time slot, it chooses to enter the "connected state" or "left state" according to the preset link connection and disconnection information.

[0019] If a link of a node is in the "connected state" and the link is disconnected in the next time slot, it will directly enter the "left state" after the time slot switch, and the disconnected link will no longer participate in the routing calculation.

[0020] If a link of a node is in the "Leave state" and is predicted to be converted to the "Connect state" in the next time slot, it will be advanced for a period of time T before the time slot switching occurs. Test (For example, 30s) to start trying to connect to the link, and send a message to the neighbor at the other end of the link at a certain time interval T Hello (For example, 3 seconds) Hello packets are continuously sent, at which point the link enters the "test state". Test It should be ensured that the link can be connected within the time without any accidents. At the same time, the latitude corresponding to the time point of connection completion should be reasonably designed to ensure that the link connection conditions are met when the connection starts. HelloThe selection should ensure that T Test A certain number of Hello packets can be sent within a certain time period to prevent misjudgment due to accidental packet loss. Hello and T Test It can be determined based on the actual on-board packet loss probability test results. The number of packets sent can ensure a certain degree of judgment accuracy. If the link between this node and the neighboring node is successfully connected in the "test state", no LSU message will be sent. The remaining nodes in the "orbital area" where the node is located will directly complete the calculation according to the LSA in the preset database. If T Test If a connection cannot be completed within the specified time slot, the node will notify the other nodes in the "track area" where the node is located through an LSU message. The other nodes will perform calculations based on the LSA contained in the received LSU message. At the same time, the neighbor state machine will remain in the "test state" and continue to detect whether the link is connected. Once the connection with the neighbor node at the other end of the link is completed, the LSU message will be used again to notify the other nodes that the link has returned to normal. If the link is still not connected within the entire time slot, then when the next time slot switch occurs, the link is considered to have temporarily failed, and the neighbor state machine will transition to the "closed state" to wait for the link to be repaired.

[0021] For a satellite with a total number of N, a number of orbits of P, and a phase factor of F (i.e., the phase difference of satellites with the same number in adjacent orbits is For a polar-orbiting constellation (where F is an integer, 0 ≤ F ≤ P-1), the typical inter-satellite link establishment scenario is as follows: each satellite establishes links with two adjacent satellites in the same orbit, and also with satellites with the same number in adjacent orbital planes. No links are established at the reverse gap. When a satellite orbits above a certain latitude, the inter-orbit link is disconnected. If the link establishment for a polar-orbiting constellation meets these typical scenarios, the OSPF protocol can be configured according to the following five steps. If a satellite's position deviates from the ideal constellation, but this deviation does not affect its connectivity with other satellites or ground nodes at all times, the actual constellation satellite position can be mapped to its ideal position, and the improved OSPF protocol can be deployed according to the following steps.

[0022] For the sake of convenience, it is assumed that the satellites in the system are represented by S(i,j)(0≤i≤P-1,0≤j≤n-1), where i represents the orbit number and j represents the satellite number in the orbit. The latitude where the satellite link is disconnected is recorded as lat M , the number of satellites in a single orbit is n, then nP=N.

[0023] Step 1: Determine the number of time slots m.

[0024] The satellite operation cycle of the entire system is divided into several time slots. During each time slot, if no unexpected failures occur, the connectivity between satellites in the entire system remains stable. However, when a time slot switch occurs, links in the entire system must undergo predictable connectivity changes, and routing switches must be performed simultaneously. Therefore, the total number of routing switches that occur during the orbital cycle of a polar-orbiting satellite communication constellation is the number of time slots, m.

[0025] In order to conveniently obtain the value of m, considering that the topology of the polar orbit constellation is repetitive, it is first necessary to determine the minimum number of orbits k that causes the topology to repeat. The meaning of k is, let i = 0, observe the connection relationship between the satellites in the i-th orbit and the i+1-th orbit, and i increases from 0 to P-2. After k orbits, the connection relationship between satellites at the same latitude may be completely repeated, that is, the connection between the satellites on orbit k and orbit k+1 is exactly the same as the connection relationship between the satellites at the corresponding latitudes on orbits 0 and 1 at any time. The value of k is calculated by formula (1):

[0026]

[0027] The number of time slots is then calculated as follows:

[0028] (1) If kn is an even number, then When it is an integer, m=kn, otherwise m=2kn;

[0029] (2) If kn is an odd number, then When is an integer, m=2kn, otherwise m=4kn.

[0030] Step 2: Determine the on / off status of all links in each time slot.

[0031] (1) Assume that the satellite S(0,0) is located at latitude lat M At this point, the latitudes of the satellites at both ends of all inter-orbit links are calculated as the initial latitude values, and the current time slot value is recorded as 0. Based on the latitude values ​​of the satellites at both ends of each link, it is determined whether it is in a connected or disconnected state.

[0032] (2) Assume that the direction of the track is: at time slot 0, S(0,0) is moving from south to north. Find the link closest to the switch in the current time slot (if there are multiple links, you can choose any one), and calculate the latitude lat that needs to be turned from this link to switch. add , then the time slot value is increased by 1, and all satellites are calculated according to the direction of movement and the latitude lat add The latitude values ​​at both ends of the link are then determined to be connected or disconnected.

[0033] (3) Repeat step (2) until the satellite S(0,0) completes one orbit around the earth. At this time, the time slot value should increase to m-1, and the on-off status of all links in each time slot has been calculated. At the same time, since the latitude lat add It has been calculated, and the angular velocity of the satellite is known, so the switching time interval will also be determined accordingly.

[0034] Step 3: Divide the track area.

[0035] Determine the number of tracks in each track zone and divide the track zone. If you want to minimize the time for route calculation, you can divide the track zone as follows:

[0036] Assume that each “track zone” has x tracks, where x is a positive integer and x ≥ 2 (when x is 1, routing islands are likely to occur, so this is not considered). Then the number of track zones in the entire system can be expressed as The number of nodes in each "track zone" can be expressed as nx.

[0037] If there are y Router-LSAs in the database, and priority queuing is used to calculate the shortest path, the route calculation time can be expressed as:

[0038] T1(y)=aylog2y+by+c (where a, b, c are fixed parameters) (2)

[0039] If there are y AS-External-LSAs in the database, the route calculation time can be expressed as:

[0040] T2(y)=dy+e (where d and e are fixed parameters) (3)

[0041] The parameters a, b, c, d, and e can be determined as follows: Test the protocol's route calculation module by varying the number of Router-LSAs and AS-External-LSAs and measuring the route calculation time. After performing multiple measurements, use statistical regression to determine the values ​​of a, b, c, d, and e.

[0042] The total calculation time T(x) can be expressed as:

[0043]

[0044] The derivative is

[0045]

[0046] Therefore, T′(x) is monotonically increasing and can be divided into the following cases:

[0047] (1) When T′(2)≤0, there exists x0∈[2,+∞) such that T′(x0)=0. At this point, the routing calculation time reaches its minimum, and x0 can be numerically solved using a computer. Generally speaking, if x0 is not an integer, x1 is the largest integer not greater than x0, and x2 is the smallest integer not less than x0. If T(x1)≤T(x2), then x1 is the optimal value; otherwise, x2 is the optimal value.

[0048] (2) When T′(2)>0, there is no x0∈[2,+∞) such that T′(x0)=0, so the number of tracks with the shortest routing calculation time is 2.

[0049] Get the number of tracks x in a single "track zone" that minimizes the routing calculation time Best After that, you can divide the "track area". Just start from track 0 and divide x Best Each track can be divided into a "track area". When it is not an integer, if the remainder is 1, the last track will be merged into the last "track area". If the remainder is greater than or equal to 2, the unallocated track at the end will be divided into a separate "track area".

[0050] Step 4: Allocate IP addresses and write out the pre-configured link state database.

[0051] After the "track area" is divided, each "track area" is assigned an independent network segment. The subnet mask length of this network segment must ensure that each link in it can be allocated a subnet segment under the "track area" network segment. The subnet mask length of the link subnet segment is up to 30. At the same time, the link between two "track areas" must also be assigned an independent IP network segment.

[0052] For each "track zone", based on the above network segment allocation and link connectivity calculation, its link state database is directly written. During operation, all nodes within each "track zone" will load the same preset link state database.

[0053] Step 5: Load the pre-set link state database, align the time slots, and run the protocol.

[0054] When the protocol is run on a satellite, the link state database of the "orbital zone" to which it belongs is loaded first. When the satellite S(0,0) moves from south to north to the north latitude lat M When the position of a satellite in the system matches the position at the start of a time slot, all satellites in the system are synchronously set to the time slot and then start running.

[0055] If there is no increase or decrease in the number of satellites in the system and no permanent failure of the link occurs, the preset database will remain unchanged. If there is an increase or decrease in the number of satellites, or a permanent failure of the link occurs, the original link state message synchronization mechanism of OSPF can be used first to quickly complete rerouting by sending LSU messages. After that, it is necessary to recalculate the number of time slots and on-off information for the "orbital area" involved in the changed topology, rewrite the link state database, and update the preset link state database of all satellites in the "orbital area".

[0056] This invention utilizes a novel partitioning mechanism to remove limitations of the existing OSPF / OSPF+ protocol partitioning mechanism in large polar orbit satellite communication systems, significantly reducing routing recalculation overhead. By pre-setting and managing a link state database, unnecessary link state message transmission is eliminated, allowing inter-satellite link resources to be used more for data message transmission. This invention only addresses inter-satellite routing forwarding and does not specifically limit access between satellite and ground.

[0057] Beneficial effects: Compared with OSPF and OSPF+ protocols, the present invention can effectively reduce the computational and message overhead generated by the operation of OSPF / OSPF+ dynamic routing protocols in large polar orbit communication systems. Under the condition of limited onboard processor performance, the dynamic routing protocol can be effectively operated using fewer onboard computing resources. On the one hand, the present invention overcomes the limitations that may arise when the original OSPF / OSPF+ regional division mechanism is applied to large polar orbit constellations through the division of "orbital zones". When the original OSPF / OSPF+ regional division mechanism is applied to large polar orbit constellations, due to the constraints that "backbone areas must be logically continuous and non-backbone areas must be directly connected to the backbone areas", the regional scale cannot be effectively reduced. However, by introducing the "orbital zone" division, the present invention can reduce the increase in computational overhead when the number of satellites in the system increases significantly, thereby ensuring the overall performance of the system. When the number of satellites in the system increases significantly, the computing overhead can be reduced to ensure the overall performance of the system. On the other hand, any predictable link interruption and recovery will no longer be announced through LSU messages, which greatly reduces unnecessary notification message overhead, speeds up the routing re-convergence when predictable link interruption and recovery occur, and reduces unnecessary inter-satellite link resource usage. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 A flowchart for the overall implementation.

[0059] Figure 2 Build a schematic diagram for a polar orbiting constellation link.

[0060] Figure 3Schematic diagram of the "track area" division.

[0061] Figure 4 Schematic diagram of satellite link state transition.

[0062] Figure 5 This is a diagram of the neighbor state machine.

[0063] Figure 6 This is a schematic diagram of the interface state machine.

[0064] Figure 7 (a) Figure 7 (b) Figure 7 (c) are all schematic diagrams of "routing islands", which respectively show the situations where routing islands appear when the "track area" contains one, two, and three links.

[0065] Figure 8 Schematic diagram of IP address allocation.

[0066] Figure 9 (a) and Figure 9 (b) is a schematic diagram of the preset information of Router-LSA and AS-External-LSA. DETAILED DESCRIPTION

[0067] In order to better understand the technical content of the present invention, a specific embodiment is given and described as follows with reference to the accompanying drawings. The overall implementation process is as follows Figure 1 The link is established according to the typical scenario of the inter-satellite link of the polar orbit constellation described in the background. Figure 2 A schematic diagram of a simple polar orbiting constellation link is established, which can be abstracted into a mesh-like topology.

[0068] This invention utilizes a novel partitioning mechanism to overcome the limitations of the existing OSPF / OSPF+ protocol partitioning mechanism in large polar orbit satellite communication systems, significantly reducing routing recalculation overhead. By pre-setting and managing a link state database, it eliminates unnecessary link state message transmission, freeing up intersatellite link resources for data message transmission. Building upon the existing OSPF / OSPF+ protocol mechanism, this invention provides the following improvements:

[0069] (1) Divide the track area to reduce the routing computing resource overhead.

[0070] Change the original partitioning mechanism of the network and divide the entire space network into multiple "track areas". Each "track area" contains several tracks and is assigned a fixed IP network segment. For all links within the "track area", an independent IP subnet segment will be assigned under the "track area" network segment, such as Figure 3 shown.

[0071] Routing information within a track area is calculated using Router-LSAs, the first type of LSAs defined by the OSPF protocol, generated by each node within the area. Routing information outside the track area is calculated using AS-External-LSAs, the fifth type of LSAs defined by the OSPF protocol, generated by nodes at the edge of the track area. At the same time, nodes at the edge of the track area and adjacent nodes in another track area will send Hello messages to each other to detect the validity of the inter-track link between them. If either node detects that the link has failed, it will broadcast a fifth type of LSA via an LSU message to notify the remaining nodes within its respective track area.

[0072] (2) Pre-set the link state database to reduce unnecessary message sending.

[0073] The entire orbital cycle of satellites within the system is divided into several time slots. During each time slot, unless an unexpected failure occurs, the connectivity between satellites within the entire system remains stable. However, when a time slot switches, links within the entire system must undergo predictable connectivity changes, and routing switches must occur simultaneously. For specific polar orbiting constellation scenarios, the number of time slots and switching intervals must be determined based on the topology and link planning of the polar orbiting constellation in which the protocol is actually running.

[0074] A link state database is pre-set for each track zone, and all nodes within that zone maintain this database. This pre-set database contains Type I and Type V LSA information for all nodes within that track zone throughout its entire operating cycle, along with information about the connectivity and disconnection of all links within that zone during all time slots. When a time slot switch occurs, if a node detects through Hello messages that the status of all its connected links after the time slot switch matches the pre-set information, it will not send an LSU message, even if the connectivity of its adjacent links changes. This means that any predictable link disruption or recovery will no longer be communicated via LSU messages, and each node will autonomously calculate the route after the time slot switch. However, if a node detects an unpredictable link disruption, it will notify the other nodes within its track zone via an LSU message. If the link recovers after a period of time, it will also notify the other nodes via an LSU message.

[0075] When a time slot switch occurs, all nodes must also manage their own link state databases. LSAs related to unpredictable link outages, obtained via LSU messages, do not carry time slot information, making them easily distinguishable from pre-set LSAs. For LSAs that have been restored to be consistent with the pre-set information, the original pre-set LSAs with time slot information are restored. For LSAs that are still inconsistent with the pre-set information, check whether any of them involve links that will be disconnected in the next time slot. If so, label them so that they do not participate in the shortest path calculation for the next time slot. After management is completed, route recalculation is performed to adapt to the topology within the new time slot.

[0076] (3) Added link "test status" to ensure link connection reliability.

[0077] Due to the relatively harsh communication environment in space, satellite nodes are unable to accurately establish links at the preset time points. For this reason, a new "test state" is added to the original OSPF+ neighbor state machine on the basis of adding the "leave state". Regardless of whether a link is located within the "orbital area" or between "orbital areas", the link and the neighbor corresponding to the link have four deterministic states: connected, left, tested, and closed. Each node will independently set up a neighbor state machine for all its adjacent neighbor nodes, and each neighbor node will have a corresponding link. During operation, for each node, the states of all its links and neighbor nodes are converted as described below:

[0078] For any node in the system, before starting operation, all its connected links and neighbors are placed in the "closed state". When entering the first time slot, it chooses to enter the "connected state" or "left state" according to the preset link connection and disconnection information.

[0079] If a link of a node is in the "connected state" and the link is disconnected in the next time slot, it will directly enter the "left state" after the time slot switch, and the disconnected link will no longer participate in the routing calculation.

[0080] If a link of a node is in the "Leave state" and is predicted to be converted to the "Connect state" in the next time slot, it will be advanced for a period of time T before the time slot switching occurs. Test (For example, 30s) to start trying to connect to the link, and send a message to the neighbor at the other end of the link at a certain time interval T Hello (For example, 3 seconds) to continue sending Hello packets, the link enters the "test state". Test It should be ensured that the link can be connected within the time without any accidents. At the same time, the latitude corresponding to the time point of connection completion should be reasonably designed to ensure that the link connection conditions are met when the connection starts. HelloThe selection should ensure that T Test A certain number of Hello packets can be sent within a certain time period to prevent misjudgment due to accidental packet loss. Hello and T Test It can be determined based on the actual on-board packet loss probability test results. The number of packets sent can ensure a certain degree of judgment accuracy. If the link between this node and the neighboring node is successfully connected in the "test state", no LSU message will be sent. The remaining nodes in the "orbital area" where the node is located will directly complete the calculation according to the LSA in the preset database. If T Test If a connection cannot be completed within the specified time slot, the node will notify the other nodes in the "track area" where the node is located through an LSU message. The other nodes will perform calculations based on the LSA contained in the received LSU message. At the same time, the neighbor state machine will remain in the "test state" and continue to detect whether the link is connected. Once the connection with the neighbor node at the other end of the link is completed, the LSU message will be used again to notify the other nodes that the link has returned to normal. If the link is still not connected within the entire time slot, then when the next time slot switch occurs, the link is considered to have temporarily failed, and the neighbor state machine will transition to the "closed state" to wait for the link to be repaired.

[0081] like Figure 4 The figure shows the link state transition diagram of a satellite when no abnormal failure occurs in the link. The neighbor state machine (NSM) and interface state machine (ISM) of the OSPF protocol are improved accordingly, and their schematic diagrams are shown as follows: Figure 5 、 Figure 6 As shown, the Down state is the closed state, and the Full and P2P states correspond to the neighbor connection state within the track area. The meanings of the newly added states are: in the neighbor state machine, NSM_Leaving (neighbor leaving the track area), NSM_Testing (neighbor connection testing within the track area), NSM_IOA (neighbor connection between track sections), NSM_IOA_Leaving (neighbor leaving the track section), NSM_IOA_Testing (neighbor testing between track sections); in the interface state machine, ISM_Leaving (link leaving the interface within the track area), ISM_Testing (link connection testing the interface within the track area), ISM_IOA (link connection between track sections), ISM_IOA_Leaving (link leaving the interface between track sections), ISM_IOA_Testing (link connection testing the interface between track sections).

[0082] For a satellite with a total number of N, a number of orbits of P, and a phase factor of F (i.e., the phase difference of satellites with the same number in adjacent orbits is For a polar-orbiting constellation (where F is an integer, 0 ≤ F ≤ P-1), the typical inter-satellite link establishment scenario is as follows: each satellite establishes links with two adjacent satellites in the same orbit, and also with satellites with the same number in adjacent orbital planes. No links are established at the reverse gap. When a satellite orbits above a certain latitude, the inter-orbit link is disconnected. If the link establishment for a polar-orbiting constellation meets these typical scenarios, the OSPF protocol can be configured according to the following five steps. If a satellite's position deviates from the ideal constellation, but this deviation does not affect its connectivity with other satellites or ground nodes at all times, the actual constellation satellite position can be mapped to its ideal position, and the improved OSPF protocol can be deployed according to the following steps.

[0083] For the sake of convenience, it is assumed that the satellites in the system are represented by S(i,j)(0≤i≤P-1,0≤j≤n-1), where i represents the orbit number and j represents the satellite number in the orbit. The latitude where the satellite link is disconnected is recorded as lat M , the number of satellites in a single orbit is recorded as n, then nP=N.

[0084] Step 1: Determine the number of time slots m.

[0085] The satellite operation cycle of the entire system is divided into several time slots. During each time slot, if no unexpected failures occur, the connectivity between satellites in the entire system remains stable. However, when a time slot switch occurs, links in the entire system must undergo predictable connectivity changes, and routing switches must be performed simultaneously. Therefore, the total number of routing switches that occur during the orbital cycle of a polar-orbiting satellite communication constellation is the number of time slots, m.

[0086] In order to conveniently obtain the value of m, considering that the topology of the polar orbit constellation is repetitive, it is first necessary to determine the minimum number of orbits k that causes the topology to repeat. The meaning of k is, let i = 0, observe the connection relationship between the satellites in the i-th orbit and the i+1-th orbit, and i increases from 0 to P-2. After k orbits, the connection relationship between satellites at the same latitude may be completely repeated, that is, the connection between the satellites on orbit k and orbit k+1 is exactly the same as the connection relationship between the satellites at the corresponding latitudes on orbits 0 and 1 at any time. The value of k is calculated by formula (1):

[0087]

[0088] The number of time slots is then calculated as follows:

[0089] (1) If kn is an even number, then When it is an integer, m=kn, otherwise m=2kn;

[0090] (2) If kn is an odd number, then When is an integer, m=2kn, otherwise m=4kn.

[0091] Step 2: Determine the on / off status of all links in each time slot.

[0092] (1) Assume that the satellite S(0,0) is located at latitude lat M At this point, the latitudes of the satellites at both ends of all inter-orbit links are calculated as the initial latitude values, and the current time slot value is recorded as 0. Based on the latitude values ​​of the satellites at both ends of each link, it is determined whether it is in a connected or disconnected state.

[0093] (2) Assume that the direction of the track is: at time slot 0, S(0,0) is moving from south to north. Find the link closest to the switch in the current time slot (if there are multiple links, you can choose any one), and calculate the latitude lat that needs to be turned from this link to switch. add , then the time slot value is increased by 1, and all satellites are calculated to rotate through the latitude lat according to the direction of operation add The latitude values ​​at both ends of the link are then determined to be connected or disconnected.

[0094] (3) Repeat step (2) until the satellite S(0,0) completes one orbit around the earth. At this time, the time slot value should increase to m-1, and the on-off status of all links in each time slot has been calculated. At the same time, since the latitude lat add It has been calculated, and the angular velocity of the satellite is known, so the switching time interval will also be determined accordingly.

[0095] Step 3: Divide the track area.

[0096] Determine the number of tracks in each "track area" and divide the "track area".

[0097] First, let's explain the situation of "routing islands". Figure 7 (a), Figure 7 (b), Figure 7 Figure (c) shows the occurrence of routing islands when the track area contains one, two, and three links, respectively. The gray and black nodes cannot be routed normally. This shows that when the number of tracks in the track area is large, more link interruptions are required to produce routing islands. When the track area contains only one track, routing islands are more likely to occur.

[0098] If you want to minimize the time required for route calculation, you can divide the "track area" as follows:

[0099] Assume that each “track zone” has x tracks, where x is a positive integer and x ≥ 2 (when x is 1, routing islands are likely to occur, so this is not considered). Then the number of track zones in the entire system can be expressed as The number of nodes in each "track zone" can be expressed as nx.

[0100] If there are y Router-LSAs in the database, and priority queuing is used to calculate the shortest path, the route calculation time can be expressed as:

[0101] T1(y)=aylog2y+by+c (where a, b, c are fixed parameters) (2)

[0102] If there are y AS-External-LSAs in the database, the route calculation time can be expressed as:

[0103] T2(y)=dy+e (where d and e are fixed parameters) (3)

[0104] The parameters a, b, c, d, and e can be determined as follows: Test the protocol's route calculation module by varying the number of Router-LSAs and AS-External-LSAs and measuring the route calculation time. After performing multiple measurements, use statistical regression to determine the values ​​of a, b, c, d, and e.

[0105] The total calculation time T(x) can be expressed as:

[0106]

[0107] The derivative is

[0108]

[0109] Therefore, T′(x) is monotonically increasing and can be divided into the following cases:

[0110] (1) When T′(2)≤0, there exists x0∈[2,+∞) such that T′(x0)=0. At this point, the routing calculation time reaches its minimum, and x0 can be numerically solved using a computer. Generally speaking, if x0 is not an integer, x1 is the largest integer not greater than x0, and x2 is the smallest integer not less than x0. If T(x1)≤T(x2), then x1 is the optimal value; otherwise, x2 is the optimal value.

[0111] (2) When T′(2)>0, there is no x0∈[2,+∞) such that T′(x0)=0, so the number of tracks with the shortest routing calculation time is 2.

[0112] Get the number of tracks x in a single "track zone" that minimizes the routing calculation timeBest After that, you can divide the "track area". Just start from track 0 and divide x Best Each track can be divided into a "track area". When it is not an integer, if the remainder is 1, the last track will be merged into the last "track area". If the remainder is greater than or equal to 2, the unallocated track at the end will be divided into a separate "track area".

[0113] Step 4: Allocate IP addresses and write out the pre-configured link state database.

[0114] After the "track area" is divided, each "track area" is assigned an independent network segment. The subnet mask length of this network segment must ensure that each link in it can be allocated a subnet segment under the "track area" network segment. The subnet mask length of the link subnet segment is up to 30. At the same time, the link between two "track areas" must also be assigned an independent IP network segment.

[0115] Figure 3 In the figure, a simple example of network segment allocation is given. The constellation is divided into n "orbital areas", denoted as OA i (0≤i≤n-1). OA i is assigned the network segment 10.i.0.0 / 16, and all links within it should be assigned a sub-segment under this network segment. The link connecting OA i and OA i+1 is assigned the network segment 10.128+i.0.0 / 16. For example Figure 8 In the link<S(0,0),S(0,1)> and Link<S(1,0),S(2,0)> Both are located inside OA i, under the network segment 10.0.0.0 / 16, and the subnet segments 10.0.0.8 / 30 and 10.0.0.4 / 30 are allocated to these two links respectively; and the link<S(2,0),S(3,0)> 、<S(2,1),S(3,1)> Both are located between OA 0 and OA 1, and are therefore assigned subnets 10.128.0.0 / 30 and 10.128.0.4 / 30 under network segment 10.128.0.0 / 16.

[0116] For each "track zone", based on the above network segment allocation and link connectivity calculation, its link state database is directly written. During operation, all nodes within each "track zone" will load the same preset link state database. The specific writing method is:

[0117] (1) Each node needs to generate a Router-LSA, which will contain the IP address information of all links within the "track area" to which the node is connected. For nodes within the "track area", it should contain the IP address information of the four links to which it is connected. For nodes at the edge of the "track area", it should contain the IP address information of the three nodes within the "track area" to which it is connected. At the same time, since the "track area" division has been adopted, there is no need to use the original OSPF area division method. Therefore, all network segments within the "track area" are declared to be located in the backbone area.

[0118] (2) For each "track area" boundary node, one AS-External-LSA should be generated for each network segment of the remaining "track areas" to which it leads. Specifically, a boundary node located on the left side of a "track area" needs to generate one AS-External-LSA for each network segment of the "track area" on its left side. For a boundary node located on the right side of a "track area", one AS-External-LSA should be generated for each network segment of the "track area" on its right side.

[0119] (3) All Router-LSAs and AS-External-LSAs must be accompanied by time slot information. The number of time slots is calculated according to step 2, and the on / off information is calculated according to step 3.

[0120] like Figure 9 (a) and Figure 9 As shown in (b), they are examples of Router-LSA and AS-External preset information. In the time slot information matrix, "0" indicates that the link is available in the time slot, and "1" indicates that it is unavailable. Figure 9 As shown in (a), the Router-LSA contains four links. Note that in the Router-LSA, for each intersatellite link configured as a point-to-point link type, two link information will be included, one of which is point-to-point (P2P) and the other is stub. Each border node needs to generate an AS-External-LSA for each external network segment it declares. The AS-External-LSAs advertised by the same router only need to share a link connectivity matrix, which contains only one link, namely the link connecting the border node of the "orbital area" to another "orbital area", as shown in Figure 1. Figure 9 As shown in (b).

[0121] Step 5: Load the pre-set link state database, align the time slots, and run the protocol.

[0122] When the protocol is run on a satellite, the link state database of the "orbital zone" to which it belongs is loaded first. When the satellite S(0,0) moves from south to north to the north latitude lat M When the position of a satellite in the system matches the position at the start of a time slot, all satellites in the system are synchronously set to the time slot and then start running.

[0123] If there is no increase or decrease in the number of satellites in the system and no permanent failure of the link occurs, the preset database will remain unchanged. If there is an increase or decrease in the number of satellites, or a permanent failure of the link occurs, the original link state message synchronization mechanism of OSPF can be used first to quickly complete rerouting by sending LSU messages. After that, it is necessary to recalculate the number of time slots and on-off information for the "orbital area" involved in the changed topology, rewrite the link state database, and update the preset link state database of all satellites in the "orbital area".

[0124] The above describes in detail the improved OSPF protocol method for large-scale polar orbiting constellations, which aims to reduce the operating overhead of OSPF / OSPF+ protocols in large polar orbiting constellations. The performance improvements are primarily reflected in the following two aspects: First, by dividing the OSPF / OSPF+ region into "orbital zones," the present invention overcomes the limitations of the existing OSPF / OSPF+ region division mechanism when applied to large polar orbiting constellations. This minimizes the increase in computational overhead when the number of constellation orbits increases significantly, ensuring overall system performance. Second, when a link is predictably interrupted or restored, LSU messages are no longer used for notification, significantly reducing unnecessary notification message overhead and accelerating route reconvergence when a predictable link interruption or restoration occurs. These two performance improvements effectively reduce the computational and message overhead of OSPF / OSPF+ dynamic routing protocols in large polar orbiting constellations, enabling efficient operation of dynamic routing protocols despite limited onboard processor performance and link bandwidth resources.

[0125] The above embodiments are only intended to help understand the core concept of the present invention. For those skilled in the art, according to the concept of the present invention, when applying the present invention to actual constellations, the specific implementation methods may vary. The scope of protection of the present invention shall be determined by the claims.

Claims

1. A low-overhead OSPF protocol improvement method for large-scale polar orbit constellations, characterized in that: Based on the original mechanism of OSPF / OSPF+ protocol, the improvement steps are as follows: (1) Divide the track area to reduce the routing computing resource overhead; The original network partitioning mechanism is changed, and the entire spatial network is divided into multiple "track zones". Each "track zone" contains several tracks and is assigned a fixed IP network segment. For all links within the "track zone", an independent IP subnet segment will be assigned under the "track zone" network segment. Routing information within a track area is calculated using the first type of LSAs (Router-LSAs) defined by the OSPF protocol, generated by each node within the area. Routing information outside the track area is calculated using the fifth type of LSAs (AS-External-LSAs) defined by the OSPF protocol, generated by the boundary nodes of the track area. At the same time, the boundary nodes of a track area and the adjacent nodes of another track area will send Hello messages to each other to detect whether the link between the two nodes is valid. Once any node finds that the link is invalid, it will broadcast the fifth type of LSA via an LSU message to notify the other nodes within its own track area. (2) Pre-set link state database to reduce unnecessary message sending; The entire orbital cycle of satellites in the system is divided into several time slots. During each time slot, unless an unexpected failure occurs, the connection between satellites in the entire system remains stable. However, when a time slot switches, links in the entire system must undergo predictable connectivity changes, and routing switches are performed simultaneously. For specific polar orbit constellation scenarios, the number of time slots and switching intervals need to be determined based on the topology and link planning of the polar orbit constellation in which the protocol is actually running. A link state database is pre-set for each track zone, and all nodes within the zone maintain this database. The pre-set database contains information about Type I and Type V LSAs for all nodes within the zone throughout its entire operating cycle, along with information about the connectivity and disconnection of all links within the zone during all time slots. When a time slot switch occurs, if a node detects through a Hello message that the status of all its connected links after the time slot switch matches the pre-set information, it will not send an LSU message, even if the connectivity of its adjacent links changes. This means that any predictable link disruption or recovery will no longer be notified via an LSU message, and each node can autonomously calculate the route after the time slot switch. However, if a node detects an unpredictable link disruption, it will notify the other nodes within its zone via an LSU message. If the link recovers after a period of time, it will also notify the other nodes via an LSU message. When a time slot switch occurs, all nodes should also manage their own link state databases. LSAs related to unpredictable link interruptions are obtained through LSU messages and do not carry time slot information, making them easy to distinguish from pre-set LSAs. For LSAs that have been restored to be consistent with the pre-set information, the original pre-set LSAs with time slot information are restored. For LSAs that are still inconsistent with the pre-set information, check whether there are links that will be disconnected in the next time slot. If so, label them so that they do not participate in the shortest path calculation in the next time slot. After the management is completed, the route is recalculated to adapt to the topology in the new time slot. (3) Added link "test status" to ensure link connection reliability; In addition to the "Leaving State" added to the existing OSPF+ neighbor state machine, a new "Testing State" has been added. Regardless of whether a link is within or between "track zones," the link and its corresponding neighbor have four deterministic states: Connected, Leaving, Testing, and Down. Each node has a separate neighbor state machine for all of its neighboring nodes, and each neighbor node has a corresponding link. During operation, for each node, the states of all its links and neighbor nodes transition as described below: Before any node in the system starts running, it sets all its connected links and neighbors to the "Closed State". When entering the first time slot, it chooses to enter the "Connected State" or "Leaving State" based on the preset link connection and disconnection information. If a link of a node is in the "connected state" and the link is disconnected in the next time slot, it will directly enter the "left state" after the time slot switch, and the disconnected link will no longer participate in the routing calculation; If a link of a node is in the "Leave state" and is predicted to be converted to the "Connect state" in the next time slot, it will be advanced for a period of time T before the time slot switching occurs. Test Start trying to connect the link, T Test The selection should ensure that it is greater than the minimum time of the link connection, and the neighbor at the other end of the link should be notified at a certain time interval T Hello Continue to send Hello packets, and the link enters the "test state"; the time T Test It should be ensured that the link can be connected within this time without any accidents. At the same time, the latitude corresponding to the time point of connection completion should be reasonably designed to ensure that the link connection conditions are met when the connection starts; T Hello The selection should ensure that T Test A certain number of Hello packets can be sent within a certain time period to prevent misjudgment due to accidental packet loss. Hello and T Test The determination is based on the actual on-board packet loss probability test results. The number of packets sent is sufficient to ensure a certain degree of judgment accuracy. If the link between this node and its neighboring node is successfully connected in the "test state", no LSU message is sent. The remaining nodes in the "orbital area" where the node is located will directly complete the calculation according to the LSA in the preset database. If T Test If the connection cannot be completed within the time slot, the node will notify the other nodes in the "track area" where the node is located through the LSU message. The other nodes will perform calculations based on the LSA contained in the received LSU message. At the same time, the neighbor state machine remains in the "test state" and continues to detect whether the link is connected. Once the connection with the neighbor node at the other end of the link is completed, the LSU message will be used again to notify the other nodes that the link has returned to normal. If the link is still not connected within the entire time slot, then when the next time slot switch occurs, the link is considered to have temporarily failed, and the neighbor state machine will change to the "closed state" to wait for the link to be repaired.

2. The low-overhead OSPF protocol improvement method for large-scale polar orbit constellations according to claim 1 is characterized in that: The configuration and deployment methods are as follows: For a polar orbit constellation with a total number of satellites N, a number of orbits P, and a phase factor F, the phase difference between satellites with the same number in adjacent orbits is 0≤F≤P-1, where F is an integer. A typical inter-satellite link establishment scenario is that each satellite establishes links with two adjacent satellites in the same orbit, and also with satellites with the same number in adjacent orbital planes. No links are established at the reverse seam. When a satellite orbits above a certain latitude, the inter-orbit link is disconnected. If the link establishment for a polar orbit constellation meets the above typical scenarios, the OSPF protocol can be configured according to the following five steps. If a satellite's position deviates from the ideal constellation, but this deviation does not affect its connectivity with other satellites or ground nodes at all times, the actual constellation satellite position can be mapped to its ideal position, and the improved OSPF protocol can be deployed according to the following steps. Satellites in the system are represented by S(i,j), 0≤i≤P-1, 0≤j≤n-1, where i represents the orbit number, j represents the satellite number in the orbit, and the latitude where the satellite link is disconnected is recorded as lat M , the number of satellites in a single orbit is recorded as n, then nP=N; Step 1: Determine the number of time slots m; The satellite operation cycle of the entire system is divided into several time slots. In each time slot, if there is no unexpected failure, the connection relationship between satellites in the entire system remains stable. However, when a time slot switch occurs, the links in the entire system must undergo predictable on-off changes and route switching. Therefore, the total number of route switches that occur during the orbital cycle of a polar orbiting satellite communication constellation is the number of time slots m. In order to conveniently obtain the value of m, considering that the topology of the polar orbit constellation is repetitive, it is first necessary to determine the minimum number of orbits k that causes the topology to repeat. The meaning of k is that, let i = 0, observe the connection relationship between the satellites in the i-th orbit and the i+1-th orbit, and i increases from 0 to P-2. After k orbits, the connection relationship between satellites at the same latitude may be completely repeated, that is, the connection between the satellites in orbit k and orbit k+1 is exactly the same as the connection relationship between the satellites at the corresponding latitudes in orbit 0 and orbit 1 at any time. The value of k is calculated by formula (1): The number of time slots is then calculated as follows: (1) If kn is an even number, then When it is an integer, m=kn, otherwise m=2kn; (2) If kn is an odd number, then or When it is an integer, m=2kn, otherwise m=4kn; Step 2: Determine the on / off status of all links in each time slot; (1) Assume that the satellite S(0,0) is located at latitude lat M Calculate the latitudes of the satellites at both ends of all inter-orbit links at this time as the initial latitude values, and record the current time slot value as 0; determine whether it is connected or disconnected based on the latitude values ​​of the satellites at both ends of each link; (2) Assume that the direction of the track is: at time slot 0, S(0,0) is moving from south to north; find the link closest to the switch in the current time slot. If there are multiple links, you can choose any one; and calculate the latitude lat that needs to be traveled to this link for the switch to occur. add , then the time slot value is increased by 1, and all satellites are calculated to rotate through the latitude lat according to the direction of operation add The latitude values ​​of both ends of the link are then determined to be connected or disconnected; (3) Repeat step (2) until the satellite S(0,0) completes one orbit around the earth. At this time, the time slot value should increase to m-1, and the on-off status of all links in each time slot has been calculated. At the same time, due to the latitude lat add It has been calculated, and the angular velocity of the satellite is known, so the switching time interval will also be determined; Step 3: Divide the "track area"; Determine the number of tracks in each "track zone" and divide the "track zone"; Step 4: Allocate IP addresses and write the pre-configured link state database; After completing the "track zone" division, assign an independent network segment to each "track zone". The subnet mask length of this network segment must ensure that each link in it can be allocated a subnet segment under the "track zone" network segment, and the maximum subnet mask length of the link subnet segment is 30. At the same time, the link between two "track zones" must also be assigned an independent IP network segment. For each "track zone", its link state database is directly written based on the above network segment allocation and link connectivity calculation. During operation, all nodes within each "track zone" will load the same preset link state database. Step 5: Load the pre-set link state database, align the time slots, and run the protocol; When the protocol is run on a satellite, the link state database of the "orbital zone" to which it belongs is first loaded; there are two cases for setting the time slot: First, when the satellite S(0,0) moves from south to north to the north latitude lat M When the time slot is equal to the starting time slot, all satellites in the system are synchronously set to the time slot and start running.

3. The low-overhead OSPF protocol improvement method for large-scale polar orbit constellations according to claim 1 is characterized in that: Specific steps for dividing the "track area": Assume that each "track zone" has x tracks, x is a positive integer and x ≥ 2, the number of track zones in the entire system is expressed as The number of nodes in each "track zone" is represented as nx; If there are y Router-LSAs in the database and priority queuing is used to calculate the shortest path, the route calculation time is expressed as: T1(y)=aylog2y+by+c, where a, b, and c are fixed parameters (2) If there are y AS-External-LSAs in the database, the route calculation time is expressed as: T2(y)=dy+e, where d and e are fixed parameters (3) The parameters a, b, c, d, and e are determined as follows: The protocol's route calculation module is tested by varying the number of Router-LSAs and AS-External-LSAs and measuring the route calculation time. After performing multiple measurements, statistical regression is used to determine the values ​​of a, b, c, d, and e. The total calculation time T(x) is expressed as: The derivative is Therefore, T ′ (x) is monotonically increasing and can be divided into the following cases: (1) When T ′ (2)≤0, there exists x0∈[2,+∞) such that T ′ (x0) = 0, at this time the routing calculation time reaches the minimum value, x0 can be numerically solved by computer; x0 is not an integer, x1 is the largest integer not greater than x0, and x2 is the smallest integer not less than x0; if T(x1) ≤ T(x2), then x1 is the optimal value, otherwise x2 is the optimal value; (2) When T ′ (2)>0, there does not exist x0∈[2,+∞) such that T ′ (x0) = 0, so the number of tracks that minimizes the routing calculation time is 2; Get the number of tracks x in a single "track zone" that minimizes the routing calculation time Best After that, you can divide the "track area". Just start from track 0 and divide x Best Each track can be divided into a "track area"; when When it is not an integer, if the remainder is 1, the last track will be merged into the last "track area". If the remainder is greater than or equal to 2, the unallocated track at the end will be divided into a separate "track area".

4. The low-overhead OSPF protocol improvement method for large-scale polar orbit constellations according to claim 1 is characterized in that: If there is no increase or decrease in the number of satellites in the system and no permanent failure of the link occurs, the preset database will remain unchanged. If there is an increase or decrease in the number of satellites, or if there is a permanent failure of the link, the original link state message synchronization mechanism of OSPF is first used to quickly complete rerouting by sending LSU messages. After that, it is necessary to recalculate the number of time slots and on-off information for the "orbital area" involved in the changed topology, rewrite the link state database, and update the preset link state database of all satellites in the "orbital area".

Images