本节摘要:终端存在的意义是"多数时间睡觉"——本节的 Class A/B/C 定义了怎么醒来、醒多久、能不能被随时呼叫;OTAA(空中激活)则决定一台陌生设备如何被网络收编、得到自己的地址与密钥。承接 5.2 的下行调度,通往 5.4 物理层与 ADR。
LoRaWAN 最耗电的动作就是"听"——只要开着射频接收,电就哗哗地跑。所以协议按"愿意醒多久听指令"把终端分成三档:Class A、Class B、Class C。
Class A 是底线,最省电、所有 LoRaWAN 设备必须支持。它的行为是:终端自发上行(说一句)后,立刻打开两个短接收窗(RX1、RX2)听一下,然后继续睡。下行只能在这两个窗口里 插队。虽然它几乎不主动监听,但对绝大多数"定期上报"的遥测传感器已经足够。
Class B 在 Class A 基础上,用网关下发的信标(Beacon)对时,让终端在预设的时刻也打开接收窗,从而支持"网络想找它时能在约定时间找到"。代价是比 Class A 多一些监听耗电,适合需要周期被询或下行的设备。
Class C 终端几乎一直开着接收窗,网络可以随时下发。它最不省电,适合有常电供应(插座供电)的网关、路灯、集中器等角色。功耗与 "可呼叫性" 的交换在下面这张时间窗图里一目了然:

设备进入网络前是"陌生人",LoRaWAN 通过**空中激活(OTAA)**完成收编。关键前提是每台设备出厂已烧入一组身份与密钥:DevEUI(设备唯一 EUI)、AppEUI/JoinEUI(归所属应用)、以及 AppKey(参与算 session key 的建档密钥)。入网就两步交谈:
入网成功后,终端与网络服务器各自独立推导出网络会话密钥 NwkSKey 与应用会话密钥 AppSKey,随后的业务通信都用这对密钥加解密(详见 5.5)。另一个"更省事但不推荐"的激活方式是 ABP(personalized activation,把会话密钥预先烧进设备),省了入网握手,却牺牲了密钥的新鲜与灵活性。
ABP 貌似导入就能用,实则有几个隐患:密钥长期写死易被抄板、会话不轮换不利于安全。工程上更稳的做法是 OTAA——让设备每次加电可选重新入网、密钥按会话新鲜派生。省那一次握手的时间,换来的是整个生命周期的安全弹性,这笔账多数团队算得过来。
⚠️ 常见坑:OTAA 入网后若服务端没管好"重复的 DevNonce",攻击者可能重放注册触发密钥混淆;接入侧要对非单调递增的帧计数保持警惕。
Class 不是越高级越好,而是"要多少可呼叫性,就牺牲多少省电"。现实中用一张表把"能干什么、烧多少电、适合谁"对起来选:
| Class | 接收行为 | 可呼叫性 | 功耗 | 典型角色 |
|---|---|---|---|---|
| A | 上行后开 RX1/RX2 | 弱(需先发上行) | 最低 | 抄表、土壤、井盖传感 |
| B | 信标定时开窗 | 中(按约定时刻) | 中 | 周期性询器、需下行的传感器 |
| C | 几乎常驻 | 强(随时可发) | 最高 | 常电的网关/路灯/集中器 |
一个判断顺序供你参考:先问"设备有没有常电"→ 有,可考虑 C;再看"多久要被主动找一次"→ 很频繁用 B、只偶尔用 A。 大多数野外电池传感最终都落到 Class A,正是因为它用"被呼叫次数"换来了最长的电池寿命。
入网那步"用 AppKey 推会话密钥"最值得展开。AppKey 是设备出厂唯一的长期密钥,不适合天天直接加密业务数据;OTAA 的做法是用它做一次密钥派生:入网协商出新鲜随机数 AppNonce,再结合与设备身份派生出 NwkSKey 与 AppSKey 两把会话密钥。于是"长期密钥只在入网的那一瞬间用一下",之后所有业务都由这两把按月/按会话新鲜派生的会话密钥保护。理解这个"用长期钥签一次、换回整套短期钥"的机制,是读懂 LoRaWAN 安全架构的关键一环(5.5 会再细化)。
给现场加一台新终端,最省心的路径是把它的 DevEUI/AppEUI/AppKey 一次性登记进网络服务器的白名单,然后上电让设备走 OTAA。核对时常用的三个信号是:设备发出 Join-Request(随机 DevNonce 递增)、网服回 Join-Accept、随后设备能收到下行并发起第一笔加密业务帧。若停在某一步,多半是 AppKey 不一致(Accept 解不开)或白名单没登记(请求被拒)。顺着这三步"敲门"往往几分钟就能定位一台"死活入不了网"的新设备。
一个建议:新设备出厂建议统一烧好全套身份密钥,上线只做"登记 + 上电",把入网动作收敛成一条无脑流程,既减少误配,也方便批量发放。
设备如何醒来、如何入门都清楚了,5.4 钻进物理层细看"扩频 + ADR"这套省电又与距离博弈的底牌。