LEO network design from scratch¶

With the preceding background, we now delve into the LEO trajectory design problem, along with the research challenge of high dimensionality.

Problem statement: We define our problem statement as follows – given the number of satellites (which is our network budget), location of GSes, and traffic demand matrix across these GSes, we need to find the constellation design parameters of one or more shells (s) and their operational altitude (h), inclination (i), minimum elevation angle (e), number of orbits (o), satellites per orbit (n), and the phase offset (p) between satellites in adjacent orbits that maximize some objective function such as throughput, coverage, latency, or a combination of these. However, in this work, we focus on a performant constellation that maximizes the throughput. Higher throughput produces more salable bandwidth, which might fetch higher revenue for the constellation operator.

The curse of dimensionality: Therefore, in a megaconstellation of multiple shells, a brute-force grid search approach to find near-optimal design parameters will require the execution of | s | × | h | × | i | × | p | × | o | × | n | × | e | × | t | simulations, where | x | means number of distinct choices of parameter x, and | t | denotes the number of epochs over 24 hours (one complete rotation of Earth) to estimate the performance fluctuation for LEO dynamics. Each simulation involves generating a network graph, calculating link budgets, computing routes globally, and evaluating network performance. That could take from a few minutes to hours or even days, depending on the number of satellites and GSes in the constellation. Therefore, executing these many simulations with many computational cores could take years.

Can we prune the search space? Given the large search space, meta-heuristic methods like Simulated Annealing [85], Differential Evolution [83], and Adaptive Particle Swarm Optimization [81] can offer near-optimal solutions. In addition, we leverage domain knowledge and heuristics related to the design parameter's impact on network performance to reduce the search space significantly. Our comprehensive analysis of design parameters highlights their performance characteristics and inter-dependencies. This insight refines meta-heuristic approaches. Further enables tuning of local search strategies to outperform out-of-the-box meta-heuristics.

这部分(Section 3: 从零开始设计 LEO 网络)是全文承上启下的枢纽段落.

它将现实中的卫星建设需求, 转化为可以通过数学和算法求解的"优化问题", 并点明了直接求解的不可行性以及本文的破局思路.

这一章的逻辑非常清晰: 我们要解什么题 -> 为什么这题硬算算不出 -> 我们打算怎么取巧解题

(1) Problem Statement

我们要解决什么问题?

核心任务: 在已知卫星总预算(数量), 地面站(GS)位置以及这些地面站之间的流量需求矩阵的前提下, 寻找一组最优的星座设计参数.
参数范围: 这组参数涵盖了壳层数 (\(s\)), 运行海拔 (\(h\)), 倾角 (\(i\)), 最小仰角 (\(e\)), 轨道数 (\(o\)), 每轨道卫星数 (\(n\)) 以及相邻轨道间的相位偏移 (\(p\)).
优化目标:
- 虽然可以优化覆盖率或延迟等指标, 但本文明确将优化目标聚焦于"最大化吞吐量(Throughput)"
- 因为在商业逻辑上, 更高的吞吐量意味着能提供更多可售卖的网络带宽, 从而为星座运营商带来更高的收入

(2) The Curse of Dimensionality

为什么这题硬算算不出?

指数级爆炸的计算量: 如果采用朴素的暴力网格搜索法(Brute-force grid search)来遍历寻找这 7 个参数的最优组合, 其需要执行的仿真总次数为 \(|s| \times |h| \times |i| \times |p| \times |o| \times |n| \times |e| \times |t|\)(其中 \(t\) 代表 24 小时内的多个时间切片/Epochs, 用于评估 LEO 动态运动带来的性能波动).
不堪重负的单次仿真成本: 每一次仿真都不是简单的数值计算, 而是需要动态生成巨大的网络拓扑图, 计算链路预算(Link budgets), 在全局范围内计算路由(Routing), 最后再评估网络性能.
不可接受的时间成本: 面对包含多壳层的巨型星座, 这种庞大的计算量即使动用海量的多核计算资源, 也可能需要耗费数年时间才能跑完.

(3) Pruning the Search Space

我们打算怎么取巧解题?

常规解法: 针对这种高维搜索空间, 通常可以使用开箱即用的元启发式算法(Meta-heuristic methods), 如模拟退火算法(SA), 差分进化算法(DE)或自适应粒子群优化算法(A-PSO)来寻找次优解.
本文的高阶解法: 作者并没有单纯依赖这些黑盒算法, 而是:
- 提出利用"领域知识(Domain knowledge)"和对参数特性的"启发式理解(Heuristics)"来大幅度裁剪搜索空间
- 通过前置分析各个参数对网络性能的具体影响和相互依赖关系, 不仅可以缩小搜索范围, 还能针对性地调整局部搜索策略, 最终使优化效率和结果超越传统的现成算法.