Starlink系列（3）--Starlink 星上 eNB 的工程实现：把基站搬上天，到底要改什么

　　把地面 eNB 搬上卫星，直觉上像是”同一台机器换了个地方”——协议栈不用动，顶多加一套温控和抗辐射。但真正落到工程上，问题会变得具体：卫星上那台 eNB，和地面上那台，到底是不是一回事？

　　本文的结论是：协议栈上层几乎可以照搬，但物理层里所有跟”时间”和”频率”沾边的部分必须重写，另有一整套地面 eNB 根本没有的模块要新建。 而且最硬的约束不在多普勒补偿算法本身，在一个大多数人想不到的地方——随机接入。

　　除特别说明外，轨道参数取 360 km 高度、43°/53° 双壳层，D2C 下行 1.9 GHz，业务信道 5 MHz（LTE 子载波间隔 15 kHz）；服务门限仰角 30°。

0. 全文速览：本文回答的十二个问题

问题	一句话答案	节
星上 eNB 是地面 eNB 搬上去吗？	不是。上层协议栈能照搬，PHY 里与时间/频率同步相关的部分必须重写	1
买一台地面 eNB 改造成星载行不行？	不行，而且改的不是”一层算法”，是 PHY 前端 + 新增一层频率管理	1.2
最先撞墙的是哪一关？	PRACH：前导检测的频偏容限差 32 倍，UE 连接入都完不成	2.1
上行频偏怎么补？	两级：波束级粗补（消公共斜坡）+ UE 级精补	2.2
预补偿多久刷一次？	≤ 11 ms，由过顶处 986 Hz/s 的多普勒变化率定的	2.3
下行也能逐 UE 补吗？	专用信道可以；公共信号（PSS/SSS/CRS）只能补一个值	3
补不干净的那部分怎么办？	残差 1.5–3 kHz 留给 UE 的 AFC，正好落在它 ±10 ppm 的捕获范围内	3.3
时延这边麻烦吗？	更麻烦：LTE 的 TA 量程只有 668 μs，星地往返 4.47 ms，差 6.7 倍	4.1
怎么解决？	星上吸收公共分量，而且必须按波束设基准——按整星设仍超 1.55 倍	4.2
这对架构有什么反作用？	“一个波束一个小区”不只是 PCI 复用的需要，也是 TA 可管理性的需要	4.3
时延刷新周期和多普勒一样吗？	不一样：≤ 56 ms。两个变化率的最大值出现在不同位置	4.4
最难的一环是什么？	不是算多普勒，是星上的时钟——它是预报精度的天花板	6

　　这十二个问题串起来是同一句话：把基站搬上天，难点不在”它飞起来了”，在于它脚下的每一寸电磁环境都和地面不一样。

1. 先弄清”搬上天”的到底是什么

1.1 一颗星 = 一个 eNB：这个粒度从哪来

　　先看这个粒度从哪里来：一颗星 248 个波束，而 LTE 的 Cell ID 字段恰好是 8 bit = 256 个槽位——一颗星正好塞进一个 eNB 的身份空间。所以”D2C 按一颗星一个 eNB 设计”不是随意划分，是被协议字段宽度框出来的粒度。

　　这个粒度决定了后面所有的改造范围：每颗星都是一台独立的、完整的基站，有自己的时钟、自己的调度器、自己的 248 个小区，以及——这是本文的重点——自己的一套时间和频率补偿机制。

1.2 星上 eNB 内部：比地面 eNB 多了什么、少了什么

　　先给结论，再解释。星上 eNB 和地面 eNB 的差异不是均匀分布的，而是集中在物理层最靠近天线的那一段：

图 1　星上 eNB 的分层改造清单：越靠近天线，越要重做

　　为什么协议层能照搬？ 因为 RRC 管的是”连接怎么建立、怎么移动”，PDCP 管的是”加密和头压缩”，RLC 管的是”分段和重传”——它们都不关心电磁环境长什么样。多普勒是 40 kHz 还是 4 Hz，对这三层的代码没有区别。

　　为什么物理层不能照搬？ 因为物理层的每一个环节都建立在一个隐含前提上：收发两端的时间基准和频率基准是稳定的、准的。 地面 eNB 这个前提由机房里的恒温晶振和 GPS/1588 保证；到了 360 km 高的轨道上，时钟要自己扛，而”稳定”的含义变成了”要在以 7.7 km/s 移动的同时保持稳定”。

　　为什么同步与时钟是”全新”？ 地面 eNB 的同步是”花钱买来的”——机房里有 GPS 天线、有 1588 边界时钟、有恒温晶振。星上这三样都没有：没有 GPS 天线（虽然有 GNSS 接收机，但要考虑在轨可见性与抗干扰）、没有稳定的温度环境（朝阳面和背阳面温差可以达到上百摄氏度）、也没法派人上去换一块晶振。

1.3 与地面 eNB 的量级差

　　把差异量化成数字，才会明白为什么不能”改改算法了事”：

维度	地面 eNB	星上 eNB	差距
与终端的相对速度	0–500 km/h	27,700 km/h（7.70 km/s）	~55 倍
上行多普勒 @1.9 GHz	±0.88 kHz（500 km/h）	±40.0 kHz（30° 仰角）	45 倍
多普勒变化率	10² Hz/s 量级	986 Hz/s（过顶）	~10 倍，且全程单调
服务窗口内多普勒跨度	可忽略	80 kHz（+40 → −40）	—
往返传播时延	≈ 0（微秒级抖动）	2.40–4.47 ms，单调扫过	3 个数量级
时延变化率	≈ 0	21.0 μs/s（窗边）	—
覆盖半径	1–30 km	单波束足迹 71×142 km	5–10 倍
频率基准	GPS/1588 + 恒温晶振	星载 GNSS 驯服 / 原子钟	获取方式完全不同

　　表里有一行值得单独看：服务窗口内多普勒跨度 80 kHz。 这个数字不是”最大频偏”，而是”一次服务过程中终端要经历的总频率落差”。作为对照，3GPP 对基站载波频率精度的要求是 ±0.05 ppm，在 1.9 GHz 上等于 ±95 Hz——也就是说，卫星在 2.5 分钟里扫过的频率范围，是基站自身频率精度要求的 842 倍。

2. 频率：上行接收侧

2.1 第一关就卡在 PRACH

　　卫星上的频偏补偿算法再精妙，也需要 UE 先成功接入。而随机接入的第一步是 UE 发 PRACH 前导，由 eNB 检测。

　　LTE 前导的子载波间隔只有 1.25 kHz（比业务信道的 15 kHz 小一个数量级，这是为了拿到足够长的序列和更好的覆盖）。前导检测的相关峰在频域上是窄的，检测器的频偏容限就在 ±1 个前导子载波间隔、也就是 ±1.25 kHz 这个量级——这也是为什么 LTE 的高速场景设计目标只有 500 km/h（换算到 1.9 GHz 是 ±880 Hz）。

　　卫星在 30° 仰角处的多普勒是 ±40.0 kHz，需要检测器覆盖的范围是常规设计的 32 倍。这个倍数是硬账：

场景	多普勒 @1.9 GHz	相对前导容限
LTE 高速铁路设计目标（500 km/h）	±880 Hz	0.7 倍
星上 eNB 在 30° 仰角门限处	±39.95 kHz	32 倍
星上 eNB 的地平线几何极限	±46.1 kHz	37 倍

　　所以第一个必须重建的模块就是 PRACH 检测器：搜索窗要按 ±40 kHz 重设，前导的根序列与循环移位要重新规划（第 5 节展开）。这一关过不去，后面所有的补偿算法都没有机会运行——UE 连接入都完不成。

　　有一点可以放心：前导序列本身长度是 800 μs，在这么短的时间里多普勒只会漂移 0.79 Hz（986 Hz/s × 800 μs），完全可以忽略。问题不在前导内部，在它整体落在哪个频点上。

2.2 两级补偿

　　既然需要覆盖 ±40 kHz，最直接的想法是”把搜索窗做宽 32 倍”。但这样做的代价是相关器复杂度同比例上升——而这只是第一步，后面还有成百上千个 UE 要处理。

　　实际做法是把补偿分成两级，先用便宜的手段把公共的那一大块消掉，再让精密的算法只处理残差：

图 2　上行两级频偏补偿：把 ±40 kHz 逐步收敛到百 Hz

　　这里有个容易忽略的协议细节：LTE 规定 UE 调制载波频率的精度基准是”相对于从 eNB 接收到的载波频率”（TS 36.101），而不是标称频率。意思是手机自己的 AFC 已经把下行多普勒学进了本地振荡器，发射时用的是同一个参考——上行信号天然携带 1 倍多普勒，到达卫星时因为卫星也在动，叠加成 2 倍。星上要校正的是剩下那一半，而且必须显式处理这个 2 倍系数。

2.3 刷新的节奏由谁定

　　补偿量算出来不是一劳永逸的——卫星一直在动，多普勒一直在变。刷新周期取多大，取决于”允许多少相位漂移”。

　　多普勒变化率在过顶处最大，达到 986 Hz/s（这一点和直觉相反，但看公式就明白：多普勒正比于径向速度，而径向速度在过顶时恰好过零——过零点的斜率最大；窗边虽然径向速度最大，但变化已经趋缓，只有 152 Hz/s）。

　　在刷新间隔 T 内，多普勒会漂移约 k·T，由此累积的相位误差是 2π·k·T²/2。要求这个误差不超过 QPSK 解调裕度（取 ±22.5°）：

相位漂移容限	刷新周期上限	间隔内多普勒漂移
±22.5°	11.3 ms	11.1 Hz
±11.25°（留一倍裕量）	8.0 ms	7.9 Hz
取工程值 10 ms	—	9.9 Hz，累积相位 17.7°

　　所以星上的多普勒预补偿刷新周期必须落在 10 ms 量级——对应 LTE 的 10 个子帧。这比地面 eNB 里任何周期性任务都快。

　　顺带澄清一个可能的误解：问题不在子帧内部。 1 ms 子帧内的多普勒漂移只有 0.99 Hz，相位漂移 0.177°，可以完全忽略。要紧的是补偿量的绝对精度和它的刷新节奏，不是单次传输内的稳定性。

3. 频率：下行发送侧

3.1 逐 UE 预补偿

　　下行比上行多一个自由度：eNB 知道每个 UE 是谁、准备发给谁。所以 PDSCH 这类专用信道可以逐 UE 预补偿——发送频率取”标称频率减去该 UE 在当前时刻的多普勒预测值”，UE 收到时正好落在标称频点上。

　　这里体现出一个前面提过的反转：地面 eNB 处理频偏是”盲估计”，星上 eNB 是”预报”。 地面 eNB 不知道 UE 在哪、速度多少，只能从接收信号里估；星上 eNB 的轨道是确定的，用星历可以提前把每个波束、每个时刻的多普勒曲线算出来，直接前馈。

3.2 公共信号只能补一个值

　　但下行有一个解不开的矛盾：PSS/SSS/CRS 是小区级广播信号，同一个波束里所有 UE 都要能解，所以只能补一个多普勒值。

　　通常取波束中心（或相当于波束中心的那条视线）。这意味着波束边缘的 UE 一定会有残余频偏：

图 3　束内多普勒梯度：公共信号为什么赶不掉那 1.5–3 kHz

　　束内梯度取多少，取决于量足迹的哪个方向：短边（71 km）两端相差 1.49 kHz（0.78 ppm）；长边（142 km）相差 3.00 kHz（1.58 ppm）。这个量级占了 15 kHz 子载波间隔的 10–20%，不能不管。

3.3 残差交给 UE 的 AFC —— 这里正好闭环

　　那么这 1.5–3 kHz 谁来消化？答案是 UE 自己的 AFC。

　　UE 晶振的捕获范围是 ±10 ppm，在 1.9 GHz 上是 ±19 kHz。星上把公共分量预补偿掉之后，UE 看到的多普勒只剩束内梯度加上星上时钟误差——几个 kHz 的量级，恰好落在 UE 能处理的范围里。

　　（顺带澄清一个容易混用的区别：±0.1 ppm 是 UE 锁定之后的调制载波精度要求，±10 ppm 是它的初始捕获范围，两个数说的是不同的事。）

　　这就是”分层补偿”的由来：不是工程上偷懒，而是物理上做不到逐 UE。 广播信号的本性决定了它只能补一个值；剩下的差额，只能交给唯一还剩下的那个可编程节点——手机里的 AFC。

4. 时间：TA 量程装不下星地距离

4.1 668 μs vs 4.47 ms

　　频率这一侧靠”预报 + 两级补偿”能解决，时间这一侧更棘手，因为它撞上的是一条写在协议字段位宽里的硬边界。

　　LTE 的定时提前（TA）命令是 11 bit，粒度 16Ts（0.521 μs），最大 1282 → 668 μs。它对应的设计假设是：小区半径不超过 100 km。

　　而卫星场景下：

量	数值
单程时延（星下点）	1.200 ms
单程时延（30° 仰角门限）	2.233 ms
往返时延	2.40 – 4.47 ms
服务窗内单程时延跨度	1.033 ms
TA 量程	668 μs
超出倍数	3.6 – 6.7 倍

　　注意最后两行的对比关系：UE 需要的最大提前量是 TA 量程的 6.7 倍。 这不是”精度不够”，是”字段装不下”——UE 就算想配合，它的 11 bit 寄存器也表达不出这个数。

4.2 按整星设基准还不够

　　自然的想法是：星上把公共的那部分自己吸收掉，只让 UE 补偿残余。星上确实可以这么做——eNB 的接收定时基准相对于发射定时偏移一个量，这个量由星历确定。

　　但基准取在哪里，结果完全不同：

图 4　三种基准方案：只有"按波束"能把跨度压进 668 μs

　　为什么”按整星设基准”没有用？因为基准只平移了需要补偿量的绝对大小，没有缩小它的跨度。整星服务圈半径 550 km，从星下点到 30° 仰角，往返时延相差 2066 μs——取中点做基准之后，UE 要覆盖的仍然是 ±1033 μs，是 TA 量程的 1.55 倍。

　　而按波束设基准，覆盖范围一下缩到 409 μs（取足迹长边 142 km 的保守口径），装得下了，还有 1.63 倍裕量。UE 侧需要 786 个 TA 步进，而它有 1282 个。

4.3 一个反作用：”一束一小区”的第二个理由

　　这个推导带来一个有意思的后果。

　　“一个波束一个小区”最常见的理由是PCI 复用——D2C 只有 1.4/5 MHz 窄带，频率上没法分色，只能靠窄波束做空间隔离。本文的推导给出了第二个理由：TA 可管理性。

　　整星服务圈的时延跨度（2066 μs）装不进 UE 的 TA 字段，但波束足迹的跨度（409 μs）装得下。也就是说，波束粒度不仅是频率复用的需要，也是时间对齐机制能工作的前提。 如果把整星做成一个小区，时延维度的补偿在存量手机上根本没法完成。

　　两条独立的约束指向同一个架构选择，这通常是设计对了的信号。

4.4 两个变化率互补，两套环路

　　最后一个关于刷新节奏的问题：TA 要多久更新一次？

图 5　两个变化率互补：多普勒在过顶最急，时延在窗边最急

　　这张图是本篇最有意思的一处细节。多普勒变化率和时延变化率的最大值出现在相反的位置：

• 多普勒变化率正比于径向速度的变化率，在过顶时最大（986 Hz/s），窗边降到 152 Hz/s；
• 时延变化率就是径向速度本身（除以光速），过顶时径向速度过零（0），窗边最大（21.0 μs/s）。

　　物理上它们本就是一对导数关系（时延是径向速度的积分），最大值互补是必然的。工程含义是：

补偿项	刷新周期上限	约束来自
多普勒预补偿（上/下行）	≤ 11 ms	过顶 986 Hz/s
TA / 时延补偿	≤ 56 ms	窗边 21.0 μs/s（取 1/4 CP 裕度）
波束指向（地固驻留）	秒级	电扫能力
公共基准 / 星历	分钟级	轨道确定更新

　　星上 eNB 需要至少两套不同速率的补偿环路，快的那套盯频率，慢的那套盯时间。把它们合并成一个周期是行不通的——要么频率那边来不及，要么时间这边白烧算力。

5. PRACH 的第二个约束：前导规划

　　回到第 2.1 节留下的尾巴。PRACH 检测器重建，除了要把频偏搜索窗拓宽 32 倍，还有第二个坑：循环移位配置。

　　LTE 前导检测靠的是一条 Zadoff-Chu 序列的循环移位正交性。序列长 839（对应 1.25 kHz 子载波间隔），循环移位的步长 Ncs 对应一个”零相关区”（ZAZ）：只要两个 UE 的到达时延差落在 ZAZ 之内，eNB 就能用不同的循环移位把它们分开。

　　地面上，小区半径 1–30 km，Ncs 取小值（比如 13）就够了，此时一条根序列能提供 64 个循环移位——也就是 64 个前导，一个小区够用了。

　　到了波束足迹 71×142 km 的场景，需要覆盖的时延跨度是 205 μs（单程，短边口径）。按 PRACH 的循环移位单位 0.9537 μs 折算：

场景	需要的 ZAZ	对应 Ncs	每根序列可提供的前导数
地面小区（≤1.25 km）	12 μs	13	64
波束足迹（71 km 短边）	≥ 205 μs	279	3
整星服务圈（550 km）	≥ 1033 μs	需 1083 > 839	不可能

　　最后一行是结论性的：整星覆盖需要的 ZAZ 超过了序列本身长度，物理上做不到。 所以前导规划也必须以波束为单位，和上文 TA 的结论一致。

　　代价是：每个根序列能提供的前导数从 64 掉到 3，要凑出 64 个前导就需要 22 个根序列（而不是 1 个）。这会带来两个后果——相邻波束之间要做根序列规划以避免冲突，以及同一波束内前导的碰撞概率上升（可用前导池变小、分配变粗）。

　　顺带说一句：LTE 高速场景用的”受限集”在这里也帮不上忙——受限集是为 500 km/h 量级的多普勒设计的，面对 ±40 kHz 完全没有意义。

6. 时钟：预报精度的天花板

　　到这里，改造清单里的每一项都能靠算法解决，唯独有一项不能——时钟。

　　前面反复说”星上 eNB 最大的优势是它知道自己在哪，可以预报多普勒”。但这句话有一个前提：预报出来的频率，得真能准确实现在载波上。

　　把两类误差放在一起看：

图 6　时钟误差比星历误差大出约 2600 倍，是预报精度的实际瓶颈

　　星上时钟偏差 1 ppm，在 1.9 GHz 上直接产生 1900 Hz 的载波偏差——是 15 kHz 子载波间隔的 12.7%，和束内多普勒梯度（1.5–3 kHz）同一量级，根本压不住。

　　而星历误差就算到 100 m，折算到多普勒误差也只有 0.7 Hz。要让它”配得上”1 ppm 的时钟误差，星历得错到 262 km——这显然不可能发生。

　　所以真正的瓶颈不在”能不能算出多普勒”，而在”星上的频率基准够不够准，让算出来的值能真正还原到载波上”。 星历可以算得再精确，时钟不准，预报就是空中楼阁。

　　这也是为什么星载时钟要单独列为一层：3GPP 对基站载波频率精度的要求是 ±0.05 ppm（1.9 GHz 上 ±95 Hz），星上必须靠星载 GNSS 驯服的高稳晶振或星载原子钟去够到这个量级。地面 eNB 的时钟是”买来的”（GPS 天线 + 1588 + 恒温晶振），星上的时钟是”自己做出来的”，而且要在温差上百摄氏度、有辐射的环境里长期稳定。

　　一个反过来说的结论：上面那些多普勒补偿算法，本质上都是在处理”已知且可预报”的量；而时钟误差是未知的漂移，只能靠硬件解决，算法一点忙都帮不上。

7. 平台层：三个容易被忽略的前置条件

　　前三节讲的都是信号处理，但把 eNB 送上 360 km 轨道还有三个非射频的前置条件，它们不解决，上面那些算法一行都跑不起来。

抗辐射与可靠性。 360 km 属于低轨，虽然在内辐射带下缘附近、辐射环境比中轨温和，但仍需要针对单粒子翻转（SEU）做加固：存储器要加 ECC/EDAC，关键寄存器要做三模冗余（TMR），还要有看门狗和定期自检。更要紧的是”坏了没法修”——地面 eNB 一块基带板出问题，换一块就行；星上只能靠冗余设计和在轨重构。这直接决定了星上 eNB 不能用货架商用芯片的裸片，而要用宇航级或经过筛选的器件。

在轨可重构。 星座在轨寿命是年为单位，而协议、算法、参数在这期间一定会迭代。所以星上基带普遍走 SDR（软件无线电） 路线——用可重配的 FPGA/SoC，把物理层做成可加载的镜像。这也是”通用平台 + 卫星 profile”这个说法的由来：不是把某款地面 eNB 的固件搬上去，而是在通用基站平台上做一份卫星专用的物理层配置，换掉频偏/定时模块、加一层星历预报，而 RRC/PDCP/RLC/MAC 这些上层几乎原样保留。

功耗与散热。 地面机房有空调、有市电。星上只有太阳能帆板供电，散热只能靠辐射——真空里没有对流。248 个波束的基带处理是整星最大的耗电项之一，而功耗直接决定散热面积和帆板尺寸。这也是为什么”只对激活波束分配基带”是必需的：满配 248 个波束各自独立基带需要约 1.9 Gsps 的处理量，而实际同时激活约 140 个波束，降到 1.1 Gsps。

8. 结论：到底改了哪一层

　　回到最初的问题。把地面 eNB 放到卫星上不是”装上去就能用”，但也不是”全部推倒重来”。 准确的边界是这样的：

层次	结论	原因
RRC / PDCP / RLC	原样保留	不关心电磁环境
MAC 调度	小幅改造	要把多普勒/时延梯度作为调度约束吃进去
PHY · 下行	重写	逐 UE 预补偿；公共信号只能补一个值，残差留给 UE AFC
PHY · 上行	重写	两级频偏补偿；PRACH 检测器搜索窗拓宽 32 倍；前导序列重规划
定时 / TA	重做	TA 量程 668 μs 装不下星地往返 4.47 ms，须按波束设基准
时钟	全新	星载 GNSS 驯服 / 原子钟，是预报精度的天花板
平台	全新	抗辐射加固 + 在轨可重构 + 功耗散热

　　如果要给出最有信息量的一句话，是这样的：

星上 eNB 的工程本质，是把”终端本该承担的 NTN 能力”（定位、星历、时延与频偏预补偿）整包搬到了卫星上；而它真正的技术门槛，不在多普勒补偿这道算术题——这道题在地面也有——而在两件地面 eNB 从不需要操心的事：星上时钟够不够准，以及存量手机协议里那几个装不下星地尺度的字段。

　　两个补充判断，供读者参考：

• 不要低估”字段位宽”这一类约束。 本文最硬的三个边界——TA 的 11 bit、PRACH 的 Ncs 表、Cell ID 的 8 bit——都是协议设计时的取值，不是算法问题。它们决定了星上 eNB 的架构（一束一小区），而不是被架构决定。这类约束在 PPT 上永远看不出来，只有把数字代进去才会撞上。
• 本文所有数字都是几何推导的结果，不是实测。 轨道高度、频点、门限仰角一变，量级会变（但”多普勒变化率峰值在过顶、时延变化率峰值在窗边”这类结构性结论不变）。文中涉及的星上实现细节（两级补偿的分工、按波束设基准、SDR 路线）是基于物理约束和公开的星载基站工程实践做的推断，不是对 Starlink 具体实现的描述——SpaceX 未公开 D2C 星上 eNB 的实现细节。