在 LoRaWAN 网络中，设备要开始收发数据之前，必须先完成”入网”（Activation）。入网方式决定了设备如何获得网络地址和通信密钥，直接影响安全性、部署复杂度和后续运维。
LoRaWAN 规范定义了两种入网方式：OTAA（Over-The-Air Activation，空中入网）和 ABP（Activation By Personalization，个性化入网）。本文梳理两者的工作原理、差异和选型建议。
OTAA：空中入网
OTAA 是 LoRaWAN 推荐的入网方式。设备在出厂时不携带会话密钥，而是在首次上电后通过网络空中完成身份认证和密钥协商。
工作流程
OTAA 的入网过程分为三步：
1. 设备发起 Join Request
设备向网络服务器发送 Join Request 消息，携带以下信息：
| 字段 | 说明 |
| JoinEUI / AppEUI | 应用标识符（64 位），标识设备要加入的应用或网络服务器 |
| DevEUI | 设备全局唯一标识符（64 位），通常基于设备硬件 MAC 或出厂烧录 |
| DevNonce | 设备生成的随机数（16 位），每次 Join Request 递增，防止重放攻击 |
Join Request 消息使用 AppKey 进行 MIC（Message Integrity Code）计算，确保消息未被篡改。
2. 网络服务器验证并发送 Join Accept
网络服务器收到 Join Request 后：
- 根据 JoinEUI/AppEUI 查找对应设备的 AppKey（和 NwkKey，LoRaWAN 1.1）
- 验证 MIC，确认消息完整性
- 检查 DevNonce，防止重放攻击（每个 DevNonce 只能使用一次）
- 验证通过后，为设备分配 DevAddr（32 位设备网络地址）
- 生成 Join Nonce（网络服务器侧随机数）
- 构造 Join Accept 消息，用 AppKey 加密后下发
Join Accept 消息携带的关键信息：
| 字段 | 说明 |
| JoinNonce | 网络服务器生成的随机数（24 位），用于密钥派生 |
| NetID | 网络标识符（24 位），标识所属网络 |
| DevAddr | 分配给设备的网络地址（32 位） |
| DLSettings | 下行设置（RX2 数据速率、RX1 偏移等） |
| RxDelay | 接收窗口延迟 |
| CFList | 可选的信道频率列表 |
3. 设备派生会话密钥
设备收到 Join Accept 后，用 AppKey 解密，然后基于 AppKey、JoinNonce、DevNonce 和 NetID 派生出会话密钥。
LoRaWAN 1.0.x（1.0.2 / 1.0.3 / 1.0.4）派生两组密钥：
- NwkSKey（Network Session Key）：用于 MAC 层消息完整性校验和数据加密
- AppSKey（Application Session Key）：用于应用层数据加密
派生公式（简化表示）：
LoRaWAN 1.1 增加了密钥分离机制，派生四组密钥：
- FNwkSIntKey：前向网络会话完整性密钥
- SNwkSIntKey：服务网络会话完整性密钥
- NwkSEncKey：网络会话加密密钥
- AppSKey：应用会话密钥
1.1 引入了 JoinEUI（替代 AppEUI 的叫法）和 NwkKey（与 AppKey 分离），实现了网络层和应用层密钥的分离，提升了漫游场景下的安全性。
OTAA 的安全特性
- 密钥从不上空口传输：AppKey/NwkKey 预置在设备和网络服务器中，会话密钥通过 Join 流程在两侧独立派生，空口上只传加密后的 Join Accept
- DevNonce 防重放：每个 DevNonce 只能用一次，网络服务器会记录已使用的 DevNonce
- 支持密钥轮换：设备可以重新发起 Join 流程，获取新的会话密钥
- 支持漫游：LoRaWAN 1.1 的密钥分离设计为跨网络漫游提供了基础
ABP：个性化入网
ABP 跳过了 Join 流程，设备出厂时直接预配置好所有通信参数，上电即开始收发数据。
预配置内容
ABP 方式下，以下信息需要在设备出厂前写入，同时在网络服务器侧预先录入：
| 参数 | 说明 |
| DevAddr | 设备网络地址（32 位），需在网络服务器分配范围内唯一 |
| NwkSKey | 网络会话密钥（128 位 AES 密钥） |
| AppSKey | 应用会话密钥（128 位 AES 密钥） |
设备不需要 DevEUI、JoinEUI 或 AppKey（除非后续要切换到 OTAA）。
工作方式
ABP 设备上电后直接进入工作状态：
- 使用预配置的 DevAddr 作为源地址
- 使用 NwkSKey 计算 MIC 和加密 MAC 命令
- 使用 AppSKey 加解密应用数据
- 在默认信道上开始发送上行数据
没有 Join Request / Join Accept 的握手过程。
ABP 的帧计数器问题
ABP 设备需要管理上行（FCntUp）和下行（FCntDown）帧计数器。网络服务器会跟踪这些计数器来防止重放攻击——如果设备重启后帧计数器归零，而网络服务器记录的值更大，设备的数据帧会被丢弃。
实际操作中有两种处理方式：
- 网络服务器侧重置：在 ThinkLink 等平台上手动重置设备的帧计数器（适合调试）
- 设备侧持久化：将帧计数器存储在非易失性存储中，重启后从上次的值继续（适合生产环境）
OTAA vs ABP：逐项对比
| 维度 | OTAA | ABP |
| 安全性 | 高——密钥通过 Join 流程派生，不上空口传输 | 低——密钥需在出厂时写入设备并在服务器侧录入，存在泄露风险 |
| 密钥轮换 | 支持——重新 Join 即可获得新密钥 | 不支持——密钥固定，更换需要重新烧录设备 |
| DevAddr 分配 | 网络服务器动态分配 | 出厂时固定，需手动管理唯一性 |
| 部署复杂度 | 设备只需预置根密钥，网络服务器管理其余 | 设备和服务器都需要预配置完整参数 |
| 入网延迟 | 有——需完成 Join 流程（通常 5-15 秒） | 无——上电即工作 |
| 帧计数器管理 | Join 后从 0 开始，无冲突问题 | 需手动管理，重启后可能被服务器拒绝 |
| 漫游支持 | 支持（LoRaWAN 1.1 密钥分离设计） | 不支持 |
| LoRaWAN 1.1 兼容性 | 完整支持——1.1 要求 OTAA | 1.1 不推荐 ABP |
| 适用规模 | 适合大规模部署 | 适合小规模或测试 |
| 设备休眠 | Join 后可正常休眠，周期性唤醒发送 | 同样支持休眠 |
| 网络切换 | 可通过更改 JoinEUI 切换网络 | 需重新烧录所有参数 |
选型建议
推荐 OTAA 的场景
- 生产部署：任何超过个位数的设备部署，都应该用 OTAA
- 需要安全性的场景：涉及敏感数据或有合规要求的应用
- 大规模部署：OTAA 的 DevAddr 由服务器动态分配，避免冲突
- 需要漫游的场景：跨网络/跨区域部署
- LoRaWAN 1.1 网络：1.1 的安全特性依赖 OTAA
可以用 ABP 的场景
- 开发调试：本地开发时快速验证设备通信，省去 Join 流程
- 教学演示：课堂演示中简化流程，让学生专注理解数据收发
- 极小规模固定部署：比如一两台设备的永久固定场景，且对安全性要求不高
- 无下行链路的场景：设备只发不收，且不需要密钥管理（但仍需注意安全性权衡）
一个常见误区
“ABP 省电，因为不需要 Join 流程。”
实际上 Join 流程的功耗很小——Join Request 和 Join Accept 各一条消息，整个过程通常在十几秒内完成，之后设备即可休眠。相比设备整个生命周期（通常数年）的能耗，入网阶段的能耗可以忽略不计。选 ABP 省的不是电，是开发阶段的配置时间——但这个便利在生产环境中的代价是安全性降低和运维复杂度上升。
实践注意事项
OTAA 实践
- DevEUI 必须全局唯一：建议使用 IEEE EUI-64（基于设备 MAC 派生），不要用硬编码的默认值
- AppKey 安全存储：AppKey 是根密钥，泄露后整个设备的通信可被解密。建议存储在安全元件（SE）中，或至少使用 MCU 的 Flash 加密功能
- DevNonce 持久化：DevNonce 必须存储在非易失性存储中，重启后递增。如果设备重启后 DevNonce 回退，网络服务器会拒绝 Join Request
- Join 失败重试：设备应实现指数退避重试机制，避免 Join 失败后立即重发导致信道拥塞
- Join 窗口：Join Accept 在 Join Request 后的 RX1（默认 5 秒）和 RX2 窗口下发，设备必须在这两个窗口内监听
ABP 实践
- 帧计数器持久化：将 FCntUp 和 FCntDown 存储在非易失性存储中（RTC 备份寄存器、Flash 或 EEPROM）
- DevAddr 规划：DevAddr 的 7 位 NwkID 部分需与网络服务器的 NetID 匹配，25 位设备地址部分需在网络内唯一
- 密钥安全：ABP 的密钥在出厂时写入，生产环节需确保密钥不被泄露（如生产日志、测试记录等）
- 避免公开仓库泄露：如果在 GitHub 等开源仓库中分享代码，不要硬编码 NwkSKey 和 AppSKey
与 ThinkLink 平台配合
在 ThinkLink 平台上：
- OTAA 设备：在平台录入 DevEUI 和 AppKey，设备上电后自动完成 Join
- ABP 设备：在平台录入 DevAddr、NwkSKey、AppSKey，设备上电后直接通信
- 平台支持随时查看设备入网状态和帧计数器
- 如遇帧计数器冲突，可在设备管理页面手动重置
总结
| OTAA | ABP | |
| 一句话 | 像手机连 Wi-Fi——自动认证、自动获取地址 | 像固定电话——出厂就配好号码和线路 |
| 安全性 | 高 | 低 |
| 生产推荐 | ✅ | ❌（仅限调试/教学） |
| LoRaWAN 1.1 | 必须 | 不推荐 |
简单结论：生产环境用 OTAA，调试和教学用 ABP。 如果你的设备数量超过 10 台，或者部署在不可控的物理环境中，OTAA 是唯一合理的选择。
本文基于 LoRaWAN 1.0.4 和 1.1 规范编写。技术细节参考 LoRa Alliance 官方规范文档，实践建议来自 ThinkLink 平台运维经验。
ThinkLink 是 ManThink 推出的物联网平台产品，提供 LoRaWAN 网络管理、设备运维和数据服务。