3.1 空间段地面段用户段
3.1 空间段、地面段与用户段
本节在知识体系中的位置：它给出全册通用的三段坐标系，之后每一章讨论任何组件，都要先归位到"空间段、地面段还是用户段"。读完你应当能徒手画出架构总览，并解释"功能上天"这条分界线两侧的取舍逻辑。
三段分工总览
空间段是天上的一切：卫星平台（供电、推进、姿控、热控）加通信载荷（天线阵、转发器或处理机、星间链路终端）。它是资产最重的一段，也是唯一"发射后难以维修"的一段，因此设计哲学偏向保守与冗余。地面段是星座的大本营：信关站负责流量落地与互联网互连，测控站（TT&C）负责遥测遥控与轨道维持，网络控制中心（NCC）负责全网资源调度、用户准入与计费策略，三者常共址建设以省回传。用户段是形态最丰富的一段：固定碟形天线、便携平板箱、车载动中收、机载相控阵、手持终端，还有越来越重要的直连手机基站模式——形态差异的背后是增益、功率与跟踪能力的差异，第 4 章的链路预算会量化这些差异。
功能上天还是留在地面
三段之间真正折磨系统工程师的问题只有一个：功能放在哪一段。把处理能力搬上天（再生式卫星、星载路由、星间交换），地面段就可以稀疏部署——信关站少量即可，跨洋流量不必先落地；代价是卫星更贵、更重、在轨升级困难，一颗处理机失效影响面大。把智能留在地面（弯管式），卫星便宜可靠、系统演进靠地面软件迭代；代价是每颗服务星都要"看见"地面站，海洋与大沙漠上空无法直接服务，时延也被落地绕行抬高。现实系统普遍走中间路线：用户链路段星上再生解调，网络层路由部分上星，计费认证等"慢策略"留在 NCC。判断某个功能该放哪边，可以用三问速查：时效要求多高（毫秒级必须上天）、失效代价多大（失效面大的倾向集中）、迭代频率多高（频繁迭代的倾向地面）。第 8 章讲安全架构时，这套三问会再登场一次——加密在哪一段做，正是同一道题的安全版。
一个对照案例：同一条海岸线两种部署
设想服务一条远洋航线。方案甲采用弯管星座：船载终端只能连到"同时看见船与某信关站"的卫星，航线远离海岸时出现覆盖空洞，需要在岛屿上加建信关站，土建与回传成本高企。方案乙采用带星间链路的再生星座：船只需看见任意一颗星，数据沿星间链路传到海岸信关站落地，海上零土建。两案的差别不在射频性能，而在"功能分布"这一个决策——它决定了地面段规模、时延分布与扩容路径。真实星座的演进也印证了这条线：早期壳层偏弯管式贴近地面，后续壳层全面转向星上处理加星间链路，架构重心持续上移。
三段是空间上的划分，"功能上天程度"是逻辑上的光谱——读任何星座方案，先找它的架构分界线，再看三问（时效、失效、迭代）如何被回答。
下一节钻进空间段内部，看星间链路如何把这些卫星焊成一张会规律变形的网格。
段间接口清单：谁跟谁说什么话
三段之间的分工最终落在接口上，调度台日常盯的接口有六条：用户链路接口（终端与接入星之间的波形与接入协议，第 4 章）；馈电链路接口（落地星与信关站之间的高速回传，通常成对冗余）；测控接口（测控站与卫星平台的遥测遥控通道，独立于业务链路，出故障时它是唯一的"生命线"）；网管接口（NCC 与卫星载荷、信关站、终端之间的控制面，下发频率计划、路由快照、准入策略）；运营支撑接口（NCC 与计费、客户管理、工单系统的对接，把网络事件翻译成账单与工单）；对等互联接口（信关站与互联网骨干的边界网关会话，第 5 章）。读架构图的功夫就是数接口：接口越少的段越"傻"也越稳，接口越多的段越"聪明"也越难管——三段架构的演化史，就是功能沿着这些接口上下搬家史。
设备形态的谱系：同一功能的三种长相
把"功能放哪段"的抽象问题落到硬件长相上更好理解。同样一个"调制解调"功能：放在终端（用户段）就是终端主板上的基带芯片，量产地摊价；放在卫星（空间段）就是抗辐射的星载调制解调器，量小价高但一颗服务千万用户；放在信关站（地面段）就是机房里的机架设备，可维修可升级。三种长相对应三种工程哲学：终端侧拼芯片产业、卫星侧拼可靠性与集成度、地面段拼运维便利。判断某功能"该放哪"，实际上是在问它的失效能否现场修复（不能则上天要冗余）、它的迭代周期多长（短则留地面）、它的单点影响面多大（大则分布化）——3.1 节的三问在这里有了硬件注脚。
一个反直觉事实：卫星越智能，地面段越重要
直觉认为功能上天会削弱地面段，实际相反。弯管时代地面只需要一堆天线；星上处理时代，NCC 要管频率计划、路由快照、波束调度、准入控制、全球终端的软件升级——网络越"自动"，编排它的地面系统越复杂。这解释了行业招聘的结构：星座公司里写网管软件的工程师远多于造卫星的工程师。组织架构图上最不起眼的 NCC 机房，才是这张天网的真正心脏。
与既有章节的算术勾稽
三段架构的每个设计选择都能在前章找到算术出处，这里把勾稽关系列成对照。信关站为什么要"成对冗余"：第 2 章的覆盖重数保证任何卫星同时可见多个地面站候选，7.2 节的并联账本证明双站把年停机从小时级压到分钟级。星上处理为什么要"够用就好"：功能上天的每一分算力都要付功耗、重量与抗辐射的代价，而第 5 章的快照路由恰好把大部分路由计算搬回地面——星上只需要"查表转发"这种便宜算力。终端为什么要分形态系列：4.1 节的三本链路账决定了增益与功率的阶梯，用户段的"多种长相"是物理定律的商业投影。架构图的每一条线背后都有一条公式，反之读架构图时若某条线"找不到出处"，要么是权衡未被言明，要么是设计冗余——两种情况都值得多问一句。
一道自测：给新需求定位归属
用一道开放自测收束本节。需求：某国要求"本国用户的全部流量必须留在本国境内处理"。请把它分解到三段：用户段（终端侧合规：本地身份认证，无本地凭证不接入）、空间段（星上路由策略：识别用户归属，只在授权地面站落地——3.1 的落地策略与第 5 章的落地选择在此汇合）、地面段（境内信关站与本地 NCC 分系统：计费数据不出境，管理面主权分治）。三段各自要新增什么、谁承担主要成本（空间段的路由约束会抬高跳数与时延）、监管怎么验收（审计日志本地化）——把这份分解写成半页纸，就完成了本节的毕业设计。这道题的价值在于演示：任何一句看似"政策性"的要求，落到系统里都是三段各自的具体工程项。