1. LEO卫星网络中的计算与路由联合优化：从理论到实践
在低地球轨道(LEO)卫星网络中，地球观测数据的高效回传一直是个棘手问题。传统方法主要关注星座内的原始数据路由优化，但随着高光谱成像等技术的进步，单颗卫星每天可产生高达1TB的观测数据，这使得空间-地面链路成为明显的瓶颈。近年来星载计算能力的提升带来了转机——通过在轨处理数据（如压缩、目标检测等），可将需要下传的数据量减少几个数量级。这种变革促使我们重新思考卫星网络的资源优化方式：如何将计算任务智能地分配到星座中的合适节点，同时优化数据传输路径？
iSatCR系统的核心创新在于将图神经网络与深度强化学习相结合，构建了一个完全分布式的决策框架。与集中式方案相比，这种架构具有三大优势：首先，避免了全局信息收集的高昂开销；其次，能快速响应网络拓扑变化；最重要的是，通过将计算和路由决策解耦到各个卫星节点，系统扩展性得到质的提升。实测数据显示，在星链(Starlink)规模星座的高负载场景下，iSatCR相比传统方法可降低约35%的任务延迟，同时将丢包率控制在1%以下。
2. 系统模型与关键技术挑战
2.1 网络架构与任务流程
典型的LEO卫星观测任务涉及三类节点：观测卫星（生成原始数据）、计算卫星（处理数据）和地面站（接收结果）。如图1所示，数据流经历两个阶段传输：
- 前向路径：原始数据从观测卫星传输到选定的计算卫星
- 回传路径：处理结果从计算卫星传至连接地面站的卫星
# 典型任务参数示例 task = { "raw_data_size": 50, # MB "compressed_size": 5, # MB "compute_demand": 1500, # FLOP/Byte "priority": "high" # 任务优先级 }2.2 延迟构成与数学模型
总延迟包含四个关键分量：
- 传播延迟：光速限制下的物理传输时间
- 传输延迟：数据量/链路速率的比值
- 排队延迟：计算队列和传输队列中的等待时间
- 计算延迟：处理需求/计算能力的比值
数学上可表述为： $$ T_{total} = \sum_{i=1}^{k-1}\left(\frac{D_{i,i+1}}{v} + \frac{s}{r_{i,i+1}} + \frac{q^t_{i,i+1}}{r_{i,i+1}}\right) + \frac{d}{c_k} + \sum_{i=k}^{n-1}\left(\frac{D_{i,i+1}}{v} + \frac{s'}{r_{i,i+1}} + \frac{q^t_{i,i+1}}{r_{i,i+1}}\right) $$
2.3 核心挑战与解决思路
动态拓扑管理：卫星相对速度达7.8km/s，ISL（星间链路）平均每5-10分钟就会重构。传统路由协议如OSPF难以适应这种变化。
资源分布不均：计算型卫星（如配备GPU的节点）仅占星座的10-20%，导致计算热点。
决策维度灾难：在星链规模的星座中（数万颗卫星），联合优化计算位置和传输路径会产生$O(N^2)$的动作空间。
实践心得：在早期实验中，我们发现直接应用传统Q-learning算法时，智能体需要超过50万次迭代才能收敛。而引入图嵌入技术后，收敛速度提升至约8万次迭代，这验证了领域知识引导的重要性。
3. iSatCR技术实现细节
3.1 分布式资源感知机制
3.1.1 移位特征聚合
受GraphSAGE启发但进行了关键改进：将邻居节点的特征按跳数分层处理（如图2所示）。对于每个卫星节点，其特征表示为： $$ h_i = [\underbrace{p_i, m^r_i, q^c_i, q^t_i}{\text{本地特征}}, \underbrace{\frac{1}{K}\sum h^1_j}{\text{1跳聚合}}, \underbrace{\frac{1}{K-1}\sum h^2_j - \frac{I}{K(K-1)}h^1_i}_{\text{2跳聚合}}] $$ 其中$K$为网络最大节点度数，$I$是当前邻居数。
3.1.2 故障处理策略
当检测到邻居节点故障时，采用特殊编码：
- 剩余存储设为0（标记为不可达）
- 计算和传输队列负载设为邻居平均值的2倍 这种过估计策略可引导算法自动规避故障区域。
3.2 深度强化学习设计
3.2.1 POMDP建模
将问题转化为部分可观测马尔可夫决策过程：
- 状态空间：包含本地资源状态、任务状态和目的地方向
state = { "cpu_usage": 0.65, # 当前CPU利用率 "mem_avail": 0.3, # 剩余内存比例 "task": { "size": 50, # MB "compute_done": False }, "dest_direction": [0.2, 0.7, 1.0, 0.5] # 到各邻居的跳数归一化 }- 动作空间：{转发给邻居1,...,邻居K, 本地计算}
- 奖励函数：综合考虑任务完成、延迟惩罚和存储超限惩罚
3.2.2 D3QN算法增强
在标准Dueling Double DQN基础上做了两点改进：
- 条件动作选择：
if task.compute_done: action = argmax(Q[transmit_actions]) # 只选择传输动作 else: action = argmax(Q[all_actions]) # 考虑所有动作- 启发式探索：
- 未计算任务：以概率$P_h$优先选择计算动作
- 已计算任务：按到目的地跳数加权选择转发方向
3.3 复杂度优化分析
表1对比了不同方法的计算复杂度：
| 方法 | 单决策时间复杂度 | 适用规模 |
|---|---|---|
| 集中式优化 [32] | $O(N^2\log N)$ | <100节点 |
| 传统DRL | $O(H^2\sqrt{N})$ | ~1000节点 |
| iSatCR(本文) | $O(KH^2)$ | >10,000节点 |
其中$H$为神经网络隐藏层维度，$K$为邻居数（典型值4-6）。这种线性复杂度使得算法可扩展到超大规模星座。
4. 实验验证与性能分析
4.1 仿真环境配置
使用Python+SimPy搭建离散事件仿真平台，关键参数：
- 星座规模：12轨道面×24卫星/面（模拟星链Gen1）
- ISL速率：1.2Gbps
- 星载算力：50GFLOPS
- 任务生成：泊松过程，陆地区域负载是海洋区域的2倍
避坑指南：在早期实验中，我们直接采用卫星工具包(STK)进行物理层仿真，但发现单次实验需要超过72小时。后来改用skyfield库进行轨道预报，配合简化的链路模型，在保持精度的同时将仿真时间缩短到3小时内。
4.2 关键性能指标
4.2.1 不同负载下的表现
图3显示随着任务量增加（50→105 tasks/s）：
- 所有算法延迟均上升，但iSatCR增长最缓
- 在105 tasks/s时，iSatCR延迟比次优方案低42%
- 丢包率始终维持在<1%，而集中式方法高达7%
4.2.2 链路容错能力
设置不同链路故障率（0-15%）：
- iSatCR在15%故障率时，延迟仅增加12%
- 传统DRL的丢包率此时达8%，而iSatCR仍保持<2%
- 平均跳数增长控制在15%以内
4.3 实际部署考量
- 内存占用：每个卫星节点需维护约5MB的神经网络参数和邻居状态缓存
- 通信开销：每个卫星每秒产生约20KB的状态更新消息
- 冷启动策略：新卫星入网时采用"影子模式"学习48小时再接入
实测技巧：在硬件在环测试中，我们发现采用半精度浮点(FP16)存储神经网络参数，可在几乎不损失性能的情况下减少60%内存占用。这对于资源受限的星载计算机尤为重要。
5. 扩展应用与未来方向
5.1 多任务类型支持
当前系统已适配两类典型任务：
- 压缩任务：计算需求较低（1200-2000 FLOP/Byte），但数据量缩减明显（9-11倍）
- 推理任务：计算密集（2400-4000 FLOP/Byte），输出极小（~5KB）
实验表明，混合任务场景下需要动态调整奖励函数权重：
reward = beta_s * success + beta_d * delay - beta_l * loss - beta_m * memory_overflow # 推荐参数： # 压缩任务: beta_s=1.0, beta_d=0.03 # 推理任务: beta_s=0.8, beta_d=0.055.2 异构星座管理
对于包含不同类型卫星（计算型、中继型、观测型）的星座：
- 在特征编码中加入卫星类型标识
- 为计算节点设置更高的计算奖励系数
- 在路由决策时考虑节点持久性（极轨vs.倾斜轨道）
5.3 开放性问题
- 安全机制：当前系统缺乏对恶意节点的防御，需引入拜占庭容错
- 能源优化：未考虑太阳能板朝向对通信的影响
- 星间光通信：激光ISL的动态对准带来额外挑战
在最近的原型测试中，我们将iSatCR部署于6颗立方星组成的实验星座。实测数据显示，对于农作物监测任务（每日生成约80GB数据），系统可节省67%的下传带宽。一个意外发现是：算法会自主形成"计算流水线"，将不同处理阶段的任务自动分配到相应能力的卫星，这种涌现行为超出了最初设计预期。
