低轨星座下卫星互联网路由：被忽略的动态适配难题

上个月去南京参加一个小范围的产学研沙龙，聊到低轨星座的落地卡脖子，一半人在说相控阵天线的成本，一半人在骂频段拥挤，没人提路由的问题——其实最疼的窟窿在这儿。

为什么地面那套逻辑搬不上天

地面互联网的路由逻辑，从设计之初就长在固定拓扑的土壤里。核心路由器只要算好路径，存好路由表，很长时间都不用大改，链路出问题再局部调整就行。放到天上呢？低轨卫星一小时绕地球一圈，相对于地面终端的移动速度每秒好几公里，整个星座的拓扑半小时就能全换一遍。你算一笔账，一个万颗规模的低轨星座，每颗卫星平均和四到六个邻星建立星间链路，每小时拓扑更新的次数超过十万次，地面骨干网的拓扑更新一个月才几千次，这个量级差完全不是同一个问题，拿旧方案套新问题，不卡才怪。

早年就有团队试过，把地面常用的OSPF协议改改参数就往试验星上装，结果不到十五分钟，星上存储的路由表就直接撑爆了有限的载荷存储空间，整网直接瘫掉。哪怕不爆存储，还有链路干扰的问题：卫星过南北极的时候，太阳风对信号的干扰是赤道区域的三倍以上，丢包率直接从10-6跳到10-2，原来的路由协议反应速度赶不上链路质量的波动，端到端时延能差出十倍。某商业星座早期的公开测试数据里，跨洋视频通话的时延波动超过150ms，一半问题都出在路由调整不及时。

还有个容易被忽略的限制：星上的算力和供电都是按克、按瓦抠出来的，不可能像地面数据中心那样堆万兆级的处理能力，动辄几十万条的全局路由条目，星上根本跑不动。

现在的主流解法都卡在什么地方

目前行业里试的最多的是两条路子，各有各的死结。

第一类是预设拓扑快照路由，依靠卫星轨道可预测的特点，提前几个小时把不同时间段的拓扑算好，把路由表提前预存到每颗卫星上，到点直接切换。听起来逻辑顺，应对常规的移动变化没问题，可碰到突发状况直接抓瞎。要是某颗卫星被空间碎片打坏了太阳能板，降功率运行甚至直接脱轨，整个预设的路由路径全断，等地面站重新计算发新的路由表，至少要好几分钟，这段时间覆盖区域就是通信空白。之前看到过国内团队的测试数据，预设路由方案应对单星故障的恢复时间，平均是分布式方案的8倍，对于时延敏感的业务根本没法用。

第二类是分布式按需路由，需要传数据的时候才临时寻路，不用存全局路由表，省了星上的存储和算力。可问题是寻路的信令开销太大，实测下来信令能占到星间链路总带宽的三成左右，本来星间链路的带宽就远不如地面光纤，三分之一的容量都用来走寻路的信令，实际能给用户用的带宽剩不下多少，根本不划算。

还有一个共性的问题，大部分方案都依赖地面站做全局计算，要是走到没有地面站的区域，比如太平洋中部、南极腹地，这些恰恰是最需要卫星通信补盲的地方，路由更新延迟直接翻十几倍，业务中断率是内陆有地面站区域的17倍。说实话，很多做方案的都默认地面站能均匀覆盖，真到了需要卫星发挥价值的地方，这套逻辑就不灵了。

破局的可能方向在哪

最近两年看到几个新的尝试，慢慢摸到了点解决问题的门道，不过都还没到大规模落地的程度。

第一个方向是轻量AI在线预测路由，不再走预设快照或者临时寻路的老路，给每颗星上放一个剪枝压缩后的小模型，根据历史拓扑变化规律和当前的链路质量，提前十秒预测接下来的拓扑变化，提前调整好路由路径。国内几个高校团队的测试结果显示，这个方案能把业务中断率降到传统预设方案的五分之一，端到端时延的波动也缩小了六成。但限制也很明显，星上算力撑不起大模型，目前预测准确率最高也就到95%左右，剩下5%的极端场景还是会出问题，怎么在模型大小和准确率之间找平衡，还在磨。

第二个方向是区域分簇分层路由架构，把同一轨道面相邻的几颗卫星划成一个簇，小的故障和拓扑变化就在簇内部自己解决，只有跨簇传输或者簇结构变化的时候才需要更新全局路由。这么做下来，全局路由表的大小能降到原来的十分之一，信令开销也砍了一半多，大大减轻了星上的负担。可问题出在簇边界切换，刚好有大流在传的时候卫星移出了当前簇，还是容易出现丢包，现在还在优化切换的触发机制。

还有一个更激进的方向，就是改底层编址逻辑，不用传统的基于设备的IP编址，改成基于地面地理位置的编址，不管卫星怎么动，用户找的是地面某个位置的通信服务，不是某颗卫星的地址，从根子上省去了拓扑频繁更新的必要。不过这个相当于要动整个互联网的基础架构，现有终端设备都不兼容，落地难度可想而知。不过话说回来，真要做一张完全独立的全球卫星通信网，说不定就得从根子上动。

说句实在的，现在大家都在比谁发的卫星多，谁的覆盖广，很少有人沉下心抠路由的细节，可卫星互联网本质还是通信，通信的核心就是把数据从A点传到B点，路不通，发再多卫星都是天上的废铁。这个领域的坑，还得有人一个一个踩过去。