卫星互联网路由：低轨星座落地的隐形卡点
低轨星座的天然矛盾
地面互联网的路由器，插上线十年不用动，拓扑结构刻在那，顶多哪条光缆断了临时改改。低轨不一样。
近地轨道的卫星，线速度超过7km/s，绕地球一圈也就一个多小时。对，不到一百分钟，你喝一杯咖啡的功夫，整个星座的拓扑结构已经换了三茬。星间链路今天连A明天连B，邻居隔十分钟就换一次。
动态拓扑的高频变化，是天生甩不开的包袱。地面路由的那套最短路径算法，直接搬上来，用不了十分钟，整个网络的路由信令就能把带宽占满。每颗星都要广播自己最新的链路状态，算一次路径要攒齐所有卫星的数据，算完的时候，拓扑已经变了。
低轨卫星星座动态拓扑变化示意图
就是这么尴尬。有人说，那把算力放卫星上，星上实时算不行吗？说实话，星上的功耗和算力都是按瓦算的，一块太阳能板发的电，要分给通信、要分给姿态控制，留给计算的不到十分之一。你带个顶级服务器上去，散热都搞不定，没俩月就坏了。
现有方案的隐形局限
现在行业里主流的两类方案，各有各的死穴。
第一类是预计算路由，基于轨道动力学可预测性，把未来几小时的拓扑都算出来，提前把路由表存到每个卫星上，到点切换。听着很完美对不对？问题出在异常情况。只要有一颗卫星故障掉链，或者太空碎片打歪了一个天线，预存的整张路由表直接报废。去年某商业星座测试的时候，就出过这么一档事，两颗卫星姿态异常，整个覆盖区的网络断了三个多小时，就是因为预计算的路径用不了，地面来不及重新下发整张表。
第二类是分布式自适应路由，每个卫星自己算邻区的路径，不用全局同步。这个解决了异常问题，但带来了新的麻烦：信令开销太大。每颗星都要定期发自己的状态，哪怕拓扑没变化，你也得发，不然邻区不知道你还在不在。实测下来，这类方案最多能吃掉30%的星间链路带宽，本来星间链路容量就不大，三分之一拿去算路由，留给用户的还剩多少？
卫星分布式路由协议链路开销对比图
还有不少人提过把高轨卫星当核心路由器，低轨做接入，听起来逻辑通顺，其实延迟直接翻了一倍还多。本来低轨的优势就是距离近延迟低，你绕去高轨转一圈，那不如直接用高轨卫星通信了，折腾低轨干嘛？
破局的可能与边界
破局的可能与边界
这两年不少研究团队在找中间路，其中比较有潜力的方向，是分段动态路由。说白了，就是把整个星座的路径切成若干小段，每段只在小段内同步路由状态，不需要跑全局信令。既降低了开销，异常的时候只需要重算坏的那一段，不用动整个路径。
这个方案目前的限制也很明显，分段点选在哪里，至今没有最优解。选在轨道面交界？同一轨道面的卫星相对位置稳定，交界的地方位置变化最快，换邻居换得勤。选在纬度分界？低纬度和高纬度的卫星速度一样，过境时间不一样，也不对。现在测试下来，最好的结果是比预计算方案丢包率降了40%，比分布式方案开销降了25%，但离商用的车载通信、实时视频传输要求，还差得远。
另一个方向是用机器学习做拓扑预测，提前预判异常，预留冗余路径。这个的问题，就是小样本下泛化性差，太空的异常情况千奇百怪，太阳风爆一下，卫星轨道变个几公里，之前训练的模型就不准了。
其实很多人没意识到，这个问题的本质，是把本来在地面做的事，搬到了一个资源极度受限、环境动态变化的分布式系统里，所有地面的经验都要打折扣。很多吹得天花乱坠的方案，一到天上实测，全不是那么回事。
从应用边界来看，目前成熟的方案，只能满足低速率的广域物联网需求，比如远洋船舶的位置上报，偏远地区的传感器数据回传，这类对延迟、丢包要求都不高的场景。真要替代地面的移动覆盖，给民用手机上网，路由这关就过不了。切换的时候动辄几百毫秒的中断，十几percent的丢包，刷短视频都卡，谁用？
现在很多商业化的宣传，故意把这个问题藏起来，好像卫星发上去就有能用的网，其实不是那回事。太空组网的路，还有大半没走，这就是最费脚的那一段。