在 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 后：

  1. 根据 JoinEUI/AppEUI 查找对应设备的 AppKey（和 NwkKey，LoRaWAN 1.1）
  2. 验证 MIC，确认消息完整性
  3. 检查 DevNonce，防止重放攻击（每个 DevNonce 只能使用一次）
  4. 验证通过后，为设备分配 DevAddr（32 位设备网络地址）
  5. 生成 Join Nonce（网络服务器侧随机数）
  6. 构造 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 = aes_encrypt(AppKey, 0x01 | AppNonce | NwkID | DevNonce)
AppSKey = aes_encrypt(AppKey, 0x02 | AppNonce | NwkID | DevNonce)

LoRaWAN 1.1 增加了密钥分离机制，派生四组密钥：

1.1 引入了 JoinEUI（替代 AppEUI 的叫法）和 NwkKey（与 AppKey 分离），实现了网络层和应用层密钥的分离，提升了漫游场景下的安全性。

OTAA 的安全特性

ABP：个性化入网

ABP 跳过了 Join 流程，设备出厂时直接预配置好所有通信参数，上电即开始收发数据。

预配置内容

ABP 方式下，以下信息需要在设备出厂前写入，同时在网络服务器侧预先录入：

参数 说明
DevAddr 设备网络地址（32 位），需在网络服务器分配范围内唯一
NwkSKey 网络会话密钥（128 位 AES 密钥）
AppSKey 应用会话密钥（128 位 AES 密钥）

设备不需要 DevEUI、JoinEUI 或 AppKey（除非后续要切换到 OTAA）。

工作方式

ABP 设备上电后直接进入工作状态：

  1. 使用预配置的 DevAddr 作为源地址
  2. 使用 NwkSKey 计算 MIC 和加密 MAC 命令
  3. 使用 AppSKey 加解密应用数据
  4. 在默认信道上开始发送上行数据

没有 Join Request / Join Accept 的握手过程。

ABP 的帧计数器问题

ABP 设备需要管理上行（FCntUp）和下行（FCntDown）帧计数器。网络服务器会跟踪这些计数器来防止重放攻击——如果设备重启后帧计数器归零，而网络服务器记录的值更大，设备的数据帧会被丢弃。

实际操作中有两种处理方式：

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 的场景

可以用 ABP 的场景

一个常见误区

"ABP 省电，因为不需要 Join 流程。"

实际上 Join 流程的功耗很小——Join Request 和 Join Accept 各一条消息，整个过程通常在十几秒内完成，之后设备即可休眠。相比设备整个生命周期（通常数年）的能耗，入网阶段的能耗可以忽略不计。选 ABP 省的不是电，是开发阶段的配置时间——但这个便利在生产环境中的代价是安全性降低和运维复杂度上升。

实践注意事项

OTAA 实践

  1. DevEUI 必须全局唯一：建议使用 IEEE EUI-64（基于设备 MAC 派生），不要用硬编码的默认值
  2. AppKey 安全存储：AppKey 是根密钥，泄露后整个设备的通信可被解密。建议存储在安全元件（SE）中，或至少使用 MCU 的 Flash 加密功能
  3. DevNonce 持久化：DevNonce 必须存储在非易失性存储中，重启后递增。如果设备重启后 DevNonce 回退，网络服务器会拒绝 Join Request
  4. Join 失败重试：设备应实现指数退避重试机制，避免 Join 失败后立即重发导致信道拥塞
  5. Join 窗口：Join Accept 在 Join Request 后的 RX1（默认 5 秒）和 RX2 窗口下发，设备必须在这两个窗口内监听

ABP 实践

  1. 帧计数器持久化：将 FCntUp 和 FCntDown 存储在非易失性存储中（RTC 备份寄存器、Flash 或 EEPROM）
  2. DevAddr 规划：DevAddr 的 7 位 NwkID 部分需与网络服务器的 NetID 匹配，25 位设备地址部分需在网络内唯一
  3. 密钥安全：ABP 的密钥在出厂时写入，生产环节需确保密钥不被泄露（如生产日志、测试记录等）
  4. 避免公开仓库泄露：如果在 GitHub 等开源仓库中分享代码，不要硬编码 NwkSKey 和 AppSKey

与 ThinkLink 平台配合

在 ThinkLink 平台上：

总结

OTAA ABP
一句话 像手机连 Wi-Fi——自动认证、自动获取地址 像固定电话——出厂就配好号码和线路
安全性 高 低
生产推荐 ✅ ❌（仅限调试/教学）
LoRaWAN 1.1 必须 不推荐

简单结论：生产环境用 OTAA，调试和教学用 ABP。 如果你的设备数量超过 10 台，或者部署在不可控的物理环境中，OTAA 是唯一合理的选择。

本文基于 LoRaWAN 1.0.4 和 1.1 规范编写。技术细节参考 LoRa Alliance 官方规范文档，实践建议来自 ThinkLink 平台运维经验。

ThinkLink 是 ManThink 推出的物联网平台产品，提供 LoRaWAN 网络管理、设备运维和数据服务。