破局天基组网：卫星互联网路由的核心矛盾与进阶方向
低轨星座里的隐形死结
近地轨道上的卫星，九十分钟绕地球一圈，相对于地面接收站的位置每一秒都在变。相邻卫星之间的相对位置也在不断变化，旧的链路断开，新的链路建立，平均每十到十五分钟，整个星座的拓扑就会完成一次大换血。
低轨卫星星座动态拓扑变化示意图
地面网络的路由，拓扑结构固定，只需要处理流量拥塞的问题。放到天基，拓扑动态变化本身就是最大的问题。之前很多研究把宝押在拓扑预测上，根据卫星的轨道参数提前算出未来几小时的链路状态，预存在星上路由表。听起来很美好，实际呢？空间环境扰动会让轨道偏移几百米，太阳活动爆发会带来电离层扰动，预测出来的链路，到点根本连不上。
还有更棘手的。星间激光链路的对准要求极高，微小的轨道偏差就会导致链路丢包率飙升。要是路由不能快速切换，整个链路的数据包就要全丢。对于时延敏感的应用，比如语音通话或者应急通信，几秒的中断就等于完全不可用。
哪怕是当前已经商用的低轨系统，也只能通过星上预存拓扑表结合地面站定期更新的方式维护路径，应对突发故障和流量潮汐的弹性几乎为零。
被刻意忽略的硬约束
说实话，我看过不下百篇相关论文，十分之九都在模拟环境里跑出了很漂亮的指标，一到实际落地全抓瞎。为什么？大多都没把星上的硬约束算进去。
星载路由处理模块功耗约束对比图
一颗低轨卫星的整星功耗，大多在一百瓦以内。去掉姿控、通信、载荷的功耗，留给路由计算和数据转发的功耗，撑死也就十多瓦。对比地面核心路由器，单块板卡的功耗就超过一百瓦。你拿地面那套复杂的路由算法往星上搬，就算塞得进去，功耗扛不住，算力也跟不上。
之前有个很火的开源分布式路由方案，模拟测试里端到端时延比传统方案低30%，丢包率低40%。结果拿到在轨试验的时候，因为每一次路由更新都要全星座广播状态信息，星上处理器直接被占满，排队时延翻了六倍，根本没法用！这就是典型的只看性能指标，不看实现约束。
还有一个约束少有人提，就是天基路由的安全边界。星间链路都是开放式无线传输，路由信息很容易被截获篡改。要是给每一条路由信息都做端到端加密认证，又会额外消耗算力和带宽，进一步挤压本来就紧张的星上资源。这里的矛盾，到现在都没有完美的解法。
说到这里，就得提应用边界。很多宣传说这个能完全替代地面网络，其实不对。哪怕路由问题完全解决，城市核心区的高楼遮挡、植被遮挡，都会导致星地链路的误码率高到没法用，路由选得再优也没用。它的核心场景本来就是地面网络覆盖不到的远洋、荒漠、边远牧区，别吹得太神。
从全局预判到本地决策的新思路
从全局预判到本地决策的新思路
不过话说回来，最近两年这个方向的进展其实挺惊喜的，不再盯着全局最优路径死磕，转而往轻量化分布式的方向走。
现在比较成熟的思路，是把路由决策拆成固定部分和动态部分。同一轨道面的卫星，相对位置几乎不变，这部分的路由规则可以提前预存烧录到星上，不用动态计算。只需要处理跨轨道面的链路切换，以及局部故障的调整，一下子就把需要计算的量降了一个数量级，非常适配星上有限的算力。
另一个方向，是基于本地状态的分布式决策。每个卫星只需要收集相邻三颗卫星的链路状态和拥塞情况，不需要掌握整个星座的拓扑，直接根据预设的策略做本地选路。配合联邦学习在地面提前训练好决策模型，卫星只需要做简单的推理，不用自己从头计算，功耗和算力消耗都压得很低。
当然，这个思路也有风险。本地决策很容易出现局部最优，甚至路由环路。怎么解决？现在通用的做法是用地面的数字孪生星座提前预演，把不同流量场景、不同故障场景下的修正参数提前下发，卫星遇到对应场景直接调用参数修正，不用自己摸索。既保留了分布式的灵活性，又避免了局部决策的混乱。
现在还有很多没填上的坑。比如多层异构星座，低轨、中轨、高轨一起组网，跨层的路径怎么选？不同运营商的星座互联互通，路由怎么跨网适配？这些问题现在都还没有成熟的落地方案，也是接下来最值得挖的方向。
说白了，这个领域从来不是比谁的算法理论更优，是比谁更能适配天基平台的各种约束，能把方案实实在在放到卫星上跑起来。花里胡哨的指标没用，稳定、低功耗、能应对突发情况，才是硬道理。