Routing for non-geostationary orbit (NGSO) satellite systems.

Abstract

To provide a non-geostationary satellite orbit (NGSO) satellite system and a method for routing data traffic in the NGSO satellite system.SOLUTION: In the NGSO satellite system, user route tables track connectivity of users to satellites, and each of the backbone route tables defines a snapshot of a time-varying backbone spatial arrangement seen by a particular satellite. During operation, an NGSO satellite 102 selects different backbone route tables as the spatial arrangement changes over time, and receives updates of the user route tables when the connectivity between the users and the satellites changes.EFFECT: Since the backbone route tables are calculated in advance and the NGSO satellite system is subsequently tasked with a computationally lower burden of performing real-time updates of the user route tables, the user route tables are decoupled from the backbone route tables, and the computational burden on the NGSO satellite system is reduced.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to the field of routing in satellite systems. In particular, the present disclosure relates to routing data traffic in NGSO satellite systems. [Background technology]

[0002] NGSO systems utilize a constellation of satellites in low Earth orbit (LEO) and / or medium Earth orbit (MEO), which sweep across the Earth's surface as they orbit the Earth. This is in contrast to satellites in geostationary Earth orbit (GEO), which are stationary relative to the Earth's surface as they orbit the Earth.

[0003] Due to their relative motion with respect to the Earth's surface, NGSO satellite systems are subject to more terrestrial antenna handovers than GEO satellite systems. Furthermore, unlike handovers (e.g., beam handovers) in GEO satellite systems that are caused by mobile terminal mobility, NGSO satellite systems are tasked with supporting multiple types of handovers, including intra-orbit handovers (due to the motion of satellites relative to one another in the same orbital plane), inter-orbit handovers (due to the motion of satellites relative to one another in different orbital planes), link handovers (due to link outages, which may be due to node and / or link failures), and beam handovers (due to satellite motion, Earth rotation, and / or mobile terminal mobility).

[0004] Current solutions for routing in NGSO satellite systems use Internet Protocol (IP) routers onboard the satellites to implement link state routing. Using this approach, a management system constantly calculates and updates routing information in real time for the entire satellite network when handover events occur. This type of solution does not scale well to NGSO satellite systems that utilize many satellites as the NGSO satellite systems undergo more handovers due to their non-geostationary orbits relative to the Earth's surface, and also due to their relative motion relative to one another. Furthermore, this type of solution can fail, even temporarily, when the NGSO satellite systems are no longer able to perform the real-time calculations that they rely on for updating routing information. Summary of the Invention

[0005] An NGSO satellite system is described that implements one or more user route tables and multiple pre-computed backbone route tables on multiple satellites of the NGSO satellite system. The user route tables track user connectivity to the satellites in the NGSO system, and each of the backbone route tables defines a snapshot of the time-varying backbone topology seen by a particular satellite. During operation, the satellites select different backbone route tables as the topology changes over time and perform updates to the user route tables when changes in user-satellite connectivity occur. The separation of the user route tables from the backbone route tables on the satellites reduces the computational load on the NGSO system because the backbone route tables have been previously calculated and the NGSO system is subsequently tasked with the lower computational load of performing real-time updates to the user route tables. Additionally, the separation of the user route tables from the backbone route tables reduces the amount of real-time information exchanged between the satellites and ground assets in the NGSO satellite system.

[0006] One embodiment includes a method operable by a satellite of a NGSO system, the method including receiving from a ground controller a plurality of backbone route tables, each of which defines a snapshot of a time-varying backbone spatial arrangement of the NGSO system, receiving from the ground controller one or more user route tables, the user route tables identifying connectivity of users to satellites in the NGSO system, and receiving a data packet for routing in the NGSO system. The method further includes determining whether the data packet is destined for a first user directly connected to another satellite in the NGSO system based on the user route table. In response to determining that the data packet is destined for the first user, the method further includes identifying another satellite based on the user route table, identifying an active backbone route table from the plurality of backbone route tables, and forwarding the data packet to the other satellite based on the active backbone route table. The method further includes determining, based on the user route table, whether the data packet is destined for a second user directly connected to the satellite, and, in response to determining that the data packet is destined for the second user, transmitting the data packet to the second user via a user link maintained by the satellite.

[0007] Another embodiment includes a non-transitory computer-readable medium having programmed instructions embodied therein that, when executed by one or more processors of a satellite in a non-geostationary satellite orbit (NGSO) system, direct the satellite to receive from a ground controller a plurality of backbone route tables, each of which defines a snapshot of a time-varying backbone spatial configuration of the NGSO system, receive from the ground controller one or more user route tables, the user route tables identifying connectivity of users to satellites in the NGSO system, and receive a data packet for routing in the NGSO system. The instructions further direct the one or more processors to determine, based on the user route table, whether the data packet is destined for a first user directly connected to another satellite in the NGSO system. In response to determining that the data packet is destined for the first user, the instructions further direct the one or more processors to identify another satellite based on the user route table, identify an active backbone route table from the plurality of backbone route tables, and forward the data packet to the another satellite based on the active backbone route table. The instructions further direct the one or more processors to determine whether the data packet is destined for a second user directly connected to the satellite based on the user route table. In response to determining that the data packet is destined for the second user, the instructions further direct the one or more processors to transmit the data packet to the second user via a user link maintained by the satellite.

[0008] Another embodiment includes an NGSO system including a satellite. The satellite includes a memory that stores a plurality of backbone route tables received from a ground controller, each of the backbone route tables defining a snapshot of a time-varying backbone spatial arrangement of the NGSO system, and one or more user route tables received from the ground controller, the user route tables specifying user connectivity to the satellite in the NGSO system. The satellite includes a communication system that implements at least one of a user link with a user of the NGSO system, an intra-orbit link with another satellite in the NGSO system that shares a common orbital plane with the satellite, and an inter-orbit link with another satellite in the NGSO system that is in a different orbital plane than the satellite. The satellite further includes at least one processor that receives a data packet for routing in the NGSO system and determines whether the data packet is destined for a first user directly connected to another satellite in the NGSO system based on the user route table. The at least one processor, in response to determining that the data packet is destined for the first user, identifies another satellite based on the user route table, identifies an active backbone route table from the multiple backbone route tables, and forwards the data packet to the other satellite via an inter-orbital link or an intra-orbital link based on the active backbone route table. The at least one processor, in response to determining that the data packet is destined for the second user, determines whether the data packet is destined for a second user directly connected to the satellite based on the user route table, and transmits the data packet to the second user via a user link maintained by the satellite.

[0009] The above-described features, functions, and advantages can be realized alone in various embodiments or can be combined in yet further embodiments, which embodiments can be more fully understood by reference to the following description and accompanying drawings.

[0010] Some embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which the same reference numbers represent the same elements or the same types of elements, and in which: [Brief description of the drawings]

[0011] [Figure 1] 1 depicts a constellation of an NGSO satellite system in an exemplary embodiment. [Figure 2A] FIG. 2 is a block diagram of the satellite NGSO satellite system of FIG. 1 in an exemplary embodiment. [Figure 2B] FIG. 2 is a block diagram of a ground controller of the NGSO satellite system of FIG. 1 in an exemplary embodiment. [Diagram 3] 2 is a flow diagram of a method operable by a satellite of the satellite NGSO satellite system of FIG. 1 in an exemplary embodiment. [Figure 4] 2 is an implementation of satellite routing for the NGSO satellite system of FIG. 1 in an exemplary embodiment. [Diagram 5] 2 illustrates user route tables and backbone route tables for satellites of the NGSO satellite system of FIG. 1 in an exemplary embodiment. [Figure 6] 4 illustrates further details of the method of FIG. 3 in an exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] The drawings and the following description show specific exemplary embodiments. Those skilled in the art will recognize that various configurations embodying the principles described herein and falling within the contemplated scope of the claims that follow this description can be devised, even if not explicitly described or illustrated herein. Furthermore, any examples described herein should be construed as being intended to aid in the understanding of the principles of the disclosure, and not as being limiting. As a result, this disclosure is not limited to the specific embodiments or examples described below, but rather by the claims and their equivalents.

[0013] As discussed above, existing routing solutions for NGSO satellite systems rely heavily on real-time calculations and updates of satellite-mounted Internet Protocol (IP) routers during handover events, which occur more frequently in NGSO satellite systems compared to GEO satellite systems. FIG. 1 illustrates an NGSO satellite system constellation 100 in an exemplary embodiment. In this embodiment, the constellation 100 includes a plurality of NGSO satellites 102 arranged in orbital planes 108-109. The orbital planes 108-109 include MEO orbital planes, LEO orbital planes, or a combination of MEO and LEO orbital planes, in various embodiments. LEO satellites are typically found in circular orbits around the Earth between about 160 kilometers (km) and about 2,000 km above the Earth's surface, with an orbital period of about 90 minutes. MEO satellites are typically found in circular orbits around the Earth between 2,000 km and below the GEO level (e.g., 35,786 km), with an orbital period that varies from about 2 hours to nearly 24 hours.

[0014] Although constellation 100 depicts only satellites 102 in the LEO and MEO orbital planes, in other embodiments constellation 100 includes satellites in LEO / MEO as well as other satellites (not shown) in the GEO orbital plane. In constellation 100, satellites 102-1, 102-2, and 102-3 are in orbital plane 108, and satellites 102-4, 102-5, and 102-6 are in orbital plane 109.

[0015] In the spatial constellation 100, the intra-orbital links 110 allow the satellites 102 in the same orbital planes 108-109 to communicate with each other. Generally, the intra-orbital links 110 are fixed in time because the satellites 102 in the same orbital planes 108-109 typically do not change position relative to each other. Additionally, in this embodiment, the inter-orbital links 112 allow the satellites 102 in different orbital planes 108-109 to communicate with each other. The inter-orbital links 112 change in time because the satellites 102 in different orbital planes 108-109 move relative to each other. For example, if the orbital plane 109 is closer to the surface of the Earth than the orbital plane 108, the satellites 102 in the orbital plane 109 may move in the direction of the arrow 123 relative to the satellites 102 in the orbital plane 108 (e.g., the satellites 102 in the orbital plane 109 sweep across the surface of the Earth at a faster rate than the satellites 102 in the orbital plane 108). When this movement occurs, a handoff may occur for satellite 102-6 as satellite 102-6 changes its communications from satellite 102-2 to satellite 102-3. When the handoff occurs for satellite 102-6, inter-orbital link 112-4 may be created between satellite 102-6 and satellite 102-3, and inter-orbital link 112-3 may be terminated between satellite 102-6 and satellite 102-2.

[0016] Additionally, in this embodiment, satellite 102 communicates with users 114 via user links 118. In this embodiment, users 114-1 and 114-2 are depicted as mobile terminals (e.g., mobile satellite phones) and user 114-3 is depicted as a ground station (e.g., a fixed deployment facility). However, the number and types of users 114 may differ in other embodiments.

[0017] As mobile users 114 (e.g., users 114-1 and 114-2) move across the surface of the Earth and / or as satellites 102 move relative to users 114 over time, user link 118 changes over time. For example, if satellites 102 in orbital planes 108-109 move in the directions of arrows 122-123 relative to the surface of the Earth, user 114-3 may be handed off from satellite 102-3 to satellite 102-6. In this embodiment, user link 118-5 may be created between user 114-3 and satellite 102-6, and user link 118-3 between user 114-3 and satellite 102-3 may be terminated. In another embodiment, user 114-2 may be handed off from satellite 102-2 to satellite 102-5. In this example, user link 118-4 may be created between user 114-2 and satellite 102-5, and user link 118-2 between user 114-2 and satellite 102-2 may be terminated.

[0018] In conventional NGSO architectures, either time-varying changes in the NGSO spatial constellation or time-varying changes in users' connectivity to NGSO satellites generate real-time updates to the IP routing tables used by the NGSO satellites. The spatial constellation changes then require ground assets to both calculate new backbone routing strategies based on the orbital mechanics of the NGSO satellites and upload the backbone routing changes to the NGSO satellites. This type of real-time update generates significant computational overhead in the NGSO satellite system and real-time data updates between the ground assets and the satellites in the NGSO satellite system, and does not scale well as the number of NGSO satellites increases due to the increased complexity of the time-varying spatial constellation. Furthermore, partial or complete failures can occur in the system when partial system outages occur and real-time updates are not distributed to the NGSO satellites. When this happens, the NGSO satellites move out of position relative to each other and their inter-orbit and / or intra-orbit communication links are lost.

[0019] In the embodiment described herein, the time-varying changes of the backbone route table in the spatial arrangement 100 and the time-varying changes of the user route table in the spatial arrangement 100 are separated from each other using separate routing tables on board the satellites 102. Furthermore, the time-varying changes of the backbone route table in the spatial arrangement 100 are pre-computed by the ground controller 120 of the spatial arrangement 100, uploaded to the satellites 102, and selected by the satellites 102 at various points in time. As the spatial arrangement 100 changes over time, the satellites 102 utilize different backbone route tables (e.g., as instructed by the ground controller 120). As the user route table in the spatial arrangement 100 changes over time (e.g., as a user 114 is handed off from one satellite 102 to another satellite 102), the ground controller 120 updates the user route table of the satellite 102 independently of the backbone route table, which reduces the real-time information exchanged between the satellites 102 and the ground controller 120. In particular, technical benefits are achieved that allow ground controller 120 to manage a larger number of NGSO satellites than traditional NGSO systems, because the real-time nature of computing backbone connectivity changes for spatial constellation 100 is reduced or eliminated. Furthermore, a momentary loss in communication between a satellite 102 and ground controller 120 does not immediately result in a failure in spatial constellation 100 as in traditional NGSO systems, because satellites 102 continue to adapt to changes in backbone connectivity over time using their pre-computed backbone route tables that are stored locally at each satellite 102.

[0020] In some embodiments, the ground controller 120 comprises a software deterministic network (SDN) architecture. In these embodiments, spatial constellation and traffic engineering intelligence and algorithms are instantiated as SDN applications running on the ground controller 120. The ground controller 120 manages the satellites 102 using a priori knowledge of the movement of the satellites 102 in the orbital planes 108-109. In some embodiments, the SDN control plane is used to configure routing tables for the satellites 102. In these embodiments, the ground controller 120 manages the user 114 connectivity paths and the spatial constellation 100 connectivity paths in addition to the inter-orbital links 112. The ground controller 120 knows a priori when the inter-orbital satellites 102 have overlapping views of each other (e.g., when the view of satellite 102-2 overlaps with satellite 102-6). The ground controller 120 also optimizes the backbone path for the constellation 100 and makes decisions regarding which inter-orbital links 112 should be created and terminated (e.g., by creating inter-orbital link 112-4 and terminating inter-orbital link 112-3 as satellite 102-6 moves out of view of satellite 102-2 and into view of satellite 102-3).

[0021] In some embodiments, the ground controller 120 manages handover requests between the user 114 and the satellite 102. In one such embodiment, the ground controller 120 uses a mobility management SDN application running on the ground controller 120 to update a user routing table onboard the satellite 102 in real time in response to user link 118 handovers (e.g., the user route table is based on real-time connectivity changes between the user 114 and the satellite 102) to manage handover requests for the user 114. In other embodiments, the ground controller 120 utilizes a priori knowledge of predicted handoff events between the user 114 and the satellite 102 to pre-compute and upload the user route table to the satellite 102 (e.g., the user route table is based on predicted connectivity changes between the user 114 and the satellite 102). Using the pre-computed user route table, the satellite 102 can operate autonomously with respect to handovers between the user 114 and the satellite 102 when a temporary loss of communication occurs between the satellite 102 and the ground controller 120.

[0022] In this embodiment, satellites 102 comprise any combination of hardware and / or software that provides in-orbit communications capabilities to users 114 and other satellites 102, including providing user link 118 communications capabilities, in-orbit link 110 communications capabilities, and inter-orbit link 112 communications capabilities.

[0023] 2A is a block diagram of a satellite 102 according to an example embodiment. In this embodiment, the satellite 102 includes, without limitation, one or more processors 202 that execute software instructions, memory 204, a power system 206, a propulsion system 208, a communication system 210, and one or more switches / routers 214. The processor 202 (and any other processors described herein) includes any hardware device capable of performing the functions described for the satellite 102. The processor 202 (and any other processors described herein) may include one or more central processing units (CPUs), microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), and the like. Some examples of processors include INTEL® CORE™ processors, advanced reduced instruction set computing (RISK) machine (ARM®) processors, and the like.

[0024] Memory 204 (and any other memory devices described herein) includes any hardware device capable of storing data. Memory 204 (and any other memory devices described herein) may include one or more volatile or non-volatile dynamic random access memory (DRAM) devices, flash devices, volatile or non-volatile static RAM devices, hard drives, solid state disks (SSDs), etc. Some examples of non-volatile DRAM and SRAM include battery-backed DRAM and battery-backed SRAM.

[0025] The power system 206 comprises any component, system, or device that stores and generates power for the satellite 102. Some examples of the power system 206 include batteries, solar panels, fuel cells, etc. The propulsion system 208 comprises any component, system, or device that provides in-orbit maneuvering capabilities for the satellite 102. The propulsion system 208 may comprise on-board fuel, rocket motors, ion thrusters, etc. The communication system 210 comprises any component, system, or device that enables the satellite 102 to communicate with each other via the in-orbit link 110 and the inter-orbital link 112, and with the user 114 via the user link 118. The communication system 210 may include a wireless communication system, an optical communication system, or a combination of wireless communication and optical communication systems. The switch / router 214 comprises any component, system, or device that provides packet routing capabilities for the satellite 102. Such packet routing functions include routing data packets received from satellites 102 to communications system 210 for data transmission via intra-orbital link 110 , inter-orbital link 112 , and user link 118 .

[0026] In this embodiment, the memory 204 stores one or more user route tables 216 and multiple backbone route tables 218. Typically, the user route table 216 and the backbone route table 218 are different for each satellite 102 in the spatial constellation 100. For each satellite 102, the user route table 216 may track which satellite 102 a user 114 is connected to. For example, if a user 114-2 is connected to the satellite 102-2 (e.g., via a user link 118-2), the user route table 216 for the satellite 102-2 may indicate that the user 114-2 is locally connected to the satellite 102-2 (e.g., via local routing information such as the currently active user link 118-2 and / or the egress port of the switch and / or router 214 associated with the user link 118-2). The user route tables 216 for other satellites 102 may indicate that the user 114-2 is not locally attached to that particular satellite 102. For example, the user route table 216 for a satellite 102-1 that is not locally connected to the user 114-2 may indicate an egress port associated with forwarding data to the user 114-2 (e.g., an egress port associated with the intra-orbital link 110-1 between the satellites 102-1 and 102-2). When the user 114 is handed off to a different satellite 102 in the spatial constellation 100, the ground controller 120 is responsible for calculating new user route tables 216 for each of the satellites 102 that indicate the change in connectivity for the user 114 and uploading the appropriate user route tables 216 to the satellites 102.

[0027] As mentioned above, the backbone route table 218 may be different for each satellite 102 because each of the satellites 102 can see a different portion of the spatial constellation 100. For example, satellite 102-4 sees a portion of the spatial constellation 100 that includes the intra-orbital link 110-3 with satellite 102-5 and the inter-orbital link 112-1 with satellite 102-1. Meanwhile, satellite 102-5 sees a portion of the spatial constellation 100 that includes the intra-orbital link 110-3 with satellite 102-4, the intra-orbital link 110-4 with satellite 102-6, and the inter-orbital link 112-2 with satellite 102-2. The ground controller 120 is responsible for pre-computing the backbone route table 218 and uploading the backbone route table 218 to the satellites 102. The ground controller 120 may also be responsible for instructing the satellite 102 which backbone route table 218 should be used at a particular point in time. For example, the ground controller 120 may instruct the satellite 102 to utilize backbone route table 218-1 during a first time period in the day, and subsequently instruct the satellite 102 to utilize backbone route table 218-2 during a second time period in the day.

[0028] In this embodiment, the ground controller 120 manages and communicates with the satellites 102 via a network 122 coupled to a user 114-3, shown in this embodiment as a ground station. FIG. 2B is a block diagram of the ground controller 120 in an example embodiment. In this embodiment, the ground controller 120 may include, without limitation, one or more processors 220 for executing software instructions, a memory 222, and a network interface 224. The network interface 224 electrically couples the ground controller 120 to the network 122. The network interface 224 includes any component, system, or device that provides network signaling and network frame processing functions to the ground controller 120. The network 122 may include a local network, the Internet, or a combination of a local network and the Internet, in some embodiments.

[0029] 3 is a flow chart of a method 300 operable by an NGSO satellite in an exemplary embodiment. Although method 300 will be described with respect to satellite 102-2 of spatial constellation 100 of FIG. 1, method 300 applies equally to other satellites 102 in spatial constellation 100. Moreover, method 300 applies equally to other NGSO satellites in other spatial constellations. The steps of method 300 are not exhaustive and may include other steps not shown. Moreover, the steps of method 300 may be performed in an alternative order.

[0030] Consider that the spatial constellation 100 is operational and that the ground controller 120 has a pre-calculated backbone route table 218 for the satellite 102-2. To do so, the ground controller 120 utilizes a priori orbital information for the satellite 102-2, including the satellite 102-2's time-varying view of the other satellites 102 in the spatial constellation 100. For example, over time, the view of the satellite 102-2 relative to the other satellites 102 in the spatial constellation 100 may include satellite 102-6, satellite 102-5, and satellite 102-4. The ground controller 120 then pre-calculates the backbone route table 218 for the satellite 102-2 accordingly, which changes over time.

[0031] In response to computing the backbone route table 218 for the satellite 102-2, the ground controller 120 uploads the backbone route table 218 to the satellite 102-2. The satellite 102-2 receives the backbone route table 218 from the ground controller 120 (see step 301) and stores the backbone route table 218 in memory 204 (see step 302). The satellite 102-2 selects the active backbone route table 218 stored in memory 204 (e.g., as instructed by the ground controller 120, see step 303).

[0032] The ground controller 120 calculates a user route table 216 for the satellite 102-2 that includes information about whether users 114 are locally connected to the satellite 102-2 and which of the users 114 are connected to other satellites 102 in the spatial constellation 100. For example, the user route table 216 for the satellite 102-2 may indicate that user 114-2 is locally connected to the satellite 102-2 and that users 114-1 and 114-3 are connected to other satellites 102 in the spatial constellation 100. This type of information allows the satellite 102-2 to determine whether data packets intended for the user 114 should be forwarded to another satellite 102 in the spatial constellation 100 or processed locally at the satellite 102-2 without being forwarded.

[0033] In response to computing the user path table 216 for the satellite 102-2, the ground controller 120 uploads the user path table 216 to the satellite 102-2, which receives it (see step 304). The satellite 102-2 stores its user path table 216 in its memory 204 (see step 305).

[0034] During operation, the satellite 102-2 monitors information from the ground controller 120 to determine whether it has received a new user path table 216 (see step 306). If a new user path table 216 has not been received, step 310 is performed. The new user path table 216 may be received, for example, when a handoff occurs for the user 114 from one satellite 102 to another satellite 102. When a handoff occurs, the ground controller 120 calculates a new user path table 216 that reflects the change in how the user 114 is connected to the satellites 102 in the spatial constellation 100 and uploads the new user path table to the appropriate satellites 102. When the new user path table 216 is received by the satellite 102-2, the satellite 102-2 updates the user path table 216 stored in the memory 204 (see step 308) and step 310 is performed.

[0035] During operation, the satellite 102-2 also determines whether the active backbone route table 218 has changed (see step 310). If the active backbone route table 218 has not changed, step 314 is performed. Typically, the active backbone route table 218 changes based on time-varying changes in the spatial constellation 100. In one embodiment, the ground controller 120 instructs the satellite 102-2 when to change the active backbone route table 218. In another embodiment, the satellite 102-2 selects a different backbone route table 218 based on internal criteria, such as the time of day. If the satellite 102-2 is instructed or determines to change the active backbone route table 218, the satellite 102-2 selects a new backbone route table 218 from the multiple backbone route tables 218 previously received by the satellite 102-2 from the ground controller 120 (see step 312) and performs step 314.

[0036] During operation, satellite 102-2 monitors its communication links (e.g., intra-orbital link 110, inter-orbital link 112, and user link 118) to determine whether a data packet has been received for processing (see step 314). In other embodiments, receiving a data packet includes receiving multiple data packets. Thus, the following description of processing received data applies equally to processing multiple data packets.

[0037] If the data packet is not received, the satellite 102-2 continues monitoring and the process returns to step 306. If the data packet is received by the satellite 102-2, step 316 is executed. The received data packet may be destined for one of the users 114, for example. The satellite 102-2 determines whether the data packet is destined for a user 114 locally connected to another satellite 102 in the spatial constellation 100 based on one or more of the user route tables 216 (see step 316). For example, the user 114 is served by a user link 118 maintained by a satellite 102 other than the satellite 102-2. If the data packet is not destined for a user 114 of another satellite 102, the satellite 102-2 determines in step 318 whether the data packet is destined for a user 114 locally connected to itself (e.g., the satellite 102-2). If the data packet is not intended for any user 114 served by the satellite 102-2, the data packet is dropped (see step 320) and the process returns to step 306 for monitoring.

[0038] If the satellite 102-2 determines that the data packet is intended for a user 114 connected locally to itself, the satellite 102-2 transmits the packet to the user 114 via a user link 118 maintained by the satellite 102-2 (see step 322), and the process returns to step 306. For example, if the data packet is addressed to user 114-2, the satellite 102-2 transmits the packet to user 114-2 via user link 118-2.

[0039] If the satellite 102-2 determines that the data packet is destined for a user 114 that is locally connected to a different satellite 102, as described in step 316, the satellite 102-2 determines to which of the satellites 102 the user 114 is locally connected based on the user route table 216 (see step 324). The satellite 102-2 determines which backbone route table 218 is active in the satellite 102-2 (see step 326) and forwards the data packet to one of the satellites 102 to which the user 114 is locally connected based on the active backbone route table 218 (see step 328). The process then returns to step 306 for monitoring.

[0040] For example, consider that satellite 102-2 receives a data packet addressed to user 114-1. Based on a user route table 216 stored in satellite 102-2, satellite 102-2 determines that user 114-1 is locally connected to satellite 102-4. Satellite 102-2 then forwards the data packet to satellite 102-4 based on an active backbone route table 218 stored in memory 204 of satellite 102-2. The active backbone route table 218 may, for example, instruct satellite 102-2 to forward the data packet intended for user 114-1 to satellite 102-1 via intra-orbital link 110-1 or to forward the data packet intended for user 114-1 to satellite 102-5 via inter-orbital link 112-2. In either case, the receiving satellite 102 performs the same or a similar process to determine whether the received data packet is intended for a user 114 locally connected to that particular satellite 102. For example, if satellite 102-1 receives a data packet intended for user 114-1 from satellite 102-2, satellite 102-1 may determine that user 114-1 is locally connected to another satellite 102, and accordingly, satellite 102-1 may forward the data packet to satellite 102-4 via inter-orbital link 112-1. If satellite 102-5 receives a data packet from satellite 102-2, satellite 102-5 may determine that user 114-1 is locally connected to another satellite 102, and accordingly, satellite 102-5 may forward the data packet to satellite 102-4 via intra-orbital link 110-3. In response to satellite 102-4 receiving a data packet intended for user 114-1, satellite 102-4 determines that user 114-1 is not locally connected to another satellite 102 and transmits the data packet to user 114-1 via a user link 118 (e.g., user link 118-1) maintained by satellite 102-4.

[0041] 4 is an implementation of routing for satellite 102-2 in an exemplary embodiment. In this embodiment, switch / router 214-1 for satellite 102-2 includes ports 401-405 communicatively coupled to communication channel 210-1, communication channel 210-2, communication channel 210-3, communication channel 210-4, and communication channel 210-5, respectively. Based on spatial constellation 100 at a particular point in time, port 401 provides a routing path to satellite 102-1 via intra-orbital link 110-1, port 402 provides a routing path to satellite 102-5 via inter-orbital link 112-2, port 403 provides a routing path to user 114-2, port 404 provides a routing path to satellite 102-6, and port 405 provides a routing path to satellite 102-3 via intra-orbital link 110-2. FIG. 4 will be used in the following description of how satellite 102-2 may perform a packet routing process using user route table 216 and backbone route table 218, as described in FIG.

[0042] FIG. 5 illustrates the user route table 216 and backbone route table 218 for satellite 102-2 in one exemplary embodiment. In particular, FIG. 5 illustrates multiple table numbers 502, 0 through N, used by satellite 102-2 when processing received data packets for users 114. In addition, each table number 502 in FIG. 5 defines a matching condition 504 and an action 506 to be taken when a match occurs in the corresponding table. Table 0 corresponds to user route table 216-1, which defines which action 506 occurs when any of users 114 are not locally connected to satellite 102-2. Table 1 corresponds to user route table 216-2, which defines which action 506 occurs when users 114 are locally connected to satellite 102-2. Table 2 defines which backbone route table 218 is currently active. In Figure 5, the active backbone route table 218 is table 3, which corresponds to backbone route table 218-1. Each of the backbone route tables 218 defines what action 506 occurs when routing a data packet to a satellite 102 other than satellite 102-2. Figure 5 also shows tables 4 and N, which specify the future backbone routing arrangement for satellite 102-2. How satellite 102-2 utilizes the tables of Figure 5 and the routing arrangement of Figure 4 will be described below with respect to Figure 6.

[0043] Figure 6 illustrates further details of method 300 in an example embodiment. Although the steps of Figure 6 will be described with respect to Figures 5-6 and satellite 102-2, the steps of Figure 6 may also be applied to other NGSO satellites in either spatial constellation 100 or the NGSO spatial constellation.

[0044] When a data packet is received by the satellite 102-2 (see step 314), processing of the data packet begins with Table 0 of FIG. 5, which corresponds to the user route table 216-1. In this embodiment, the user route table 216-1 (Table 0) identifies which of the users 114 in the spatial constellation 100 are connected to other satellites 102 (e.g., the users 114 are not locally connected to the satellite 102-2). For example, the user route table 216-1 specifies that the user 114-1 is locally connected to the satellite 102-4 and the user 114-3 is locally connected to the satellite 102-3. When the data packet is received by the satellite 102-2, the satellite 102-2 determines whether the address for the data packet matches an IP prefix for a user 114 locally connected to another satellite 102 based on the entries in Table 0 and the matching conditions 504 (see step 602 of FIG. 6). A match of the IP prefix in Table 0 informs satellite 102-2 that the data received by satellite 102-2 is destined for another satellite 102 in the constellation 100.

[0045] If a match occurs for an entry in Table 0, then satellite 102-2 performs the action 506 in Table 0 that corresponds to the matching entry. In particular, satellite 102-2 writes satellite node ID metadata for the data packet, which tags how the data packet is subsequently processed (see step 604).

[0046] For example, if the data packet received by satellite 102-2 contains an IP prefix for user 114-1, satellite 102-2 performs operation 506 of writing the node ID of satellite 102-4 to the metadata associated with the packet, and processing jumps to Table 2. If the data packet received by satellite 102-2 contains an IP prefix for user 114-3, satellite 102-2 performs operation 506 of writing the node ID of satellite 102-3 to the metadata associated with the packet, and processing also jumps to Table 2. In either case, the metadata written for the data packet specifies how the backbone route table 218 will forward the data packet through switch / router 214-1 (see FIG. 4) of satellite 102-2. Using Table 2 of FIG. 5, satellite 102-2 identifies the active backbone route table 218 (see step 324). In FIG. 5, Table 2 shows that the active backbone route table 218 is located in Table 3. 5. Using the information in Table 2, processing continues at Table 3 of FIG. 5. Using Table 3 and the metadata written about the data packet, satellite 102-2 determines to which port 401-405 of switch / router 214-1 the data packet is to be routed (see step 606). Satellite 102-2 then routes the data packet to one of satellites 102 using the identified port on switch / router 214-1 (see step 608).

[0047] Referring back to step 602, if no matching condition 504 is found for the data packet, satellite 102-2 begins processing Table 1, which corresponds to user route table 216-2. In this case, the lack of a match assumes that the data packet received by satellite 102-2 is intended for a user 114 that is locally connected to satellite 102-2 (e.g., a user 114 that communicates with satellite 102-2 via user link 118).

[0048] When the process moves to Table 1 based on the action 506 specified in Table 0, the satellite 102-2 determines whether the data packet received by the satellite 102-2 matches an IP prefix for a user 114 in Table 1 (i.e., the user route table 214-2). Table 1 identifies which users 114, if any, are locally connected to the satellite 102-2 (see step 610). If there is no match, the packet is dropped (see step 612). If the address of the data packet matches an IP prefix for a user 114 in Table 1, the satellite 102-2 identifies a local port for that locally attached user 114 (see step 614). The satellite 102-2 then uses the switch / router 214-1 to send the data packet to that user 114 via the identified port (see step 616). In this embodiment, user 114-2 is locally connected to satellite 102-2 via user link 118-2 (see FIG. 4) at port 403. Thus, if a data packet matches an IP prefix for user 114-2 in Table 1, satellite 102-2 performs action 506 in Table 1 to send the data packet through port 403 in switch / router 214-1.

[0049] For example, if the metadata associated with the data packet indicates the node ID of satellite 102-1, satellite 102-2 will forward the data packet via port 401 as indicated by backbone route table 218-1. If the metadata indicates the node ID of satellite 102-3, port 405 is used. In a similar manner, if the metadata indicates the node ID of satellite 102-4, port 402 is used, and if the metadata indicates the node ID of satellite 102-6, port 404 is used. This information corresponds to the matching conditions 504 and their actions 506 shown in Table 3. Table 3 is backbone route table 218-1. How the various ports 401-405 correspond to the intra-orbit links 110, inter-orbit links 112, or user links 118 for satellite 102-2 is more clearly identified in FIG. 4. FIG. 4 is a snapshot of the routing arrangement defined by the active backbone route table 218-1 in satellite 102-2. In response to transmitting the data in step 614, processing returns to step 306 for monitoring.

[0050] As previously described with respect to FIG. 3, the satellite 102-2 may receive updates to its user route table 216 during operation as the user 114 is handed off to a different satellite 102 in the spatial constellation 100. When an update occurs, the satellite 102-2 performs step 308 (see FIG. 6) by updating table 0 and / or table 1 of FIG. 5, which correspond to user route table 216-1 and user route table 216-2, respectively. For example, if the user 114-1 is handed off from satellite 102-4 to 102-5, the ground controller generates a new user route table 216-1 for the satellite 102-2 indicating that the operation 506 for the user 114-1 has changed, writing the node ID of the satellite 102-2 rather than the node ID of the satellite 102-4. This type of update is performed independently of the backbone route table 218, thereby reducing the computational load of the ground controller 120 and the updating of real-time data from the ground controller 120 to the satellite 102. In another example, if user 114-2 is handed off from satellite 102-2 to satellite 102-5 (e.g., user link 118-2 is terminated between user 114-2 and satellite 102-2 and user link 118-4 is created between user 114-2 and satellite 102-5), ground controller 120 updates both user route table 216-1 and user route table 216-2 for satellite 102-2. In particular, the update to Table 0 may indicate that user 114-2 is now located at satellite 102-5 and the entry for user 114-2 in Table 2 may be removed.

[0051] Also as previously described, different backbone route tables 218 are used by satellite 102 at different points in time as spatial constellation 100 changes due to the orbital motion of satellite 102. When a new backbone route table 218 is selected (see step 312 of FIG. 6), satellite 102-2 updates Table 2 to indicate which backbone route table 218 is currently active at various times. For example, at some future point in time, Table 2 of FIG. 5 may be updated to point to the new backbone route table 218 (e.g., by updating the information in backbone route table 218-2, Table 2 in Table 4). This allows satellite 102-2 to adapt to changes in spatial constellation 100 over time during the packet routing process.

[0052] Although this process has been specifically described with respect to the backbone route table 218-1 and the transient backbone constellation defined in satellite 102-2, the process applies equally to other satellites 102 in the constellation 100 and during other periods of operation in which the constellation 100 may change based on the orbital mechanics of the satellite 102.

[0053] Any of the various elements illustrated in the figures described herein may be implemented as hardware, software, firmware, or some combination thereof. For example, certain elements may be implemented as dedicated hardware. Dedicated hardware elements may be referred to as "processors," "controllers," or some similar terminology. When functions are provided by a processor, they may be provided by a single dedicated processor, by a single shared processor, or by multiple individual processors, some of which may be shared. Furthermore, explicit use of the terms "processor" or "controller" should not be construed as referring only to hardware capable of executing software, but may implicitly include, without limitation, digital signal processor (DSP) hardware, network processors, application specific integrated circuits (ASICs) or other circuits, field programmable gate arrays (FPGAs), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage, logic, or any other physical hardware component or module.

[0054] Furthermore, an element may be implemented as instructions executable by a processor or computer, thereby performing the functions of the element. Some examples of instructions are software, program code, and firmware. The instructions, when executed by a processor, are operable to instruct the processor to perform the functions of the element. The instructions may be stored in a storage device readable by the processor. Some examples of storage devices are digital or solid state memory, magnetic storage media such as magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.

[0055] Further, the present disclosure includes embodiments according to the following clauses: Article 1. 1. A method (300) operable by a satellite in a non-geostationary orbit (NGSO) system, comprising: receiving from a ground controller (301) a plurality of backbone route tables, each of which defines a snapshot of a time-varying backbone spatial configuration of the NGSO system; receiving (304) one or more user route tables from the ground controller, the user route tables specifying connectivity of users to satellites in the NGSO system; receiving (314) a data packet for routing in the NGSO system; determining (316) whether the data packet is destined for a first user directly connected to another satellite in the NGSO system based on the user route table; In response to determining that the data packet is destined for the first user, identifying (324) the other satellite based on the user route table; identifying an active backbone route table from the plurality of backbone route tables (326); and performing a step (328) of forwarding the data packet to the other satellite based on the active backbone route table; determining (318) whether the data packet is destined for a second user directly connected to the satellite based on the user route table; and in response to determining that the data packet is destined for the second user, transmitting (322) the data packet to the second user via a user link maintained by the satellite. Article 2. determining (310) that the active backbone route table has changed; and 2. The method of claim 1, further comprising: selecting (312) a new active backbone route table from the plurality of backbone route tables. Article 3. determining that the active backbone route table has changed, 3. The method of claim 2, comprising receiving an instruction from the ground controller to select the new active backbone route table. Article 4. 4. The method of any one of clauses 1 to 3, further comprising receiving updates to the user route table from the ground controller in response to real-time or predicted changes in the connectivity of the users to the satellites in the NGSO system. Article 5. determining whether the data packet is destined for the first user based on the user route table; determining (602) that the data packet is destined for the first user when an address for the data packet matches an Internet Protocol (IP) prefix for a table entry for the first user in a first user route table of the one or more user route tables; The method further comprising: writing (604) satellite node identification (ID) metadata for the data packet; identifying (606) a first port in a switch of the satellite that is communicatively coupled to another satellite via at least one of an intra-orbit link and an inter-orbit link based on the metadata for the data packet and the active backbone route table; and 5. The method of any one of clauses 1 to 4, further comprising forwarding (608) the data packet through the first port. Article 6. determining whether the data packet is destined for the second user based on the user route table; determining (610) that the data packet is addressed to the second user when the address for the data packet matches an IP prefix for a table entry for the second user in a second user route table of the one or more user route tables; The method further comprising: identifying (614) a second port in the switch of the satellite that is communicatively coupled to the second user via a user link based on the table entry for the second user in the second user route table; and 6. The method of claim 5, further comprising transmitting (616) the data packet to the second user via the second port. Article 7. 7. The method of claim 6, further comprising receiving, from the ground controller, updates to the first user route table based on changes in real-time or predicted connectivity of the first user to other satellites in the NGSO system. Article 8. 8. The method of claim 7, further comprising receiving, from the ground controller, updates to the second user route table based on changes in real-time or predicted connectivity of the second user to the satellite. Article 9. A non-transitory computer readable medium having programmed instructions embodied therein that, when executed by one or more processors (202) of a satellite (102) of a non-geostationary orbit (NGSO) system (100), cause the satellite to: receiving (301) a plurality of backbone route tables from a ground controller, each backbone route table defining a snapshot of a time-varying backbone spatial configuration of the NGSO system; receiving (304) one or more user route tables from the ground controller, the user route tables specifying connectivity of users to satellites in the NGSO system; receiving (314) a data packet for routing in the NGSO system; determining (316) whether the data packet is destined for a first user directly connected to another satellite in the NGSO system based on the user route table; In response to determining that the data packet is destined for a first user, identifying the other satellite based on the user route table (324); identifying an active backbone route table from the plurality of backbone route tables (326); and forwarding the data packet to the other satellite based on the active backbone route table (328); determining (318) whether the data packet is destined for a second user directly connected to the satellite based on the user route table; and in response to determining that the data packet is destined for the second user, transmitting (322) the data packet to the second user via a user link maintained by the satellite. Article 10. The programmed instructions cause the satellite to: determining (310) that the active backbone route table has changed; and 10. The non-transitory computer-readable medium of claim 9, further instructing: selecting (312) a new active backbone route table from the plurality of backbone route tables. Article 11. The programmed instructions cause the satellite to: 11. The non-transitory computer-readable medium of claim 10, further instructing: selecting the new active backbone route table in response to instructions received from the ground controller. Article 12. The programmed instructions cause the satellite to: 12. The non-transitory computer-readable medium of any one of clauses 9 to 11, further directing: receiving updates of the user route table from the ground controller in response to real-time or predicted changes in the connectivity of the user to the satellites in the NGSO system. Article 13. The satellite determines (602) that the data packet is destined for the first user when an address for the data packet matches an Internet Protocol (IP) prefix for a table entry for the first user in a first user route table of the one or more user route tables; The programmed instructions cause the satellite to: writing (604) satellite node identification (ID) metadata for the data packet; identifying (606) a first port in a switch of the satellite that is communicatively coupled to another satellite via at least one of an intra-orbit link and an inter-orbit link based on the metadata for the data packet and the active backbone route table; and 13. The non-transitory computer-readable medium of any one of clauses 9 to 12, further instructing: forwarding (608) the data packet through the first port. Article 14. The satellite determines (610) that the data packet is destined for the second user when an address for the data packet matches an IP prefix for a table entry for the second user in a second user route table of the one or more user route tables; The programmed instructions cause the satellite to: identifying (614) a second port in the switch of the satellite that is communicatively coupled to the second user via a user link based on the table entry for the second user in the second user route table; and 14. The non-transitory computer-readable medium of claim 13, further instructing: transmitting (616) the data packet to the second user via the second port. Article 15. The programmed instructions cause the satellite to: 15. The non-transitory computer-readable medium of claim 14, further instructing receiving from the ground controller updates to the first user route table based on changes in real-time or predicted connectivity of the first user to other satellites in the NGSO system. Article 16. The programmed instructions cause the satellite to: 16. The non-transitory computer-readable medium of claim 15, further instructing receiving from the ground controller updates to the second user route table based on changes in real-time or predicted connectivity of the second user to the satellite. Article 17. A non-geostationary satellite orbit (NGSO) system (100), comprising: The NGSO system includes a satellite (102), the satellite (102) including: A memory (204), a plurality of backbone route tables (218) received from a ground controller (120), each backbone route table defining a snapshot of a time-varying backbone spatial configuration of the NGSO system; and a memory storing one or more user route tables (216) received from the ground controller, the user route tables specifying connectivity of users (114) to satellites (102) in the NGSO system; a communications system (210) configured to implement at least one of a user link (118) with a user of the NGSO system, an intra-orbit link (110) with other satellites in the NGSO system that share a common orbital plane with the satellite, and an inter-orbit link (112) with other satellites in the NGSO system that are in a different orbital plane than the satellite; at least one processor (202) configured to receive a data packet for routing in the NGSO system and determine, based on the user route table, whether the data packet is destined for a first user directly connected to another satellite in the NGSO system; the at least one processor is configured, in response to determining that the data packet is destined for the first user, to identify the other satellite based on the user route table, identify an active backbone route table from the plurality of backbone route tables, and forward the data packet to the other satellite via an inter-orbital link or an intra-orbital link based on the active backbone route table; the at least one processor is configured to determine, based on the user route table, whether the data packet is destined for a second user directly connected to the satellite, and in response to determining that the data packet is destined for the second user, transmit the data packet to the second user via a user link maintained by the satellite. Article 18. 18. The NGSO system of claim 17, wherein the at least one processor is configured to determine that the active backbone route table has changed and to select a new active backbone route table from the plurality of backbone route tables. Article 19. 19. The NGSO system of claim 18, wherein the at least one processor is configured to select the new active backbone route table in response to an instruction received from the ground controller. Article 20. 20. The NGSO system of any one of clauses 17 to 19, wherein the at least one processor is configured to receive updates to the user route table from the ground controller in response to real-time or predicted changes in the connectivity of the users to the satellites in the NGSO system. Article 21. The satellite, a switch (214) having a first port communicatively coupled to the other satellite via the intra-orbit link or the inter-orbit link; the at least one processor is configured to determine that the data packet is destined for the first user when an address for the data packet matches an Internet Protocol (IP) prefix for a table entry for the first user in a first user route table of the one or more user route tables; 21. The NGSO system of any one of clauses 17 to 20, wherein the at least one processor is configured to write satellite node identification (ID) metadata for the data packet, identify the first port based on the metadata for the data packet and the active backbone route table, and forward the data packet to the other satellite via the first port. Article 22. the switch further includes a second port communicatively coupled to the second user via a user link; 22. The NGSO satellite system of claim 21, wherein the at least one processor is configured to determine that the data packet is addressed to the second user when the address for the data packet matches an IP prefix for a table entry for the second user in a second user route table of the one or more user route tables, identify the second port based on the table entry for the second user in the second user route table, and transmit the data packet to the second user via the second port. Article 23. 23. The NGSO satellite system of claim 22, wherein the at least one processor is configured to receive updates to the first user route table from the ground controller based on changes in real-time or predicted connectivity of the first user to other satellites in the NGSO system. Article 24. 24. The NGSO satellite system of claim 23, wherein the at least one processor is configured to receive updates to the second user route table from the ground controller based on changes in real-time or predicted connectivity of the second user to the satellite. Article 25. 25. The NGSO satellite system of any one of clauses 17 to 24, further comprising the ground controller.

[0056] Although specific embodiments have been described herein, the scope of the disclosure is not limited to those specific embodiments. Rather, the scope of the disclosure is defined by the following claims and any equivalents thereof.

Claims

1. 1. A method (300) operable by a satellite in a Non-geostationary Orbit (NGSO) system, comprising: receiving from a ground controller (301) a plurality of backbone route tables, each of which defines a snapshot of a time-varying backbone spatial configuration of the NGSO system; receiving (304) one or more user route tables from the ground controller, the user route tables specifying connectivity of users to satellites in the NGSO system; receiving (314) a data packet for routing in the NGSO system; determining (316) whether the data packet is destined for a first user directly connected to another satellite in the NGSO system based on the user route table; in response to determining that the data packet is destined for the first user, Identifying the other satellite based on the user route table (324); identifying an active backbone route table from the plurality of backbone route tables (326); and performing a step (328) of forwarding the data packet to the other satellite via an intra-orbit link (110) with another satellite in the NGSO system that shares a common orbital plane with the satellite, or an inter-orbit link (112) with another satellite in the NGSO system that is in a different orbital plane from the satellite, based on the active backbone route table; determining (318) whether the data packet is destined for a second user directly connected to the satellite based on the user route table; and in response to determining that the data packet is destined for the second user, transmitting (322) the data packet to the second user via a user link maintained by the satellite.

2. determining (310) that the active backbone route table has changed; and 2. The method of claim 1, further comprising: selecting (312) a new active backbone route table from the plurality of backbone route tables.

3. determining that the active backbone route table has changed, The method of claim 2 , comprising receiving an instruction from the ground controller to select the new active backbone route table.

4. 4. The method of claim 1, further comprising receiving updates to the user route table from the ground controller in response to real-time or predicted changes in the connectivity of the users to the satellites in the NGSO system.

5. determining whether the data packet is destined for the first user based on the user route table; determining (602) that the data packet is destined for the first user when an address for the data packet matches an Internet Protocol (IP) prefix for a table entry for the first user in a first user route table of the one or more user route tables; The method further comprising: writing (604) satellite node identification (ID) metadata for the data packet; Identifying (606) a first port in a switch of the satellite that is communicatively coupled to another satellite via at least one of an intra-orbit link and an inter-orbit link based on the metadata for the data packet and the active backbone route table; and The method of claim 1 , further comprising forwarding (608) the data packet through the first port.

6. determining whether the data packet is destined for the second user based on the user route table; determining (610) that the data packet is addressed to the second user when the address for the data packet matches an IP prefix for a table entry for the second user in a second user route table of the one or more user route tables; The method further comprising: identifying (614) a second port in the switch of the satellite that is communicatively coupled to the second user via a user link based on the table entry for the second user in the second user route table; and 6. The method of claim 5, further comprising transmitting (616) the data packet to the second user via the second port.

7. 7. The method of claim 6, further comprising receiving, from the ground controller, updates to the first user route table based on changes in real-time or predicted connectivity of the first user to other satellites in the NGSO system.

8. 8. The method of claim 7, further comprising receiving, from the ground controller, updates to the second user route table based on changes in real-time or predicted connectivity of the second user to the satellite.

9. A non-geostationary satellite orbit (NGSO) system (100), The NGSO system includes a satellite (102), the satellite (102) including: A memory (204), a plurality of backbone route tables (218) received from a ground controller (120), each backbone route table defining a snapshot of a time-varying backbone spatial configuration of the NGSO system; and a memory storing one or more user route tables (216) received from the ground controller, the user route tables specifying connectivity of users (114) to satellites (102) in the NGSO system; a communications system (210) configured to implement at least one of a user link (118) with a user of the NGSO system, an intra-orbit link (110) with other satellites in the NGSO system that share a common orbital plane with the satellite, and an inter-orbit link (112) with other satellites in the NGSO system that are in a different orbital plane from the satellite; at least one processor (202) configured to receive a data packet for routing in the NGSO system and determine, based on the user route table, whether the data packet is destined for a first user directly connected to another satellite in the NGSO system; the at least one processor is configured, in response to determining that the data packet is destined for the first user, to identify the other satellite based on the user route table, identify an active backbone route table from the plurality of backbone route tables, and forward the data packet to the other satellite via an inter-orbital link or an intra-orbital link based on the active backbone route table; the at least one processor is configured to determine, based on the user route table, whether the data packet is destined for a second user directly connected to the satellite, and in response to determining that the data packet is destined for the second user, transmit the data packet to the second user via a user link maintained by the satellite.

10. 10. The NGSO system of claim 9, wherein the at least one processor is configured to determine that the active backbone route table has changed and to select a new active backbone route table from the plurality of backbone route tables.

11. 11. The NGSO system of claim 10, wherein the at least one processor is configured to select the new active backbone route table in response to an instruction received from the ground controller.

12. 12. The NGSO system of claim 9, wherein the at least one processor is configured to receive updates to the user route table from the ground controller in response to real-time or predicted changes in the connectivity of the users to the satellites in the NGSO system.

13. The satellite, a switch (214) having a first port communicatively coupled to the other satellite via the intra-orbit link or the inter-orbit link; the at least one processor is configured to determine that the data packet is destined for the first user when an address for the data packet matches an Internet Protocol (IP) prefix for a table entry for the first user in a first user route table of the one or more user route tables; 13. The NGSO system of claim 9, wherein the at least one processor is configured to write satellite node identification (ID) metadata for the data packet, identify the first port based on the metadata for the data packet and the active backbone route table, and forward the data packet to the other satellite via the first port.

14. the switch further includes a second port communicatively coupled to the second user via a user link; 14. The NGSO system of claim 13, wherein the at least one processor is configured to determine that the data packet is addressed to the second user when the address for the data packet matches an IP prefix for a table entry for the second user in a second user route table of the one or more user route tables, identify the second port based on the table entry for the second user in the second user route table, and transmit the data packet to the second user via the second port.

15. the at least one processor is configured to receive updates to the first user route table from the ground controller based on changes in real-time or predicted connectivity of the first user to other satellites in the NGSO system; 15. The NGSO system of claim 14, wherein the at least one processor is configured to receive updates to the second user route table from the ground controller based on changes in real-time or predicted connectivity of the second user to the satellite.

Images