4. OTAA入网流程：消息结构与随机数
OTAA，全称是Over-The-Air Activation。说白了，就是设备第一次入网时，跟网络服务器之间的一次“握手”。
我刚开始接触LoRaWAN时，觉得这流程挺绕的。后来亲手抓了几次包，才把每个字节都看明白。今天咱们就把Join-Request和Join-Accept这两条消息，拆开揉碎了讲。
核心要点：OTAA入网的核心，就是设备用一组预置的密钥（AppKey），向网络证明自己的身份，并安全地拿到后续通信用的会话密钥。
4.1 Join-Request消息结构
设备上电后，第一件事就是发Join-Request。这条消息不长，但每个字段都有讲究。
| 字段 | 长度（字节） | 说明 |
|---|---|---|
| AppEUI | 8 | 应用标识符，相当于应用的“身份证号” |
| DevEUI | 8 | 设备标识符，全球唯一，烧录时固定 |
| DevNonce | 2 | 设备生成的随机数，防重放攻击 |
你看，就三个字段，总共18个字节。但这里有个坑——Join-Request本身是不加密的。为什么？因为此时设备还没有会话密钥。所以AppEUI和DevEUI都是明文传输的。
注意：DevNonce虽然只有2个字节，但它的随机性至关重要。我曾经见过一批设备，因为随机数生成器质量太差，导致DevNonce频繁重复，结果入网失败率高达30%。
我个人习惯，在设备出厂前，会专门写个脚本跑1000次DevNonce生成，检查有没有重复。嗯，这步不能省。
4.2 Join-Accept消息结构
网络服务器收到Join-Request后，如果验证通过，就会回复Join-Accept。这条消息是加密的，用的就是设备预置的那个AppKey。
| 字段 | 长度（字节） | 说明 |
|---|---|---|
| JoinNonce | 3 | 服务器生成的随机数，用于派生会话密钥 |
| NetID | 3 | 网络标识符，区分不同的LoRaWAN网络 |
| DevAddr | 4 | 设备在网络中的短地址，后续通信用这个 |
| DLSettings | 1 | 下行链路参数，比如速率、RX窗口配置 |
| RxDelay | 1 | 接收窗口延迟，单位秒 |
| CFList（可选） | 0或16 | 频道频率列表，用于动态配置 |
你想想看，Join-Accept里最关键的是哪个字段？我个人觉得是JoinNonce。因为它直接决定了后续会话密钥的“种子”。
小技巧：Join-Accept的MIC（消息完整性校验码）是附加在末尾的，长度为4字节。设备收到后，第一件事就是用AppKey重新计算MIC，比对一致才继续处理。这是防止伪造Join-Accept的第一道防线。
4.3 随机数生成：DevNonce与JoinNonce
随机数，是整个OTAA流程的“安全基石”。为什么这么说？
咱们先看DevNonce。设备每次发起入网请求，都要生成一个新的DevNonce。网络服务器会记录每个设备用过的DevNonce，如果发现重复，直接拒绝入网。
这其实是个防重放攻击的机制。假设没有DevNonce，攻击者只要抓到一个Join-Request，就可以不断重放，让服务器给设备分配新的会话密钥——那整个网络就乱套了。
JoinNonce呢？它是服务器生成的，用于派生会话密钥。注意，JoinNonce是3个字节，比DevNonce多1个字节。为什么？因为服务器要保证，同一个设备每次入网拿到的JoinNonce都不同，这样才能派生出不同的会话密钥。
关键区别：
- DevNonce（2字节）：设备生成，防重放，服务器记录历史值
- JoinNonce（3字节）：服务器生成，派生会话密钥，设备用于计算
我记得有一次，客户反馈设备偶尔入网失败。排查了半天，发现是设备端的随机数生成器在低温环境下性能下降，生成的DevNonce出现了大量重复。后来换了硬件随机数模块，问题才解决。
所以，我建议你在选型时，一定要关注MCU的硬件随机数生成器质量。软件伪随机数，说实话，在LoRaWAN这种对安全要求高的场景下，不太靠谱。
4.4 完整入网流程时序图
下面这张图，把整个OTAA流程串起来了。你可以对照着看，每一步对应哪条消息、哪个随机数。
流程其实就三步：
- 设备发起：生成DevNonce，组装Join-Request，明文发送
- 服务器响应：验证DevNonce，生成JoinNonce，派生会话密钥，加密返回Join-Accept
- 设备完成：解密Join-Accept，用JoinNonce派生同样的会话密钥，入网成功
避坑指南：我曾经遇到过一个案例，设备端和服务器端用的密钥派生算法版本不一致，导致两边算出来的会话密钥对不上。设备明明收到了Join-Accept，但后续通信全部失败。排查了整整两天才发现是固件库版本问题。
所以，我建议你在开发时，一定要确认设备SDK和网络服务器使用的LoRaWAN规范版本完全一致。1.0.x和1.1.x的密钥派生算法是有差异的。
4.5 小结
OTAA入网流程，说白了就是一次安全的密钥交换过程。Join-Request负责“自我介绍”，Join-Accept负责“下发凭证”。而DevNonce和JoinNonce这两个随机数，一个防重放，一个派生密钥，缺一不可。
嗯，理解了这些，你就能明白为什么OTAA比ABP更安全了——每次入网都会生成全新的会话密钥，即使之前的密钥泄露，也不会影响后续通信。