ManThink 技术专栏 | LoRaWAN 系列第 5 期 面向开发者、方案工程师与 IoT 项目决策者
翻看任何一个 LoRaWAN 设备的规格书，你都会看到一行参数：Device Class。水表写 Class A，智能路灯可能是 Class B，而继电器控制柜、网关这类设备则是 Class C。
这三个字母不是营销标签，而是 LoRaWAN 协议里对"设备如何接收下行数据"的三种约定。它直接决定了：
一句话概括本质：LoRaWAN 的上行容易，下行昂贵。设备发数据很轻松，但要"随时听得到平台说话"，就得让射频接收机一直开着——而接收机的功耗，往往比深睡眠高出一百倍以上。Class A/B/C 就是协议针对这个矛盾给出的三档解法。
这篇文章把三类机制讲透，并给出一张可以直接拿去用的选型决策表。
LoRaWAN 是低功耗广域网络（LPWAN），它的典型终端是电池供电的传感器，设计目标是"一节电池用 5–10 年"。
要实现这一点，设备绝大部分时间必须处于深度睡眠——而睡眠中的设备是"聋"的，听不到网关的任何呼叫。如果想让平台能随时下发指令（比如远程拉闸、修改上报周期），设备就必须持续开着的接收机，电池寿命立刻从"十年"缩水到"几个月"。
功耗和下行实时性，天生就是一对矛盾。 Class A、B、C 不是三种"技术"，而是这条矛盾线上的三个折中点：从"完全不为下行留功耗"（A），到"定时醒一下看看有没有指令"（B），再到"一直在线"（C）。
Class A 是所有 LoRaWAN 设备的必选基线——不管标称什么 Class，设备都首先实现 Class A 行为。
它的逻辑很朴素：设备平时深睡，只有自己发完一条上行之后，才短暂打开两个接收窗口：
设备 ──上行──► 网关/NS
│
│ 等待 RECEIVE_DELAY1（默认 1 秒）
▼
RX1 窗口开启（短瞬）
│ 若无数据，再等 1 秒
▼
RX2 窗口开启（短瞬）
│ 若仍无数据
▼
回到深度睡眠
两个窗口都很短，开完立刻回到睡眠。也就是说，网络想给 Class A 设备发指令，只能"搭车"——必须等设备先说话。平台下发的内容会在 NS 排队，等设备下一次上行后的 RX1/RX2 里送达。
| 维度 | 表现 |
|---|---|
| 功耗 | 三类中最低，深睡眠占绝对主导 |
| 下行时机 | 只能跟随上行，无法主动唤醒 |
| 下行延迟 | 取决于上报周期：每小时报一次，指令最坏要等近 1 小时 |
| 典型供电 | 一次电池（锂电池），寿命可达 8–10 年 |
适用场景：水表、电表、气表，温湿度/土壤传感器，一切"以采集为主、几乎不需要下行"的设备。这也是为什么 LoRaWAN 的传感器生态里 Class A 占绝对主流。
Class B 在 Class A 的基础上，增加了一套"定时醒来看一眼"的机制：
Ping Slot 的周期是可配置的（协议定义了从秒级到 128 秒的几档）：周期越短，下行越及时，但醒得越频繁、功耗越高。
Beacon 同步后，设备的时间轴：
──┬────┬────┬────┬────┬──►
│ │ │ │
Ping Ping Ping Ping ← 定时短开窗
Slot Slot Slot Slot
(醒几毫秒，其余时间深睡)
| 维度 | 表现 |
|---|---|
| 功耗 | 略高于 Class A（多出 Beacon 接收和 Ping Slot 的唤醒） |
| 下行时机 | 可在 Ping Slot 被调度，不再完全依赖上行 |
| 下行延迟 | 有上界：最坏等一个 Ping Slot 周期 |
| 部署要求 | 网络侧要支持 Beacon 广播——网关和 NS 都必须配合，不是设备单方面能实现的 |
适用场景：智能路灯（需要按季节远程调开关灯计划）、需周期性同步时间的设备、需要在分钟级收到下行指令的测点。Class B 在实际项目中相对少见，一个重要原因就是部署门槛：整条链路（设备-网关-NS）都要支持 Class B。
Class C 干脆放弃"睡眠换功耗"的思路：射频接收机几乎全程开启，只在上行发射的瞬间短暂关闭（避免自干扰），发完立刻回到接收状态。
──RX──RX──RX──│TX│──RX──RX──RX──RX──►
(仅发射时关闭接收)
这样，平台下发的指令几乎可以立即送达，下行延迟从"分钟/小时级"降到"秒级"。
这是工程上必须算清的一笔账。射频接收机的典型工作电流在毫安级到几十毫安级，而 Class A 设备深睡眠电流只有微安级——相差三到四个数量级。
行业里有一个明确的工程结论（而非协议禁令）：Class C 通常不适合一次电池供电的设备。一次电池（如锂亚电池）的容量撑不住持续的 RX 电流，除非做过完整的功耗生命周期预算，否则无法宣称"多年寿命"。
所以 Class C 的典型供电是市电、PoE 或大容量可充电电池。
| 维度 | 表现 |
|---|---|
| 功耗 | 三类中最高，平均电流由 RX 电流主导 |
| 下行时机 | 随时可发，近实时 |
| 下行延迟 | 秒级 |
| 典型供电 | 市电 / PoE / 常供电 |
适用场景：继电器与控制柜（远程分合闸）、工业实时监控、执行器、以及 LoRaWAN 网关自身（网关作为"永远在线"的设备天然是 Class C 形态）。
| 维度 | Class A | Class B | Class C |
|---|---|---|---|
| 接收时机 | 仅上行后 RX1/RX2 | 上行后 + 周期性 Ping Slot | 除发射外持续接收 |
| 下行能力 | 最弱（搭上行的车） | 有调度、有延迟上界 | 近实时 |
| 下行延迟 | 等下次上行（分钟~小时级） | 最坏一个 Ping 周期（秒~分钟级） | 秒级 |
| 功耗 | 最低 | 略高于 A | 最高（RX 主导） |
| 典型供电 | 一次电池 | 电池（容量需相应加大） | 市电/PoE |
| 电池寿命量级 | 5–10 年 | 数年（取决于 Ping 周期） | 不适用一次电池 |
| 网络侧要求 | 无特殊要求 | 网关+NS 需支持 Beacon | 无特殊要求 |
| 典型设备 | 水电气表、温湿度传感器 | 智能路灯 | 继电器、执行器、网关 |
需要强调一点：Class 的选择不改变区域数据率定义，也不能绕过当地的发射限制——它是 MAC 层的接收行为约定，与物理层参数（SF/BW/CR，参见本系列第 4 篇）是相互独立的两个维度。
问题 1：这个设备需要接收下行指令吗？ - 几乎不需要（只上报数据）→ Class A，别犹豫。 - 需要，但等几分钟没关系 → 往下看问题 2。 - 需要秒级响应（控制类）→ Class C，并规划市电/PoE 供电。
问题 2：设备是电池供电吗？ - 是，且要撑 5 年以上 → Class A；若确需周期性下行，评估 Class B 并核算功耗预算。 - 市电/常供电 → Class C 可用，享受实时下行。
问题 3（针对 Class B）：网络基础设施支持吗？ - 网关和 NS 都支持 Beacon 广播吗？不支持的话，Class B 只是纸面能力。
一个实用的经验法则：传感器默认 Class A，执行器默认 Class C，中间地带再考虑 Class B。这也是市面上绝大多数 LoRaWAN 产品线的产品分布现状。
误区一："Class C 更高级，选它准没错。" Class C 不是升级版，而是另一种取舍。把电池传感器配成 Class C，等于让它在 RX 电流上空耗——续航从十年掉到几个月，还占用了网关下行资源。选错 Class 比选错 SF 的代价更直接。
误区二："Class A 设备就完全收不到下行。" 不对。Class A 设备在每次上行后的 RX1/RX2 里都能接收下行——ACK、MAC 命令、参数配置都可以在这两个窗口里完成。只是"时机"被绑定在上行之后。实际项目中，配合合理的上报周期和指令排队机制，Class A 也能完成大部分配置下发需求。
误区三："Class 是设备固有的，不能改。" Class 是 MAC 层行为，很多设备（尤其带可配置固件的 DTU/模组）支持 Class A/C 模式切换，可按项目阶段动态选择：调试期用 Class C 方便实时下发，部署运行后切回 Class A 省电。当然，切换逻辑要考虑功耗与供电的匹配。
Class A/B/C 的本质，是 LoRaWAN 在"低功耗"和"下行实时性"之间画出的三条线：A 把功耗压到极致、把下行交给排队；B 用时间同步换一个有上界的下行延迟；C 用常供电换秒级响应。
理解了这条主线，你看到任何一台 LoRaWAN 设备的 Class 标注，就能立刻推断出它的供电形态、下行能力和适用场景——这比记住任何参数都有价值。
本文由 ManThink 技术团队编写。ManThink 致力于开源与可靠的 LoRaWAN 基础设施：GD6 开源网关（ESP32-S3 + SX1302）支持全球主流频段与主流网络服务器；自研 EdgeBus 边缘计算引擎支持 Class A/C 模式切换，帮助传感器以最低功耗接入 LoRaWAN 网络。
系列阅读： - 第 1 期：LoRaWAN 设备入网流程详解：OTAA vs ABP，怎么选？ - 第 2 期：LoRaWAN ADR 机制解读：谁在控制数据速率 - 第 3 期：LoRaWAN Regional Parameters：为什么 CN470 和 EU868 的频点数不同 - 第 4 期：LoRa 物理层参数：SF、BW、CR 如何影响传输距离和速率