2.3 星座与波束：Starlink 规模账与多波束成形

2.3 星座与波束：Starlink 规模账与多波束成形

傍晚抬头看一颗快速移动的"星星"划过头顶，四分钟后它沉入地平线阴影里——那可能是一颗正在换班的宽带卫星。单颗星几分钟的可见时间，如何变成用户"永不掉线"的服务？答案由两件事拼成：地面上万颗卫星的几何排布（星座），与每颗星上几十个可转向的波束（多波束成形）。本节拆开 Starlink 的壳层参数算规模账，再看波束怎么像追光灯一样在地面上流动。

先看样本：Starlink 第一代的壳层结构

Starlink 第一代获批约 4408 颗，实际部署是分壳层（shell）完成的：约 1584 颗在 550 公里、倾角 53 度；约 1584 颗在 540 公里、倾角 53.2 度；720 颗在 570 公里、倾角 70 度；再加上极轨与高倾角壳层各一二百颗。读这组参数的门道在倾角：53 度壳层照顾全球人口稠密的中纬度带，70 度以上壳层补高纬度，极轨壳层保证两极。同一高度多壳层的重复铺设则是为了容量——同一地区头顶可服务的卫星数翻倍，等效小区容量翻倍。对比 OneWeb 第一代：648 颗全放在 1200 公里、12 个轨道面，走"少星、高轨、广覆盖"路线，单星覆盖大所以数量少，代价是单跳时延约 8.7 毫秒（对比 550 公里的约 3.9 毫秒）与更高的路径损耗。两家的选择就是上一节"高度—数量—时延"曲线上的两个点。

轨道面内的排布用行业术语叫 Walker 架构：轨道面数 × 每面星数 × 相位因子。数量下限可以粗估：全球任意地点任意时刻至少看到一颗服务星的必要条件，是"单星覆盖面积 × 星数 ≥ 地球表面积 × 冗余系数"。550 公里、仰角 25 度的单星可见面积约 400 万平方公里量级，地球表面积 5.1 亿平方公里，理论下限约 130 颗——但这要求星恰好在头顶均匀分布，实际低轨卫星沿轨道面流动、覆盖时间不均，加上城市遮挡、仰角余量、多星分集需求，工程规模直接放大到千颗量级。理论下限与工程规模的百倍差距，正是星座设计里的真实学问：轨道面倾角决定纬度覆盖权重，面内相位决定区域密度峰值，星数决定的是统计意义上的连续性而不是"是否有一点覆盖"。

图：壳层星座与流动波束的覆盖几何

波束：让"小区"跑起来的相控阵

传统卫星用抛物面天线，波束指哪打哪但要机械转动；现代宽带星座用相控阵，电调相位即时改向，一颗星能同时维持几十个点波束。真正的独特点是波束在流动：卫星以每秒约 7.5 公里的速度掠过地面，星下点波束跟着扫过地表，地面上的"小区"几分钟内从西边进来、往东边出去。用户感觉"没断网"，是因为地面网络控制面在波束间做了接力——这套接力就是第 4 章切换问题的主角。波束设计还要处理两个约束：旁瓣对邻区与邻星的干扰（频谱复用越激进，干扰协调越难，第 4.1 节的频谱账在此预演），以及波束尺寸与容量的反比——波束越小容量密度越高，但切换频率也越高，工程上在两者之间取折中。

动手验证：头顶有几颗星

把"可见卫星数"变成一个可算的量。下面这段代码用最简几何（均匀球面分布近似）估算给定星座规模下、给定最低仰角的可见星数期望值：

import math

def visible_sats(total_sats, alt_km, min_elev_deg=25.0, lat_deg=30.0):
    """均匀分布近似：估算某地平均可见卫星数（含纬度密度粗修正）"""
    Re = 6371.0
    e = math.radians(min_elev_deg)
    rho = math.sqrt((Re + alt_km)**2 - (Re*math.cos(e))**2) - Re*math.sin(e)
    psi = math.asin(Re*math.cos(e) / (Re + alt_km))       # 地心角
    cap_area = 2 * math.pi * Re**2 * (1 - math.cos(psi))  # 单星可见球冠面积
    frac = cap_area / (4*math.pi*Re**2)                   # 覆盖比例
    # 纬度修正：倾角 53 度星座在 30 度纬度略密于均值，取 1.1
    return total_sats * frac * 1.1, rho

for name, n, alt in [("Starlink级", 4408, 550), ("OneWeb级", 648, 1200)]:
    v, rho = visible_sats(n, alt)
    print(f"{name}: 斜距约{rho:.0f} km, 平均可见约 {v:.1f} 颗")
​

跑出来的量级：Starlink 规模星座在中纬度平均可见几十颗，OneWeb 规模则是个位数。这个差值就是多连接切换（第 4.3 节）的可行性差距——可见星越多，天地切换的"接应者"越充裕，掉线概率越低。

波束调度的日常：一张星上在忙什么

把镜头对准一颗在轨卫星的典型一分钟，波束调度的日常就具体了：相控阵持续扫描服务区内的用户分布，按流量热力把几十个波束的功率与带宽动态重分配——城市网格吃满带宽、海洋网格保底连接；每当星下点掠过 4.1 节登记过的敏感台站，对应波束按预案压功率或关断再恢复；波束越过轨道面边界时与邻星交接用户；空闲时段排队处理星间链路的路由更新与软件灰度任务。这一分钟的"忙碌清单"几乎浓缩了本册前四章的全部机制：波束成形是 2.3 的硬件基础，台站规避是 4.1 的合规动作，波束交接是第 4 章的切换话题，路由更新是 3.1 的组网话题。单星一分钟的业务密度，就是 SAGIN 系统复杂度的最小心跳——理解了这个心跳，再大的系统图景也只是它的千万次重复。

这份清单也解释了星上软件为什么越写越重：波束调度在毫秒级周期上跑，规避与交接在秒级事件上跑，路由与灰度在分钟级任务上跑——三个时间尺度的任务共享一套算力与功耗预算，优先级设计与资源隔离是星上软件的核心功课，也是 8.1 节算力坎的具体体现。

本节要点回顾

• 星座结构读法：高度 × 倾角 × 面数 × 每面星数，Starlink 用多壳层堆容量，OneWeb 用高轨省数量。
• 规模账有百倍差距：理论覆盖下限百余颗，工程规模数千颗，差在连续性、仰角余量与分集。
• 波束是流动的小区：相控阵几十波束、每秒约 7.5 公里掠地，切换接力由第 4 章机制兜底。
• 监管也是节奏：国际电联的分期组网里程碑，是星座"抢发射"背后的制度推手。

星座铺好了，每颗星几千万用户数共享的容量怎么进互联网？下一章把镜头转向星与星之间——星间链路解决什么。