02-LR-FHSS卫星直连的预算重构
9.2 LR-FHSS 卫星直连的预算重构
本节摘要：卫星直连让 LoRa 覆盖延伸到无地面网关的荒野与海上，代价是链路预算与协议行为的全面重构。本节讲 LR-FHSS 的调制差异与卫星链路的预算账。位置：9.1 用中继扩展了几公里，本节看几百公里级的扩展。
LR-FHSS 与 CSS 的差异
卫星场景不能直接用地面 CSS 配置：几百公里距离的路径损耗大、多普勒频移明显、低轨卫星过境时间短。LR-FHSS（Long Range Frequency Hopping Spread Spectrum）为此设计：报文拆成多个小包，按跳频序列在多个子信道上发送，接收端按序列重组。与 CSS 相比：
| 维度 | CSS（地面） | LR-FHSS（卫星/长距） |
|---|---|---|
| 频率使用 | 单信道连续 | 多子信道跳频 |
| 抗多普勒 | 弱 | 强（跳频天然抗频移） |
| 数据速率 | 相对较高 | 低（每子信道极窄） |
| 空中时间 | 秒级 | 分钟级（长报文） |
| 适用 | 地面网关 | 卫星直连、超远距离 |
卫星链路的预算账
卫星链路的账本变化：路径损耗更大（几百公里 vs 几公里，差 40dB 量级）、天线增益受限（地面设备天线小）、多普勒与时间同步（卫星运动引入频移与传播时延变化）。补偿手段：更低速率（处理增益换余量）、更强的跳频（抗频移）、功率按卫星过境时刻规划（只在卫星可见时发射）。
量级对比（同为 14dBm、全向天线）： 地面 5km：FSPL ≈ 105dB，余量充足（1.3 算例） 卫星 500km：FSPL ≈ 185dB，余量需靠极低速率与跳频增益补
协议的适配
卫星直连涉及协议层适配：过境窗口（设备要知道卫星何时可见，规划发射时机）、长空中时间下的占空比与调度、多普勒补偿（频率预补偿或接收端校正）。这些功能通常由卫星运营商的地面站与定制 NS 承担，设备侧主要配合"过境调度"。
易错点清单
- 拿地面配置跑卫星：卫星场景必须用 LR-FHSS 或专有配置，地面 CSS 的参数无法支撑几百公里链路；
- 忽略过境窗口：低轨卫星过境几分钟到几十分钟，设备不在窗口发射等于白费，调度逻辑要正确；
- 用全向天线当增益来源：卫星链路增益主要来自速率与跳频，设备侧天线难以提供定向增益，别指望它；
- 不评估时延：卫星链路端到端时延按秒到分钟计，对实时性要求高的业务不适合。
要点回顾：LR-FHSS 用跳频与极低速率应对超远距离与多普勒；卫星预算差 40dB 量级，靠增益换余量；过境窗口调度是设备侧的关键配合。最后一节看应用层：语义化与 DLMS 的兼容账。
卫星场景的协议与地面差异
卫星直连与地面网络的协议差异集中在三处：时间同步（卫星过境窗口与多普勒补偿，地面无需考虑）、频偏补偿（卫星运动引入数十 kHz 的多普勒频移，地面链路几乎为零）、长时延下的重传策略（卫星往返时延秒级，地面重传超时毫秒级）。这些差异意味着设备固件要针对卫星场景做专门分支，不能简单复用地面配置。
过境窗口的计算与调度
低轨卫星过境周期 90–120 分钟，可见窗口几分钟到几十分钟。设备侧调度三件事：预测窗口（根据轨道参数或运营商下发的窗口表，计算下一次可见时刻）、在窗口内发射（只在可见时发，避免盲发浪费电量）、失败重传规划（窗口内重传，窗口关闭后等下一次）。轨道预测参数一般由卫星运营商提供，设备侧只需按表调度——表的下发与更新机制是设备固件要实现的。
易错点补充
- 拿地面重传超时跑卫星：卫星往返时延按秒计，地面毫秒级重传超时会触发无意义重发，重传参数按场景分套；
- 盲发浪费电量：卫星不可见时发射等于浪费电量与带宽，窗口预测是省电关键；
- 多普勒补偿不做：不补偿频偏的链路在卫星过境时频繁丢帧，补偿量由运营商参数或设备自测。
关键实现清单
- 卫星场景用 LR-FHSS 或专有配置，禁用地面 CSS 参数
- 设备按过境窗口调度发射，窗口外盲发等于浪费
- 多普勒频移要做预补偿或接收端校正
- 重传超时按卫星往返时延（秒级）配置
典型故障与处置
| 现象 | 原因 | 处置 |
|---|---|---|
| 窗口内仍收不到 | 频偏未补偿或窗口表过期 | 核对轨道参数与频偏 |
| 电量消耗异常 | 窗口外盲发 | 检查窗口调度逻辑 |
| 丢帧频繁 | 重传参数用地面毫秒级 | 改按秒级超时重传 |
卫星直连的适用边界
卫星直连不是"哪里都能连"的万能方案，适用边界要划清楚：地理上——只在无地面覆盖的区域（海洋、荒漠、极地）才值得，有地面网关的区域用地面更便宜更快；业务上——数据稀疏、非实时、单次报文几十字节的遥测（定位、状态、读数）适合，实时控制不适合；成本上——卫星服务按条计费，频繁上报的成本远高于地面网络，先把上报频率压到业务底线。
| 维度 | 适合 | 不适合 |
|---|---|---|
| 区域 | 无地面覆盖 | 有地面网关 |
| 业务 | 稀疏遥测 | 实时控制 |
| 频率 | 分钟级以上 | 秒级上报 |
| 成本 | 低频低字节 | 高频大报文 |
落地建议：卫星直连作为"补充通道"而非"唯一通道"——设备优先走地面，地面不可用时切卫星，双通道按可用性与成本自动选择。这比"全上卫星"和"全不上卫星"都更符合工程实际。
卫星服务的接入方式
卫星服务通常由运营商提供地面站与云接口：设备通过卫星上行到地面站，运营商把数据转成标准协议（MQTT/HTTP）交给应用。设备侧要实现的只有两件事：过境窗口调度（按运营商下发的窗口表决定何时发射）与报文格式约定（载荷长度、加密方式按运营商规范）。协议栈本身不需要大改——卫星侧的上行本质是"一个超远距离的网关"。
与地面网络的混合规划
卫星直连与地面 LoRaWAN 可共用同一套应用层：设备上报的数据格式与解密逻辑完全一致，只是传输通道不同。规划时把"通道"与"业务"解耦——业务层只管字节，通道层按可用性与成本选地面或卫星——这样未来新增通道（如新的卫星运营商）不需要改业务代码。
一条原则：卫星直连的工程本质是用时间换距离——用更低的速率、更长的空中时间与更慢的调度，换取几百公里的覆盖。把这条权衡记在心里，就不会拿地面网络的指标去要求卫星链路。