02-Class A
3.2 Class A/B/C 状态机与接收窗口的时间账
本节摘要：Class A 的两次接收窗口、Class B 的信标与插槽、Class C 的持续监听，本质都是"用多久的接收时间换多大的下行能力"。本节把三类 Class 的时序与时间开销算清楚，并给出实现状态机时的时间预算表。位置：3.1 算了字节账，本节算时间账，两者共同决定设备的省电剖面。
三类 Class 的时间账
| Class | 接收时机 | 接收时间开销 | 下行能力 | 典型设备 |
|---|---|---|---|---|
| A | 上行后 RX1（默认 1s）、RX2（2s） | 每次上行后仅约 2 个窗口 | 上行后才有下行机会 | 绝大多数电池设备 |
| B | Class A 基础 + 周期信标与插槽 | 定期醒来接收，通常约 1% 占空比 | 可随时下行（插槽内） | 需定期下行的场景 |
| C | 除发射外持续接收 | 几乎 100% | 任意时刻下行 | 有源供电设备 |
Class A 的时序拆解
上行完成后，设备按 RECEIVE_DELAY1（默认 1 秒）开启 RX1，RX1 关窗后隔 RECEIVE_DELAY2 − RECEIVE_DELAY1（默认再 1 秒）开启 RX2。RX 窗口的标准长度是 RECEIVE_DELAY 前的 RX_SYMBOL_TIMEOUT（默认约 5 个符号时间）。窗口只开几百毫秒就关——这段"短暂开启"的时长，正是省电的关键：其余时间射频完全关闭，电流从毫安级掉到微安级。
上行发射结束 t=0 RX1 开启 t=1s，持续约 0.2s（SF12 下 5 符号 ≈ 164ms） RX2 开启 t=2s，持续约 0.2s 之后射频关闭，进入休眠（Class A 常态）
Class B 的插槽账
Class B 在 Class A 基础上叠加：网关每 128 秒广播一个信标（Beacon），设备据信标推算自己的 ping slot（每 128 秒内 1–128 个插槽之一，设备只在该插槽醒来）。一个插槽的接收时间约 10–30ms。设备用"醒来频率"换"下行实时性"：插槽越多下行越快，但接收时间与耗电同步上升。
Class C 的代价
Class C 除发射瞬间外持续监听，接收时间开销几乎 100%。下行实时性最好（网络服务器可随时下行），但耗电与占用信道资源也最大——只适合有源供电、需要随时接收的节点（如网关、有源中继）。
状态机实现的时间预算表
| 事件 | 时间预算 | 超时后果 |
|---|---|---|
| 上行结束 → RX1 开启 | ±20ms 内（依赖 32kHz 时钟） | 窗口错位，下行丢失 |
| RX1 窗口时长 | 约 0.2s（SF12） | 过长浪费，过短漏包 |
| RX1 → RX2 间隔 | 1s（RX2 延迟 − RX1 延迟） | 配置不一致导致收不到 |
| 休眠唤醒精度 | 32kHz 晶振漂移按 ppm 计 | 长时间漂移后窗口偏移 |
与网络服务器的时间对齐
接收窗口能否准确命中，是 MAC 层最容易出"玄学故障"的地方，根因几乎都是设备与网络服务器对时间的理解不一致。三个对齐环节：
环节一：上行帧到达时间的基准。 网络服务器以"收到上行帧的时刻"为基准计算下行发送时刻（RX1 延迟等），因此网关必须上报精确的接收时间戳（GPS 或 PTP 授时），NS 才能把下行对准设备的 RX 窗口。环节二：设备侧的延迟基准。 设备以"上行发射完成的时刻"为基准开启 RX1/RX2，两个基准之间差一个"上行传播时间"——地面场景可忽略，卫星场景（第 9 章）就必须显式补偿。环节三：时钟漂移。 设备的 32kHz 低功耗时钟长期运行会漂移，长时间休眠后窗口偏移累积，成熟协议栈会在每次上行后重新校准定时器基准。
状态机实现的时间预算表
| 事件 | 时间预算 | 超时后果 | 实现提示 |
|---|---|---|---|
| 上行完成 → RX1 开启 | ±20ms（32kHz 时钟精度） | 窗口错过，下行丢失 | 用硬件定时器，避免软件延迟 |
| RX1 窗口时长 | 5 个符号时间（SF12 约 164ms） | 过短漏包，过长费电 | 从符号时间换算，勿写死 |
| RX1 → RX2 间隔 | RECEIVE_DELAY2 − RECEIVE_DELAY1 = 1s | 与 NS 配置不一致则全落空 | 参数从网络下发，别本地写死 |
| 休眠 → 定时唤醒 | 32kHz 晶振 ppm 漂移 | 长时间后窗口整体偏移 | 每次上行后重新对时 |
Class B 的同步失败恢复
Class B 依赖信标同步，一旦连续多个信标未收到（网络抖动、网关故障），设备要能降级回 Class A——实现上必须把"信标丢失计数"与"降级开关"做成独立模块，避免信标解析故障卡死整个 MAC 状态机。恢复流程：设备上报 Class B 状态给 NS，NS 侧同步降级下行调度策略。
易错点补充
- RX 窗口用软件轮询实现：窗口毫秒级，软件循环会抖动，必须硬件定时器或 DMA；
- Class C 忽略发射屏蔽：发射期间收不到下行，NS 调度器要知道设备的发射窗口（靠帧计数与速率推断），否则下行冲突；
- 把 RX 偏移当固定值：RXParamSetup 可以动态改偏移，设备收到指令后要立即更新定时配置，否则后续窗口全部错位。
易错点清单
- 窗口时间用系统时钟硬凑：接收窗口依赖低功耗 32kHz 时钟，其 ppm 漂移在长时间休眠后会累积，需周期性对时；
- 把 RX1/RX2 延迟配成不同值而不自知：网络服务器与设备必须使用一致的延迟配置，否则下行总落空；
- Class C 设备忘记处理"发射期间的接收窗口"：发射时无法接收，网络服务器调度要避开该时段。
要点回顾：Class A 用两次短窗口换极低功耗，Class B 用周期性插槽换下行实时性，Class C 用持续监听换随时下行；时间预算必须精确到窗口开关毫秒级。下一节看 MAC 命令引擎与占空比这道硬约束。
小结与延伸
三类 Class 的取舍本质是"接收时间预算"的分配：Class A 用约 0.4s/次的开销换极低功耗，Class B 用周期插槽换可预测下行，Class C 用持续监听换随时下行。时间账的关键数字：RX 窗口约 5 个符号、默认延迟 1s/2s、32kHz 时钟漂移需周期性对时。延伸思考：混合 Class 设备（平时 A、特定时段切 B）是省电与下行的常见折中，实现时状态机要支持"运行时切换 + 信标同步恢复"，切换失败要能安全回退 Class A——这是工业表计场景的高频需求。