NGSO Satellite Routing via Decoupled Route Tables
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current routing solutions for NGSO satellite systems, which rely on real-time calculations and updates for satellite Internet Protocol (IP) routers, do not scale well due to the high frequency of handovers caused by non-stationary orbits and relative satellite motion, leading to computational overhead and potential system failures.
Innovation Solution
Implementing user route tables and pre-calculated backbone route tables that decouple the computational burden, allowing satellites to select different backbone route tables based on time-varying topology changes and update user route tables independently, reducing real-time information exchange and computational load.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If real-time link-state routing calculations are implemented using IP routers onboard satellites, then routing information can be dynamically updated, but the computational burden increases significantly and the system does not scale well to large numbers of satellites
Solution Approach 1:
The routing system is segmented into two distinct components: backbone route tables that define pre-calculated satellite-to-satellite paths, and user route tables that track user-to-satellite connectivity. This segmentation allows each component to be optimized independently, reducing the overall computational burden while maintaining routing accuracy.
Solution Approach 2:
Backbone route tables are pre-calculated and stored onboard satellites before operation begins. These tables contain advance routing information for satellite-to-satellite connections, eliminating the need for complex real-time calculations during operation. The ground controller performs these calculations in advance when the network topology is known or predictable.
2Adaptability or versatility
If real-time routing calculations are performed by a centralized management system, then routing information can be updated dynamically, but the system becomes vulnerable to failure when the management system cannot perform calculations
Solution Approach 1:
Multiple backbone route tables are pre-calculated for different network topologies and time periods, and stored onboard satellites. When the management system is unavailable or cannot perform real-time calculations, satellites can autonomously select and use the appropriate pre-calculated backbone route table based on current conditions, ensuring continuous operation without centralized control.
Solution Approach 2:
The system dynamically selects among multiple pre-calculated backbone route tables based on current network conditions and satellite positions. This dynamic selection capability provides adaptability similar to real-time calculations while relying on pre-computed data, reducing dependence on continuous management system operation.
3Measurement precision
If link-state routing with frequent updates is implemented, then routing information remains current, but the amount of real-time information exchange between satellites and ground assets increases
Solution Approach 1:
Backbone route tables are pre-calculated and stored onboard satellites before operation. This eliminates the need for frequent real-time exchange of routing information between ground assets and satellites. User route tables are updated less frequently based on user connectivity changes rather than continuous topology updates, significantly reducing information exchange volume.
Solution Approach 2:
By separating backbone routing information from user connectivity information, the system can update each independently at appropriate frequencies. Backbone route tables remain stable and are updated only when network topology changes significantly, while user route tables are updated based on user mobility patterns. This segmentation reduces the overall update frequency and information exchange compared to traditional link-state routing that requires continuous updates of all routing information.
Data Source
Figure 1
Figure 2A~2B
Figure 3
AI summary
A Non-Geostationary Satellite Orbit (NGSO) satellite system is described that implements one or more user route tables and a plurality of pre-calculated backbone route tables at its satellites. The user route tables track user connectivity to the satellites, and each of the backbone route tables defines a snapshot of a time-varying backbone topology seen by a particular satellite. During operation, a satellite selects different backbone route tables as the topology changes over time, and receives updates to the user route tables when connectivity changes occur between the users and the satellites. The decoupling of the user route tables from the backbone route tables at the satellite reduces the computational burden on the NGSO system, as the backbone route tables are calculated in advance and the NGSO system is subsequently tasked with a computationally lower burden of performing real-time updates to the user route tables.