想象你住在一座没有地面道路的大都会里,整座城市的交通全凭地铁网完成。人们把信件交给离自己最近的一班列车,列车并不直达目的地,而是在站台交汇处把信件递给另一趟车,再由那趟车接力前行。最特别的是:这条地铁网的轨道是固定的,时刻表也是完全可预测的,但列车永远在运动中——交接信件只能在两车擦肩而过的短暂窗口内完成。 这就是星间链路路由的缩影。在太空里,成百上千颗卫星像地铁列车一样沿着固定轨道飞驰,它们之间没有光纤、没有基站,只能靠激光或微波在“交汇窗口”内短暂互联。一个从北京地面站发出的数据包,要到达纽约地面站,往往需要七八颗卫星接力。关键问题随之而来:每一跳该把数据包交给谁?什么时候交?走哪条线路时延最短、拥塞最少?——这正是星间链路路由要回答的。 好消息是,卫星运动远比地铁更守时。开普勒定律让每颗卫星的轨迹像钟表一样精确可预报,于是路由工程师可以像查阅地铁时刻表一样,提前算出未来任意时刻的星座拓扑。基于这个前提,地面网络积累多年的路由技术被重新发明:快照法、虚拟拓扑、时变图模型……它们共同撑起了 Starlink、OneWeb 这类巨型星座的太空互联网。 本文用“地铁接力送信”贯穿始终:从路由的基本概念讲到星间链路的特殊脾气,从动态拓扑建模讲到关键算法与优化策略,最后落回真实的星座工程。读完你会发现,太空中的“快递分拣”并不神秘,它只是把地面上的一套成熟经验,搬进了一个永远在动的坐标系。
理解星间链路路由,是进入卫星互联网、天地一体化网络领域的第一把钥匙。无论你是网络协议工程师、星座系统架构师,还是 AI+ 通信方向的研究者,这套“动态拓扑下的路径决策”思想直接决定你的技术下限。掌握它,你就能看懂 Starlink 如何让数千颗卫星协同工作,也能在设计下一代空间网络时做出合理的架构取舍。
可视化演示
动态展示星间链路类型与拓扑、动态拓扑路由算法、AI增强路由优化与链路中断重路由机制。
本节配有交互动效(进入视口后自动加载,约 3KB)。
路由基础概念
地铁送信的起点,是搞清楚“把信交给谁、在哪交接”。如果城东的 A 站要把信件送到城西的 F 站,中间会经过 B、C、D、E 几个换乘枢纽。乘客可以选 A-B-C-F,也可以选 A-D-E-F,甚至绕一个更大的圈。路由,就是替每一封信决定“最优换乘方案”的那套规则——它要回答三个问题:路径怎么选、依据什么标准选、由谁来选。
把画面搬到太空:地铁站变成了卫星节点,固定轨道就是“线路”,数据包就是信件。一颗卫星通常只能与同轨道前后相邻的两颗卫星,以及邻近轨道面上距离最近的一两颗卫星建立星间链路(Inter-Satellite Link,ISL)。路由算法的任务,就是在这些“运动中的换乘站”之间,为每个数据包选出一条从源卫星到目的卫星的转发路径。注意,这里没有“直达车”——低轨卫星的轨道周期约 90 分钟,任何两颗星的相对位置都在快速变化,路径必须不断重算。
选路不能拍脑袋,得有一把度量尺子。最常用的指标是端到端时延——信件从上车到最终到站的总耗时。此外还有跳数(接力次数)、链路带宽利用率、丢包率等。星间场景下,传播时延占绝对主导:两颗卫星之间动辄上千公里,光速再快也要几毫秒。这与地面光纤网络“排队时延为主”的画像是完全不同的。
对照地铁场景——发送时延像乘客刷卡进站排队,传播时延像列车在隧道里飞驰的时间,处理时延像换乘时看清指示牌的一两秒,排队时延则像早晚高峰在站台苦等。四段加起来,才是“信件从口袋到收件人”的总耗时。理解了这把尺子,后面所有算法和优化,本质上都是在跟这四项时延博弈。
- 发送时延数据包在卫星发射机里“排队出门”的时间,等于数据包大小除以链路速率。
- 传播时延电磁波在星间距离上“飞行”的时间,等于星间距离除以光速。
- 处理时延卫星检查路由表、决定下一跳的“思考”时间,由星上处理器性能决定。
- 排队时延数据包在转发队列中等待的“等红灯”时间,随网络负载增大而增长。
星间链路特征
地铁接力送信最棘手的一点是:换乘点会消失。A 车和 B 车只在 10:03 到 10:05 在 X 站交汇,错过这个窗口,就只能等下一班,或者改走另一条线。卫星网络比这更极端——星间链路本身就是两车交汇时短暂握手的产物,链路随时在建立、在断开、在切换。
这种动态性来自三个物理事实。第一,卫星以每秒 7 公里左右的速度绕地球飞行,两星相对位置每秒钟都在变;第二,星间链路依赖视线传播(激光)或定向波束(微波),彼此可见且距离足够近时才能建链,一旦视线被地球遮挡或距离超限就立即中断;第三,低轨星座绕地一圈只需约 90 分钟,也就是说,整张网络的“形状”每 90 分钟就完成一次循环。用行话说:拓扑是时变的,但周期可预报。
除了动态拓扑,星间链路还有两个“穷脾气”。一个是资源受限:卫星受体积、重量、功耗约束,星上处理器远不如地面数据中心,存储和算力都很紧张,跑不动太复杂的路由算法。另一个是长时延:两星相距 1000 到 5000 公里,单跳传播时延约 3 到 17 毫秒——对比地面网络,这个数字意味着路由协议不能像地面上那样频繁地握手确认,否则光是确认消息就把链路占满了。
如果把地面网络比作灯火通明的固定邮局,卫星网络就是一群在高速公路上边跑边递包裹的快递员。包裹不能慢悠悠地等,因为下一秒快递员可能就驶出了视线范围。设计路由算法,必须时刻记着这四个字:短、变、频、紧——时延短不了、拓扑变不停、链路频切换、资源紧巴巴。理解了这些“宇宙级脾气”,再看后面的建模和算法,就明白为什么不能简单照抄地面路由了。
- 星间距离相邻可建链卫星之间的距离,低轨星座典型值 1000~5000 公里。
- 光速电磁波在真空中的传播速度,约等于 \(3\times 10^8\) 米/秒。
- 传播时延两者相除,得到单跳约 3 到 17 毫秒。
动态拓扑建模
既然地铁时刻表是公开且确定性的,调度员就可以把一天中所有换乘窗口提前画在一张大表上:哪两趟车、在哪个站、什么时间交汇、窗口持续几秒。有了这张表,送信方案就能提前规划。卫星网络也一样——轨道力学的可预报性,是星间路由最宝贵的资产。
数学上,我们用一个时变图来描述这张不断变化的网络。图的节点是卫星(基本不变),图的边是当前时刻可用的星间链路(每时每刻都在变):
时变图虽然精确,却不好算——路由算法普遍假设网络是静态的。工程师的解法很朴素:快照法。把连续时间切成一个个小片段,在每个片段内近似认为拓扑不变,对每个“静态快照”运行经典路由算法,再把结果按时间顺序串起来,就得到一条完整的时空路径。把未来所有时刻的快照连同路由结果预先算好、存成一张 连接规划表(connection plan),卫星在轨运行时只需查表,就像乘客照着时刻表换乘一样省心。
回到地铁比喻:时变图是“列车实时运行图”,快照是“把一天切成 1440 个一分钟、每分钟画一张静态图”,连接规划表则是“提前印好的换乘手册”。这套“以确定性对抗动态性”的思路,是整个星间路由大厦的地基——后面讲到的虚拟拓扑、多径备份,都是在这块地基上盖起来的。
- 节点集合星座中所有卫星的集合,在星座建成后通常保持不变。
- 链路集合\(t\) 时刻所有可用星间链路的集合,随卫星相对位置不断增删。
- 周期重复由于卫星轨道周期运动,拓扑每隔一个回归周期 \(T\) 就重复一次。
路由算法分类
拿到换乘手册后,还需要决定:由谁来制定换乘方案?这个决策权放在哪里,直接决定了系统的效率和灵活性。路由算法按照“是否随拓扑变化而调整”和“由谁决策”两个维度,可以分成四大门派。
按是否适应拓扑变化分:静态路由像一本固定印制的换乘手册——假设网络拓扑长期不变,提前算好路径,运行时不做任何调整。它在卫星相对位置稳定的场景(如高轨道)勉强够用,但在低轨星座里很快过时。动态路由则像实时导航——拓扑一变,马上根据当前链路状态重新计算路径,适应性强,但消耗更多星上算力和信令带宽。
按决策者位置分:集中式路由把决策权交给地面控制中心(或某颗主星),由它统一计算全网路由再下发。优点是全局最优、计算能力强;缺点是依赖地面站可见窗口,链路断开时更新滞后。分布式路由让每颗卫星只跟邻居交换信息、各自决策,像每个车长凭对讲机协调,反应快、抗毁性强,但容易陷入局部最优,需要精心设计协议来收敛。
用开地铁公司来理解:静态路由是“线路图印好就不改”,动态路由是“出了故障马上跳站”,集中式是“总调度中心统一指挥”,分布式是“每个站长自行协调列车”。大型低轨星座通常采用“动态 + 分布为主、集中式为辅”的混合架构——既要有全局视野,又不能把命运全部押在地面站身上。这一节帮你看清格局,下一节就钻进具体算法里看看它们怎么工作。
- 静态与动态静态路由预先计算、运行时固定;动态路由根据实时链路状态重算。
- 集中与分布集中式由中心统一计算后下发;分布式由各节点交换信息自行决策。
- 组合决策真实星座方案在这四个象限间权衡,形成混合策略。
关键路由算法
有了分类的坐标系,接下来认识四个真正的“算法主角”。它们就像地铁调度员手里的四套工具:最经典的是最短路径算法(Dijkstra),它解决“给定一张静态图,怎么走最近”的问题;链路状态路由让每颗卫星广播自己知道的链路信息,全网据此构建一致的拓扑视图;虚拟拓扑路由利用轨道周期性,把未来一段时间的快照预先算成一张“虚拟的静态图”;多径路由则同时维护两条以上可用路径,主路断了立刻切换备份。
Dijkstra 是整套工具的灵魂。它的核心操作叫松弛:从源点出发,逐个考察邻居,每发现一条“经 u 到 v 更短”的路线,就更新 v 的距离记录,像比价一样不断压低上限。
在星间场景中,链路权重 \(w(u,v)\) 通常取传播时延或综合考虑时延与剩余带宽的代价。Dijkstra 给出的是单跳代价最小的路径,但它假设图是静态的——所以实际工程中,Dijkstra 通常是跑在“快照图”上的:每个快照时刻重算一次,配合虚拟拓扑的预规划表,把计算压力从在轨卫星转移到地面,星上只需查表。
换乘手册翻到这一页:Dijkstra 是“怎么换乘最近”的精确算法,链路状态广播是“让所有车长手里都有一份全线实时图”,虚拟拓扑是“把未来一周的换乘方案提前印好”,多径则是“多备一条备选路线防止临时堵车”。四个工具各司其职,组合起来就构成了一套完整的星间路由协议栈。
- 当前最短距离\(d(v)\) 记录源点到 \(v\) 目前已知的最短距离,初始为无穷大。
- 邻居绕行距离\(d(u) + w(u,v)\) 表示先走最短路到 \(u\),再经链路 \(u \to v\) 到达。
- 取较小者新旧两条候选路线比价,谁短谁留下,这就是“松弛”。
性能优化策略
地铁运营得好不好,不只看一趟车跑得快不快,还要看整张网络挤不挤、稳不稳、费不费电。星间路由的性能优化,同样是一道多目标均衡题。时延优化是核心目标:通过选择传播时延小的路径、减少不必要的跳数,把端到端时延压到最低。但单看时延会出问题——所有人都挤向最短路径,最短路径立刻变成最堵路径。
于是负载均衡登场。它的思路不是让某条链路吃撑,而是让全网链路利用率尽量均匀,避免“热点卫星”成为瓶颈。数学上的典型做法是:最小化全网最拥塞链路的利用率,也就是“别让最惨的那条路更惨”。可靠性保障则考虑链路中断:一颗卫星进出阴影、姿态调整或激光失锁都会导致链路瞬时失效,必须通过多径备份和快速重路由来兜底。能耗优化也不能忽视:星上能源来自太阳能,但进出地影时会断电,路由算法若能主动避开“低电量卫星”,就能延长星座整体寿命。
在实际系统中,优化目标往往是一个加权和:时延、均衡、可靠、能耗各占一个权重,由运营策略动态调节——紧急通信时调高时延权重,平时则更重视均衡和能耗。这就像地铁公司在高峰期加密班次、平峰期降耗运行一样,一张换乘手册背后,是无数次的权衡与折中。把这些目标写进路由算法的代价函数,是神经网络、强化学习等 AI 方法在卫星网络中最好的切入点。
- 链路流量链路 \(l\) 上当前承载的数据量。
- 链路容量链路 \(l\) 的最大带宽。
- 链路利用率流量除以容量,反映这条链路“挤不挤”。
- 最小化最大利用率对全网所有链路求最大值,再让它尽量小——均衡的目标。
应用与挑战
把视线拉回现实世界。今天,星间链路路由已经不是论文里的概念,而是正在天上运行的工程。大型星座组网是最典型的应用:Starlink 已有数千颗低轨卫星在轨,通过激光星间链路组成太空骨干网,数据包可以在几十毫秒内从地球上任意一点到达另一点——覆盖了海底光缆够不到的海洋、沙漠和极地。OneWeb、我国的“千帆星座”等也采用了类似的组网思路。
天地一体化网络是另一个大方向。卫星骨干网与地面移动网络、光纤网深度融合:城市流量走地面,偏远地区、海上、空中由卫星兜底,两张网共用一套路由大脑,实现“全球无缝覆盖”。这带来了一个有意思的挑战——卫星路由必须与地面路由协议互通,而两者的时延量级差了好几个数量级,需要专门的网关和翻译机制。
面向未来,智能化是明确趋势。星座规模动辄上千颗卫星,拓扑变化频繁,传统查表式路由已经逼近算力极限。AI 被引入来做三件事:预测链路质量(结合太阳活动、地磁扰动等空间天气数据)、预生成优化路由策略、在链路故障时快速重规划。未来的星间路由,很可能从“规则驱动”走向“数据驱动”,由在轨 AI 芯片实时决策。
回到地铁比喻:轨道是永不失约的时刻表,AI 则是那个能提前预判“哪个站台会挤爆、哪扇门会临时故障”的调度大师。它不取代时刻表,而是让时刻表在面对意外时依然聪明。对于今天的网络工程师来说,理解这层“确定 + 智能”的架构,比背下任何具体算法都更重要——因为下一代空间网络的入场券,就藏在这两者的交汇处。
- 确定性部分轨道力学决定拓扑何时变、怎么变,这是可预报的。
- 不确定性部分空间天气、硬件故障、流量突发难以精确建模。
- 智能网络两者结合,用预测补偿不确定,形成闭环优化。
AI 应用场景
大型低轨星座网络智能化运维
阶段:网络规划与智能化运维
解决的问题:Starlink 这类星座包含数千颗卫星,拓扑每 90 分钟循环一次,人工配置路由表完全不现实。传统方式依赖地面站周期性上传预计算路由表,但面对突发链路失效(激光失锁、太阳活动干扰)反应迟缓。AI 结合轨道预报与实时遥测,可预测链路质量并动态调整路由权重,在故障发生前就完成流量迁移。
具体案例:某低轨星座运营商的网络运维中心,AI 系统持续接收每颗卫星的链路误码率、信号强度、姿态数据,结合空间天气模型预测未来 30 分钟各链路的可用概率。当预测某条跨轨道链路将有 20% 概率中断时,系统会自动将敏感流量切换到备用路径,并将告警推送给值班工程师。这套系统使路由收敛时间从分钟级降到秒级,可用性提升到 99.9% 以上。
天地一体化骨干网络的智能调度
阶段:资源调度与路径优化
解决的问题:天地一体化网络把地面光纤、5G 基站与卫星骨干网融合成一张网。传统路由协议为地面高稳定环境设计,无法适应卫星链路的频繁通断与毫秒级时延波动。AI 智能调度器维护一张“天地统一的虚拟拓扑图”,根据业务优先级(如金融交易、应急指挥)实时选择最优路径:能走地面就走地面,地面拥堵或故障时无缝切换到卫星链路。
具体案例:某远洋航运公司为上千艘货轮提供宽带接入,船只远离海岸线后信号由低轨星座接管。AI 调度器根据每艘船的位置、航线预报和当前星座拓扑,提前规划“换星时刻表”,让船只始终由信号质量最好的卫星服务。切换链路时用户几乎无感知,视频会议不掉线。
应急通信快速组网与路由恢复
阶段:智能规划与快速恢复
解决的问题:地震、洪灾后地面基站大面积瘫痪,应急通信车和无人机-卫星中继链成为唯一生命线。救灾现场拓扑混乱、资源紧张、链路忽通忽断,人工规划多跳路由耗时且易错。AI 可基于灾后第一时间获得的卫星影像和链路状态,在数分钟内生成一套覆盖指挥中心与救援队的最优路由方案,并随拓扑变化实时修正。
具体案例:在一次山区地震救援演练中,应急系统在 5 分钟内通过 AI 规划出一条“无人机中继 → 卫星 → 后方指挥车”的三跳应急链路。AI 优先保障指挥视频流的低时延路径,同时为普通数据分配备用路径;当一架无人机电量不足退出时,路由在 2 秒内自动切换到备用中继,指挥通信全程未中断。
Python 演示
"""星间链路路由演示:基于快照序列的 Dijkstra 最短路径路由 模拟两条低轨轨道上的 6 颗卫星,随时间推进动态建图并重算路由。"""import mathfrom heapq import heappop, heappush MAX_RANGE = 3.2 # 星间通信最大距离ORBITS = [2.0, 2.8] # 两条轨道的半径 class Satellite(object): """单颗卫星:在固定半径轨道上匀速运动""" def __init__(self, s_id, orbit, speed, phase): self.s_id = s_id self.radius = ORBITS[orbit] self.speed = speed self.phase = phase def pos(self, t): ang = self.speed * t + self.phase return (self.radius * math.cos(ang), self.radius * math.sin(ang)) def build_graph(sats, t): """在时刻 t 建立邻接表:距离小于通信范围的卫星之间连边""" graph = {s.s_id: [] for s in sats} for i in range(len(sats)): for j in range(i + 1, len(sats)): a = sats[i].pos(t) b = sats[j].pos(t) dist = math.hypot(a[0] - b[0], a[1] - b[1]) if dist < MAX_RANGE: graph[sats[i].s_id].append((sats[j].s_id, dist)) graph[sats[j].s_id].append((sats[i].s_id, dist)) return graph def dijkstra(graph, src, dst): """Dijkstra 最短路径:返回 (路径, 总代价)""" dist = {n: float('inf') for n in graph} prev = {n: None for n in graph} dist[src] = 0 pq = [(0, src)] while pq: d, u = heappop(pq) if d > dist[u]: continue if u == dst: break for v, w in graph[u]: nd = d + w if nd < dist[v]: dist[v] = nd prev[v] = u heappush(pq, (nd, v)) path = [] node = dst while node is not None: path.append(node) node = prev[node] return list(reversed(path)), dist[dst] def simulate(sats, times, src, dst): """按快照时刻逐个重算路由,打印路径变化""" for t in times: graph = build_graph(sats, t) path, cost = dijkstra(graph, src, dst) text = "t=%.1f 路径: %s 代价: %.3f" % ( t, " -> ".join(str(n) for n in path), cost) print(text) def main(): sats = [ Satellite(0, 0, 0.50, 0.0), Satellite(1, 0, 0.50, 1.2), Satellite(2, 0, 0.50, 2.4), Satellite(3, 1, 0.35, 0.6), Satellite(4, 1, 0.35, 1.8), Satellite(5, 1, 0.35, 3.0), ] simulate(sats, [0.0, 1.0, 2.0, 3.0], src=0, dst=5) if __name__ == "__main__": main()
ORBITS = [2.0, 2.8]定义两条轨道半径,对应比喻里两条“地铁线路”。def pos(self, t)根据时间算出卫星位置,体现轨道运动的确定性、可预报性。def build_graph(sats, t)快照法的核心:把 t 时刻能互相通信的卫星连成一张静态图。if dist < MAX_RANGE通信范围判定,模拟“只有交汇窗口内才能交接信件”。def dijkstra(graph, src, dst)最短路径计算,对应“最优换乘方案”的查找。prev[v] = u记录前驱节点,算法结束后用来回溯完整路径。simulate(sats, times, src, dst)按多个快照时刻重算路由,展示路径随拓扑变化。
常见误区
误区卫星都在天上,离得又不远,想跟谁通信就跟谁通信,信号可以直接打到任何一颗卫星上。
正解星间链路必须满足两个硬条件:彼此视线无遮挡(不能被地球挡住),且距离在通信范围内。低轨卫星的激光或定向微波链路就像手电筒,必须对准才能握手。两颗卫星分处地球两侧时,中间隔着直径一万多公里的地球,根本不可能直连。路由必须依赖“接力”,而不是“乱射”。
为何常见:人们把地面 5G 基站“全向覆盖”的直觉带到了太空。实际上卫星通信大量使用窄波束定向传输,链路是“点对点”而非“点对面”的,范围极为有限。
误区地面上 OSPF、BGP 跑了这么多年,星间路由无非是把路由器搬到卫星上,改改参数就能用。
正解地面网络拓扑以天甚至年为尺度稳定,路由协议可以慢悠悠地收敛;卫星网络拓扑每秒钟都在变,90 分钟循环一圈,链路时通时断。若直接用地面链路状态协议,全网路由会陷入持续的震荡和重算,信令开销就能把链路挤爆。星间路由必须利用“轨道可预报”这一前提,用快照、虚拟拓扑等手段把动态问题转化成静态问题,这是本质区别。
为何常见:两者都叫“路由”,都用图论,外观看相似;但“拓扑变化的时间尺度”完全不同,导致设计哲学根本分叉。
误区卫星就在头顶几百公里的轨道上,信号嗖一下就到了,时延肯定比地面光纤还小。
正解你听到的“几百公里”是地面站到卫星的垂直距离,而星间链路是卫星之间的横向距离,低轨相邻可建链卫星通常相隔一两千公里以上,信号单跳就要 3~17 毫秒。一个跨洋数据包要经过七八跳,累计传播时延可达上百毫秒——比地面光纤跨洋时延(约 60~80 毫秒)还高。星间路由优化的核心,就是在多跳接力中尽量压缩这段“太空飞行时间”。
为何常见:混淆了“到卫星的距离”和“卫星之间的距离”,也低估了光速虽快、太空更大的现实。
误区星座里卫星多了,链路四通八达,怎么走都能到,路由问题自然就简单了。
正解恰恰相反。卫星越多,拓扑变化越频繁,链路切换越密集,路由表的更新压力呈指数增长。想象地铁网里列车增加一倍,每一站的交汇窗口都会更密但更短,调度员的换乘手册会厚得翻不完。真实系统中,上千颗卫星意味着每秒钟都有链路在建立和断开,路由算法必须在极短时间内完成收敛,这对星上算力和信令带宽都是严峻考验。
为何常见:把“网络冗余度高”等同于“路由简单”。冗余降低了无路可走的概率,却提高了“选哪条路最优”的计算复杂度。
误区卫星那么大,多装几块芯片、几根内存条,跑复杂路由算法不在话下。
正解卫星的每一克重量、每一瓦功耗都极其昂贵。星上计算机的算力通常远低于一部普通手机,存储更是捉襟见肘。正因如此,工程上才要采用虚拟拓扑预计算的思路——把最复杂的路径计算放到地面,星上只保留一张查表用的路由表和一两个用于局部修复的小算法。这不是设计偏好,而是物理约束下的必然选择。
为何常见:习惯性地用地面的资源水平去想象太空平台,忽略了火箭发射成本对卫星载荷的苛刻限制。
面试题
Q1. 星间链路路由中,数据包主要通过哪种路径传输?
- A.地面基站转发
- B.卫星间直接链路← 正确答案
- C.海底光缆中继
- D.高空热气球
答案:B。星间链路路由的本意就是让数据包在卫星之间通过激光或微波链路接力传输,像地铁列车之间传递信件。地面基站、海底光缆属于天地融合网络的地面部分,热气球则与星间路由无关。
Q2. 与地面固定网络相比,卫星星座网络最突出的特点是?
- A.拓扑结构静止不变
- B.链路带宽完全无限
- C.网络拓扑动态变化← 正确答案
- D.传播时延始终为零
答案:C。卫星以每秒数公里的速度绕地飞行,彼此相对位置持续改变,链路不断建立与断开,因此拓扑是动态的。静止不变、带宽无限、时延为零都是不真实的理想化假设。
Q3. 卫星网络中“快照法”的核心思想是什么?
- A.每颗卫星独立存储全量数据
- B.完全依赖地面中心逐包决策
- C.放弃路由表改用洪泛广播
- D.将动态拓扑离散为静态快照← 正确答案
答案:D。快照法把连续变化的拓扑按时间切片,每个切片内近似视为静态图,再用经典静态路由算法求解。这与地铁换乘手册“把一天切成若干时段、每时段画一张运行图”是同一个思路。其余选项分别误解了快照法的存储、决策和转发方式。
Q4. Dijkstra 算法在星间链路路由中主要用于?
- A.计算最短传播路径← 正确答案
- B.调整卫星轨道高度
- C.压缩视频传输码流
- D.加密星间通信数据
答案:A。Dijkstra 是经典的最短路径算法,用于在静态拓扑快照上找到源卫星到目的卫星代价最小的路径,相当于帮信件找出“最优换乘方案”。轨道调整、视频压缩、数据加密各有专门技术,与路径计算无关。
Q5. 虚拟拓扑路由方法的设计前提是?
- A.地面基站随时可接管所有流量
- B.每颗卫星配备超大容量缓存
- C.卫星运动具有周期可预测性← 正确答案
- D.星间链路永远不会发生中断
答案:C。虚拟拓扑路由“预计算”的前提是卫星轨道运动精确可预报——像地铁时刻表一样,可以先算出未来所有时刻的拓扑再规划路径。如果链路随时中断或拓扑不可预测,预计算就失去意义。地面接管、超大缓存都不是虚拟拓扑的前提。
Q6. 星间链路频繁切换最容易引发什么问题?
- A.卫星轨道出现明显偏移
- B.路由震荡引发数据丢包← 正确答案
- C.太阳能帆板发电过量
- D.地面站接收天线过热
答案:B。链路频繁断开与重建会让路由算法来不及收敛,出现路径反复摇摆的“路由震荡”,进而导致数据包丢失和时延抖动。这与地铁临时改线导致乘客来回换乘、反而误点是一个道理。链路切换是通信行为,不会影响卫星轨道、发电或天线温度。
Q7. 分布式星间路由相比集中式路由的典型优势是?
- A.需要更强星上计算能力
- B.完全消除链路传播时延
- C.无需维护任何路由状态
- D.对动态拓扑适应更加灵活← 正确答案
答案:D。分布式路由由各卫星仅依据局部信息独立决策,不依赖地面中心统一下发,因此拓扑突变时能快速响应,适应性更强。它反而更节省单星计算资源(只需处理邻居信息),也不可能消除物理时延,且同样需要维护路由状态。
Q8. 下列哪些属于星间链路路由的常见优化目标?
- A.降低端到端时延← 正确答案
- B.均衡网络节点负载← 正确答案
- C.提高卫星总发射功率
- D.增强传输链路可靠性← 正确答案
答案:ABD。时延、负载均衡、可靠性是星间路由优化的三大经典目标,对应“更快、更均、更稳”。提高发射功率不是路由层的优化目标,反而会因为能耗问题增加卫星负担,工程上通常是在链路预算阶段就确定好的。
Q9. 星间链路路由面临的特殊约束有哪些?
- A.星上存储计算资源有限← 正确答案
- B.链路传播时延数值较大← 正确答案
- C.节点高速运动拓扑变化← 正确答案
- D.任意两星随时可建立直连
答案:ABC。星上资源受限、传播时延大、拓扑动态变化是三大核心约束,它们共同决定了星间路由不能照搬地面方案。任意两星随时可直连是错误认知——只有视线可见且距离足够近的卫星才能建立链路,就像列车只能在交汇站台递信。
Q10. 关于时变图模型 G(t)=(V,E(t)) 的说法,正确的有?
- A.节点集合 V 通常保持固定← 正确答案
- B.链路集合 E 随时间变化← 正确答案
- C.该模型无法表达链路切换
- D.可借助快照序列做路径规划← 正确答案
答案:ABD。时变图中 V 是星座卫星集合,在星座建成后基本固定;E(t) 每秒都在变,正是它刻画了链路切换。快照法就是把连续的 E(t) 离散成若干静态快照再进行路径规划。说“无法表达链路切换”恰恰与模型的初衷相反。