Patent Description:
The present invention generally relates to satellite communication and, more particularly, to data packet forwarding in a non-geosynchronous orbit (NGSO) satellite network.

Non-geosynchronous orbit (NGSO) satellite networks have the potential to provide very high throughput, low-delay services to end-users, allowing them to effectively complement or even compete with the terrestrial fiber and the wireless service offerings. However, end-to-end, hop-by-hop data packet forwarding in an NGSO satellite network is extremely challenging given the dynamic nature of the satellite constellation. There is a continually changing relationship between satellites and user-terminals, satellites and gateways, as well as user-terminals and gateways (in NGSO constellations where the payload performs no processing or partial processing). This continually changing relationship requires the frequent updating of forwarding tables. The network dynamism is further accentuated in NGSO constellations, which use satellite cross-links and on-board processing.

For such constellations, forwarding tables also need to be updated to account for changes in cross-link connectivity and changes in best paths between source and destination end-points. Mobile user-terminals, which change satellite connectivity based on changes in terminal location, further heighten the problem of asynchronously updating forwarding tables. Finally, the large scale associated with typical NGSO networks being envisaged (e.g., including hundreds to thousands of satellites, hundreds of gateways, and millions of end-user terminals) makes the data packet forwarding challenge truly challenging. The scale aspects are of concern to both the size of forwarding tables, especially on satellites that have limited on-board memory, as well as the amount of network bandwidth (capacity) needed for updating the forwarding tables at each network node.

<CIT> refers to a handoff procedure for a satellite communication system such as a broadband low-Earth orbit (LEO) satellite communication system. A gateway and a user terminal (UT) coordinate and schedule a satellite-to-satellite handoff in such a way that there are no messaging round-trip delays between the last return service link (RSL) packet transmitted from the user terminal to the source satellite and the first RSL packet transmitted from the user terminal to the target satellite. Therefore, an outage on the return link (from the user terminal to the gateway) can be limited to the actual time for moving the antenna feed from the source satellite to the target satellite. Furthermore, an outage on the forward link (from the gateway to the user terminal) can be limited to a single round-trip delay in addition to the time for moving the antenna feed.

D2 <CIT> refers to a SDSN that employs satellite network nodes, where central L2 network nodes are controlled via a centralized Controller. Link status information is obtained regarding links of each L2 node. Global routing constraints, satellite ephemeris data, and resource allocation information are obtained. A constellation topology of the network nodes is determined based on the ephemeris data. Network routes between pairs of endpoints are determined. Each route includes links based on the link status information regarding the links, the global routing constraints, the bandwidth resources of the links and the current allocation of bandwidth resources, and/or the constellation topology. A forwarding table is generated for each network node, wherein each forwarding table includes route entries providing a next hop indicating a destination for data packets, wherein the destination is associated with a link of the respective network node that represents a link of a respective route.

According to various aspects of the subject technology, methods and systems are disclosed for ensuring persistent end-to-end data packet forwarding in a non-geosynchronous orbit (NGSO) network. Key attributes of the subject solution are (a) proactive updates to the forwarding tables to deal with deterministic, time-synchronized link connectivity changes and (b) reactive updates to the forwarding table to deal with ad hoc link connectivity changes.

In one or more aspects, a communication system includes a satellite constellation, one or more gateways and a network controller. The satellite constellation includes multiple satellites to facilitate communication between a number of user terminals (UTs). Each gateway communicates with one or more of the satellites, if a processing satellite configuration is used, or directly with one or more UTs when the satellite is non-processing or bent-pipe. The network controller controls operation of the satellites, the gateways and the UTs. The satellites, the UTs, the gateways and the network controller include hardware that may also be software-defined network (SDN) enabled to ensure a persistent end-to-end data packet forwarding including proactive updates and reactive updates to forwarding tables. The proactive updates handle deterministic and time-synchronized link connectivity changes, and the reactive updates handle ad hoc link connectivity changes due to events such as user terminal mobility across beams, signal blockages from the user terminal in a specific direction or due to network failure scenarios.

In other aspects, a network controller includes a transceiver circuit and a processor. The transceiver circuit enables the network controller to communicate with one or more satellites of an NGSO satellite constellation, one or more gateways and a number of UTs. The processor controls operation of the satellites, the gateways and the UTs, updates destination tables, transmits updated destination tables to the UTs and transmits updated forwarding tables to the satellites.

The foregoing has outlined rather broadly the features of the present disclosure so that the following detailed description can be better understood. Additional features and advantages of the disclosure, which form the subject of the claims, will be described hereinafter.

For a more complete understanding of the present disclosure and the advantages thereof, reference is now made to the following descriptions to be taken in conjunction with the accompanying drawings describing specific aspects of the disclosure, wherein:.

The appended drawings are incorporated herein and constitute a part of the detailed description, which includes specific details for the purpose of providing a thorough understanding of the subject technology. However, it will be clear and apparent to those skilled in the art that the subject technology is not limited to the specific details set forth herein and can be practiced using one or more implementations. In one or more instances, well-known structures and components are shown in block-diagram form in order to avoid obscuring the concepts of the subject technology.

In some aspects of the present technology, methods and configuration are disclosed for ensuring persistent end-to-end data packet forwarding in a non-geosynchronous orbit (NGSO) network. Key attributes of the subject solution are (a) proactive updates to the forwarding tables to deal with deterministic, time-synchronized link connectivity changes, and (b) reactive updates to the forwarding table to deal with ad hoc link connectivity changes. The key benefits of the disclosed solution are the small forwarding table sizes at the core network nodes and the low network overhead associated with updating the network node forwarding tables. In the disclosed solution, the NGSO network is divided into two domains; <NUM>) a core network, which consists of all gateways and all satellites (when the satellites incorporate on-board processing and cross links); and <NUM>) an access network, which consist of the user terminals (UTs) attached (admitted) to the core network.

<FIG> is a high-level diagram illustrating an example NGSO satellite-network environment <NUM> that consists of on-board processing satellites according to certain aspects of the disclosure. The example NGSO satellite network environment <NUM> includes a number of NGSO satellites <NUM> (hereinafter, "satellites <NUM>," e.g., <NUM>-<NUM>, <NUM>-<NUM>. <NUM>-<NUM>), a number of satellite gateways <NUM> (hereinafter "gateways <NUM>", e.g., <NUM>-<NUM> and <NUM>-<NUM>), multiple UTs <NUM> (e.g., <NUM>-<NUM>, <NUM>-<NUM>. <NUM>-<NUM>) and a network operation center <NUM> (hereinafter, "control center <NUM>"). The satellites <NUM> are members of an NGSO satellite constellation and facilitate communication between the gateways <NUM> and the UTs <NUM> as well as between the UTs <NUM>. The communication between the UTs <NUM> can take place through one or more satellites <NUM>. For example, the UT <NUM>-<NUM> can connect to the gateway <NUM>-<NUM> via the satellite <NUM>-<NUM>. The UT <NUM>-<NUM>, for instance, can connect to gateway <NUM>-<NUM> via satellites <NUM>-<NUM>, and <NUM>-<NUM>. The UT <NUM>-<NUM> can connect to UT <NUM>-<NUM> via the satellites <NUM>-<NUM> and <NUM>-<NUM>. The gateways <NUM> are connected to terrestrial networks <NUM> (e.g., <NUM>-<NUM> and <NUM>-<NUM>, such as the Internet). Note that user networks connected to UTs <NUM> can also be the local Internet or Intranet <NUM>. The control center <NUM> can control the operations of the satellites <NUM>, gateways <NUM> and UTs <NUM><NUM>. In one or more aspects, the control center <NUM> may include a transceiver circuit to communicate with the satellites <NUM>, gateways <NUM>, UTs <NUM> via a "nearby" gateway <NUM> and a processor. The processor can secure a required end-to-end network capacity to support a CIR by evaluating all time-variant network paths and can enable the UTs <NUM> and the gateways <NUM> to perform per-flow QoS enforcement based on the CoS of a respective admitted traffic flow (e.g., <NUM>) to secure a required end-to-end network capacity to support a CIR (e.g., <NUM> Gbps) by evaluating all time-variant network paths that will be encountered given the dynamic nature of the NGSO constellation.

In some aspects, the satellites <NUM>, the gateways <NUM>, the UTs <NUM> and the control center <NUM> include hardware including field-programmable gate array (FPGA) processors and firmware to include one or more algorithms as described below.

Due to the nonstationary aspects of the NGSO satellites in relation to the earth, the UT-to-gateway (e.g., the UT <NUM>-<NUM> to the gateway <NUM>-<NUM>, in case of non-processed satellite constellation), UT-to-satellite (e.g., the UT <NUM>-<NUM> to satellite <NUM>-<NUM>), gateway-to-satellite (e.g., the gateway <NUM>-<NUM> to satellite <NUM>-<NUM>) and satellite-to-satellite (e.g., the satellite <NUM>-<NUM> to satellite <NUM>-<NUM>) connectivity is continually changing. A nonprocessed satellite is a satellite that does not implement any modem or packet switching functionality and serves in a bent-pipe mode. The nonstationary aspects of the NGSO satellites require frequent updating of the forwarding tables. The network dynamism is further accentuated in NGSO constellations, which use satellite cross-links and on-board processing.

For such constellations, forwarding tables also need to be updated to account for changes in cross link connectivity and changes in best paths between source and destination end-points. Mobile user-terminals, which change satellite connectivity based on changes in terminal location, further accentuate the problem of asynchronously updating forwarding tables. Further, the large scale associated with typical NGSO networks being envisaged makes the data packet forwarding truly challenging. The scale aspects are of concern to both the size of forwarding tables, especially on satellites that have limited on-board memory, as well as the amount of network bandwidth (capacity) needed for updating the forwarding tables at each network node. These challenges are overcome by the system of the subject technology, as discussed in more detail herein.

The subject solution, as implemented within the system <NUM>, includes two main functionalities. The first functionality includes forwarding in the core network. The second functionality includes detecting and automatically resolving service degradations. The first functionality is based on deterministic changes in the core network topology and changes in UT-to-satellite (for cases where the NGSO satellites incorporate on-board processing) or terminal-to-gateway (in the case of non-processed NGSO constellation). The first functionality also includes addressing nondeterministic changes due to mobile UTs. The second functionality addresses automated handling of service degradations due to recurring blockage or traffic congestion in the network.

The first functionality of the system <NUM>, which includes forwarding in the core network, involves three main aspects: a) hierarchical two-tuple based forwarding, b) centralized time-based route computation, and c) a local SDN controller, on the satellite and edge-nodes such as user terminals and gateways, that manages flow tables. The aspect in part a allows for smaller forwarding table within the core satellite network and, correspondingly, the ability to make low complexity and fast packet forwarding decisions. The aspects in parts b and c ensure that the bandwidth utilized for packet forwarding tables is minimized, with route computation performed on the ground. These aspects are described in more detail herein.

<FIG> is a schematic diagram illustrating an example system <NUM> for implementing a two-tuple packet forwarding algorithm between two user terminals (UTs) <NUM>, according to certain aspects of the disclosure. The example system <NUM> includes UTs <NUM> (<NUM>-<NUM> and <NUM>-<NUM>) and two satellites (also referred to space vehicle (SV)) <NUM> (<NUM>-<NUM> and <NUM>-<NUM>), which are in communication with a local network controller (e.g., central controller <NUM> of <FIG>). The local network controller, along with the UTs <NUM> and the satellites <NUM> are responsible for executing the two-tuple packet forwarding algorithm between two UTs <NUM>. The two-tuple packet forwarding algorithm starts with the local network controller making time-based updates to a destination table <NUM> in the UT <NUM>-<NUM>. The UT <NUM>-<NUM> (UT1) then updates the user packet <NUM>-<NUM> (including a data portion and a destination (Dest) portion) based on the updated destination table <NUM>. In the updated destination table <NUM>, the Dest terminal (Dest Term) and the Dest node (Dest Node) are indicated to be UT2 and satellite <NUM>-<NUM> (SV2), respectively. The updated packet <NUM>-<NUM>, includes a duplet address vector < UT2, SV2> compatible with updated destination table <NUM> and is forwarded to the satellite <NUM>- <NUM>.

The user packet <NUM>-<NUM> is programmed by the local network controller to pass through a route <NUM>, which consists of satellites <NUM>-<NUM> (SV1) and <NUM>-<NUM> (SV2) to reach UT <NUM>-<NUM> (UT2). In satellite <NUM>-<NUM>, the forwarding table (flow table) <NUM> is updated based on the current route by the local network controller, based on the current route <NUM>, to include SV2 and inter-satellite link (ISL) <NUM> as the Dest Node and Interface, respectively. The satellite <NUM>-<NUM> updates the address portion of the date packet <NUM>-<NUM> received from the UT <NUM>-<NUM> to produce a packet <NUM>-<NUM>, which includes UT2 and SV2 in its address portion and is forwarded to the satellite <NUM>-<NUM>. In satellite <NUM>-<NUM>, the forwarding table <NUM> is updated by the local network controller, based on the current route <NUM>, to include UT2 and beam <NUM> as the Dest Term and the Interface, respectively. Beam <NUM> is the link between the satellite <NUM>-<NUM> and the UT <NUM>-<NUM>. The satellite <NUM>-<NUM> changes the address portion of the data packet received from satellite <NUM>-<NUM> to produce a data packet <NUM>-<NUM>, having an address portion including UT2 and SV2, which is sent through beam <NUM> to the UT <NUM>-<NUM> (UT2). It is noted that in a scenario where the connection is terminated in a UT (such as the scenario of <FIG>), the address portion of the data packet includes the terminal identification (Term ID) if the destination terminal (e.g., UT2) and the satellite ID (SV ID) of the satellite (e.g., SV2) currently serving the destination terminal.

<FIG> is a schematic diagram illustrating an example system <NUM> for implementing a two-tuple packet-forwarding algorithm between a UT and a gateway, according to certain aspects of the disclosure. The example system <NUM> includes UT <NUM> (UT2), two satellites <NUM> (<NUM>-<NUM> and <NUM>-<NUM>) and a gateway <NUM> (GW A), which are in communication with a local network controller (e.g., central controller <NUM> of <FIG>). The local network controller, along with the UT <NUM>, satellites <NUM> and the gateway <NUM> are responsible for executing the two-tuple packet-forwarding algorithm between the UT <NUM> and the gateway <NUM>. The local network controller has selected the route <NUM> as the best route with the least delay between the UT <NUM> and the gateway <NUM>, which can connect the user <NUM> to a terrestrial network (e.g., the Internet) via a carrier <NUM>.

The two-tuple packet forwarding algorithm of <FIG> starts with the local network controller making time-based updates to a destination table <NUM> in the UT <NUM> and forwarding tables <NUM> and <NUM> of satellites <NUM>-<NUM> and <NUM>-<NUM>. The address portion of the user packet <NUM>-<NUM> is updated in the UT <NUM> to the packet <NUM>-<NUM>, and in satellites <NUM>-<NUM> and <NUM>-<NUM> to packets <NUM>-<NUM> and <NUM>-<NUM> respectively. In the packets <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM>, the destination address is indicated as <GW A, GW A>, where GW A is the node ID of the gateway <NUM>.

It is noted that the satellite <NUM>-<NUM> and <NUM>-<NUM> only check the Dest Node of the flow tables <NUM> and <NUM> to update the address portions of the packets <NUM>-<NUM> and <NUM>-<NUM>, respectively. Also, the UT and the gateway node IDs are used as subnet addresses and may require layer-<NUM> resolution. Forwarding table entries are limited to the satellite nodes and gateways, which limit the size of the forwarding table. The scalable-size is based on the number of satellites (e.g., many thousands) and gateways (e.g., hundreds or thousands) and can support millions of users.

<FIG> is a schematic diagram illustrating an example system <NUM> for implementing a centralized time-based routing algorithm, according to certain aspects of the disclosure.

The example system <NUM> includes a UT <NUM> , a satellite constellation <NUM> including satellites <NUM> (<NUM>-<NUM> through <NUM>-<NUM>), gateway <NUM>-<NUM> (GW A), <NUM>-<NUM> (GW B) and a route controller <NUM>, which are in communication with a local network controller (e.g., central controller <NUM> of <FIG>). At time T0, the satellite <NUM>-<NUM> has an active link with the gateway <NUM>-<NUM>, which makes the route <NUM> between the UT <NUM> and the gateway <NUM>-<NUM> the shortest path. However, at time T1, the link between the satellite <NUM>-<NUM> and the gateway <NUM>-<NUM> become unavailable, so the route <NUM> can no longer be used.

It is noted that the routes are computed and updated in a time-synchronized manner based on the admitted flows quality-of-service (QoS) parameters and traffic engineering. Paths are computed for all node pairs, across all network link connectivity changes. Multiple paths between nodes are computed to support differentiated service offerings, and alternate paths are also computed for automated rerouting on link failure. For example, at time T1, a local SDN controller on the satellite <NUM>-<NUM> manages the flow, by updating the forwarding (flow) tables <NUM>. In the updated flow table at T1, the interface field GW A is replaced with ISL <NUM> to indicate the next destination is a satellite node. Similarly, the flow tables of the satellites <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> are updated to have the link between the UT <NUM> and the gateway <NUM>-<NUM> established via the route <NUM>, which is the shortest possible route. The gateway <NUM> uses services of the route controller <NUM> to connect to the gateway <NUM>-<NUM> through a teleport and/or gateway ground network <NUM> (e.g., including fiber optics links) to complete the route <NUM> between the UT <NUM> and the gateway <NUM>-<NUM>.

<FIG> is a block diagram illustrating an example SDN framework <NUM> for packet forwarding, according to certain aspects of the disclosure. The example SDN framework <NUM> includes a local SDN controller <NUM> and a packet forwarding engine <NUM>. The SDN framework <NUM> is used in satellites nodes (e.g., satellites <NUM>-<NUM> through <NUM>-<NUM> of <FIG>) of a processed satellite network to manage distribution and execution of the forwarding tables, as described with respect to <FIG>. Time-tagged routing tables <NUM> are generated as the result of centralized time-based route computation <NUM> performed by the network controller (e.g., <NUM> of <FIG>), and are provided to the local SDN controller <NUM>. The local SDN controller <NUM> uses the services of the packet-forwarding engine <NUM> for parsing an incoming data packet and queuing the data packet for transmission to the next node in the route defined by the time-tagged routing tables <NUM>. The packet forwarding engine <NUM> can be implemented in hardware and/or firmware and consists of a number of blocks, including a parsing block, a number of matching-action tables, a packet data and metadata block and a global (flow) data block.

<FIG> is a schematic diagram illustrating an example system <NUM> for implementing a nonprocessed-satellite forwarding algorithm after satellite handoff, according to certain aspects of the disclosure. The example system <NUM> includes a UT <NUM>, satellites <NUM> (<NUM>-<NUM> and <NUM>-<NUM>), gateways <NUM> (<NUM>-<NUM> and <NUM>-<NUM>), carriers <NUM> (<NUM>-<NUM> and <NUM>-<NUM>) and local SDN controllers <NUM> (<NUM>-<NUM> and <NUM>-<NUM>) at the gateways <NUM> (<NUM>-<NUM> and <NUM>-<NUM>), which receive centralized time-based route computation <NUM> from a network controller (e.g., <NUM> of <FIG>). The satellites <NUM> are nonprocessed satellites, and the gateway <NUM>-<NUM> is a home gateway for the UT <NUM>. For the nonprocessed satellites <NUM>, the forwarding solution is similar to the forwarding solution described above with respect to <FIG>, except that instead of two-tuple addressing, only single-tuple addressing is used to indicate the destination node. For example, for the return link (UT-to-gateway) traffic, the UT <NUM> sets the configured home gateway <NUM>-<NUM> as the destination node, and for the forward link (gateway-to-UT) traffic, the home gateway <NUM>-<NUM> sets the user terminal as the destination node.

When the UT <NUM> moves to the satellite <NUM>-<NUM>, which does not directly link to the home gateway <NUM>-<NUM>, return link packets reach the gateway <NUM>-<NUM> (visitor gateway) and are then forwarded to the home gateway <NUM>-<NUM> using a terrestrial gateway and/or teleport network <NUM>. Similarly, when the forward link packets for the UT <NUM>, currently served by the gateway <NUM>-<NUM>, arrive at the home gateway <NUM>-<NUM>, they are forwarded to the gateway <NUM>-<NUM> using a terrestrial gateway and/or teleport network <NUM>. The SDN framework <NUM> of <FIG> is used to manage distribution and execution of the forwarding tables to the gateway and/or teleport locations. Each gateway <NUM> runs a local SDN controller <NUM> for forwarding traffic. The local SDN controller <NUM>-<NUM> at the gateway <NUM>-<NUM> checks the destination terminal in the flow table <NUM> to set the destination address of the data packet <NUM>. Also, the local SDN controller <NUM>-<NUM> at the gateway <NUM>-<NUM> sets the destination address of the data packet <NUM> to the home gateway <NUM>-<NUM> (GW A).

<FIG> is a schematic diagram illustrating an example system <NUM> for implementing measurement-based automated traffic engineering and UT-interference handling algorithm, according to certain aspects of the disclosure. The example system <NUM> includes a UT <NUM>, a satellite <NUM> of a satellite constellation and a route controller <NUM>.

This system <NUM> handles service degradation caused by long-term or recurrent satellite blockage or persistent, predictable traffic congestions. The two key aspects of the solution as implemented by the system <NUM> are <NUM>) use of long-term traffic patterns to perform traffic engineering; and <NUM>) use of interference data to detect service degradation and automatically move terminals from their planned uplink satellite to a different satellite.

For implementing the traffic engineering and re-routing aspect, each satellite (e.g., satellite <NUM>) is instrumented to provide periodic measurement results <NUM>, including real-time link utilization for all crosslinks and terminal link signal quality, to the route controller <NUM>. The route controller performs big-data analytics on this data to infer traffic trends and congestion hot spots. Based on the trends, core network routing is updated to relieve long-term congestion and updated forwarding tables <NUM> are sent to the satellite <NUM>.

When implementing interference detection and resolution, in addition to pre-planned handovers due to satellite (e.g., satellite <NUM>) motion, the UT <NUM> may also undergo unplanned handovers to avoid blockages. The route controller <NUM> performs big-data analytics on these unplanned handovers to infer predictable satellite blockages for the UT <NUM>. Based on the blockage analysis, the route controller <NUM> further performs big-data analytics on available location maps (terrain, city, etc.) to identify potential terminal handoffs <NUM>, for sending to the UT <NUM>, to relieve persistent or predictable service degradation. Before the UT <NUM> is moved to a different satellite (other than the satellite <NUM>), the route controller <NUM> computes the impact of this ad hoc mobility on the core network. The handoff is only confirmed if it can be accommodated without causing any potential service degradation to existing connections in the core network.

<FIG> conceptually illustrates an electronic system <NUM> with which some aspects of the subject technology can be implemented. The electronic system <NUM>, for example, can be a UT (e.g., UT <NUM> of <FIG>), a gateway (e.g., <NUM> of <FIG>), a server, a switch, a router, a receiver or any device that can control and/or perform processing of data, including aggregation of data, or generally any electronic device that transmits signals over a network. The electronic system <NUM> may also be embedded in the NGSO satellites <NUM> of <FIG> and the control center <NUM> of <FIG>. Such an electronic system includes various types of computer-readable media and interfaces for various other types of computer-readable media. The electronic system <NUM> includes bus <NUM>, Processor(s) <NUM>, system memory <NUM>, read-only memory (ROM) <NUM>, permanent storage device <NUM>, input device interface <NUM>, output device interface <NUM>, and network interface <NUM>, or subsets and variations thereof.

Bus <NUM> collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system <NUM>. In one or more implementations, bus <NUM> communicatively connects Processor(s) <NUM> with ROM <NUM>, system memory <NUM>, and permanent storage device <NUM>. From these various memory units, Processor(s) <NUM> retrieve(s) instructions to execute and data to process in order to execute the processes of the subject disclosure. The Processor(s) <NUM><NUM> can be a single processor or a multicore processor in different implementations.

ROM <NUM> stores static data and instructions that are needed by Processor(s) <NUM> and other modules of the electronic system. Permanent storage device <NUM>, on the other hand, is a read-and-write memory device. This device is a nonvolatile memory unit that stores instructions and data even when electronic system <NUM> is off. One or more implementations of the subject disclosure use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as permanent storage device <NUM>.

Other implementations use a removable storage device (such as a floppy disk or flash drive, and its corresponding disk drive) as permanent storage device <NUM>. Like permanent storage device <NUM>, system memory <NUM> is a read-and-write memory device. However, unlike storage device <NUM>, system memory <NUM> is a volatile read-and-write memory, such as random access memory (RAM). System memory <NUM> stores any of the instructions and data that Processor(s) <NUM> need(s) at runtime. In one or more implementations, the processes of the subject disclosure, for example, the trained ROM, are stored in system memory <NUM>, permanent storage device <NUM>, and/or ROM <NUM>. From these various memory units, processor(s) <NUM> retrieve(s) instructions to execute and data to process in order to execute the processes of one or more implementations. In one or more implementations, the processor(s) <NUM> execute(s) the automatic processes of the subject technology, including executing various algorithms described above with respect to <FIG>.

Bus <NUM> also connects to input device interface <NUM> and output device interface <NUM>. Input device interface <NUM> enables a user to communicate information and select commands to the electronic system. Input devices used with input device interface <NUM> include, for example, alphanumeric keyboards and pointing devices (also called "cursor-control devices"). Output device interface <NUM> enables, for example, the display of images generated by electronic system <NUM>. Output devices used with output device interface <NUM> include, for example, printers and display devices such as a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, a flexible display, a flat-panel display, a solid-state display, a projector, or any other device for outputting information. In these implementations, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user can be received in any form, including acoustic, speech, or tactile input.

Finally, as shown in <FIG>, bus <NUM> also couples electronic system <NUM> to a network (not shown) through network interfaces <NUM>. In this manner, the computer can be a part of a network of computers (such as a local-area network (LAN), a wide-area network (WAN), or an Intranet, or a network of networks, such as the Internet). Any or all components of electronic system <NUM> can be used in conjunction with the subject disclosure.

In some aspects, the subject technology may be used in various markets, including, for example, and without limitation, the signal-processing and communications markets.

Various components and blocks may be arranged differently (e.g., arranged in a different order or partitioned in a different way), all without departing from the scope of the subject technology.

It is understood that any specific order or hierarchy of blocks in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes may be rearranged or that all illustrated blocks may be performed. Any of the blocks may be performed simultaneously. In one or more implementations, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single hardware and software product or packaged into multiple hardware and software products.

The description of the subject technology is provided to enable any person skilled in the art to practice the various aspects described herein. While the subject technology has been particularly described with reference to the various figures and aspects, it should be understood that these are for illustration purposes only and should not be taken as limiting the scope of the subject technology.

A reference to an element in the singular is not intended to mean "one and only one" unless specifically stated, but rather "one or more. " The term "some" refers to one or more. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and intended to be encompassed by the subject technology. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the above description.

Claim 1:
A communication system comprising:
an non-geosynchronous orbit, NGSO, satellite constellation (<NUM>), including a plurality of satellites (<NUM>) configured to facilitate communication between a plurality of user terminals, UTs;
characterized by one or more gateways (<NUM>), each gateway configured to communicate with one or more satellites of the plurality of satellites; and
a network controller (<NUM>) configured to control operation of the plurality of satellites, the one or more gateways and the plurality of UTs,
wherein,
an address portion of a data packet in non-processing satellites of the plurality of satellites comprises a single-tuple address that indicates a destination node comprising one of a UT or a gateway,
an address portion of a data packet in processing satellites of the plurality of satellites comprises a two-tuple address comprising an inner address and an outer address, wherein a respective connection terminates in a destination UT and the inner address and the outer address comprise a UT ID associated with the destination UT and a satellite ID, respectively, and wherein the satellite ID is associated with a satellite that is currently serving the destination UT, and
the plurality of satellites, the plurality of UTs, the one or more gateways and the network controller include hardware that is configured to perform a persistent end-to-end data packet forwarding including proactive updates and reactive updates to forwarding tables, wherein the proactive updates are configured to handle deterministic and time-synchronized link connectivity changes and the reactive updates are configured to handle ad hoc link connectivity changes.