第3章 LoRaWAN协议栈

3. LoRaWAN协议栈：网络架构与核心机制

好，咱们今天来聊聊LoRaWAN协议栈。说实话，很多做智能门锁的朋友，一上来就盯着硬件功耗看，却忽略了协议栈的选择。我个人的经验是，协议栈选对了，功耗问题就解决了一半。

LoRaWAN不是单纯的无线通信，它是一整套网络架构。你想想看，门锁发一条指令，谁在收？谁在处理？谁在响应？这背后就是终端、网关、服务器三层架构在干活。

先看这张图（脑子里想象一下）：

这里有个关键点：终端和网关之间是星型拓扑。没有中继，没有Mesh。为什么？因为中继会引入额外功耗，而且门锁这种固定设备，没必要搞那么复杂。

我的经验：在智能门锁项目中，网关的部署位置很关键。我曾经遇到一个案例，门锁离网关太远，SF（扩频因子）自动跳到12，单次发送时间从30ms飙到800ms，功耗直接炸了。所以，网关覆盖半径建议控制在500米以内，SF尽量用7或8。

LoRaWAN定义了三种终端模式。嗯，这里要重点讲，因为选错了模式，你的门锁可能连一个月都撑不住。

模式	下行接收时机	功耗特点	适用场景
Class A	上行发送后，打开两个短接收窗口	最低，几乎不额外耗电	门锁上报状态、报警
Class B	定时打开接收窗口（信标同步）	中等，需定期唤醒	需要服务器定时查询的门锁
Class C	持续监听，几乎一直接收	最高，不适合电池供电	电控锁、常供电场景

我个人习惯，智能门锁99%的情况用Class A。为什么？因为门锁平时就是待机，只有用户开锁、上报电量、触发报警时才需要发数据。发完数据，服务器如果有指令（比如远程开锁），就在那两个接收窗口里下发。没有指令，门锁继续睡大觉。

你可能会问：那远程开锁怎么办？服务器怎么主动下发指令？

其实很简单：服务器先发一条“下行通知”到网关，网关缓存这条指令。等门锁下次主动上报数据时，网关在接收窗口里把指令塞过去。这就是所谓的“下行随上行”机制。我刚开始做的时候也纠结过这个问题，后来发现LoRaWAN的设计哲学就是“终端主动，服务器被动”，想通了就豁然开朗。

避坑指南：我曾经在一个项目中，为了追求“实时远程开锁”，强行把门锁设成了Class C模式。结果呢？电池一周就耗光了。后来改成Class A，配合服务器缓存+轮询机制，延迟控制在2秒以内，电池撑了两年。所以，别为了那点实时性牺牲续航。

LoRaWAN的MAC层帧结构，说白了就是给数据包穿衣服。从里到外分三层：

这里有个细节：帧计数器（FCnt）。每个终端维护一个上行计数器，服务器维护一个下行计数器。如果计数器不匹配，服务器会丢弃数据包。我遇到过有人把门锁的计数器清零了，结果服务器死活不认，排查了半天才发现是计数器重置的问题。

来看一个典型的MAC帧结构（简化版）：

| 前导码 | PHDR | PHDR_CRC | 帧头(MHDR) | 设备地址(DevAddr) | 帧控制(FCtrl) | 帧计数器(FCnt) | 帧选项(FOpts) | 帧端口(FPort) | 帧负载(FRMPayload) | MIC |

嗯，看着有点复杂对吧？其实你只需要记住：帧头占13字节，负载最多51字节（DR0时）。所以，你的业务数据一定要精简。我习惯把开锁指令压缩到4字节以内，电量值用1字节表示百分比。

门锁要上网，得先“注册”。LoRaWAN提供了两种入网方式：

这是推荐方式。流程如下：

好处是密钥动态生成，安全性高。坏处是每次入网需要多一次握手，多耗一点电。但说实话，门锁入网通常只在初次安装或断网重连时发生，这点功耗可以忽略。

这种方式是出厂时就把DevAddr、NwkSKey、AppSKey烧录到门锁里。门锁上电直接发数据，不需要入网流程。

好处是快，省电。坏处是密钥固定，如果泄露，所有门锁都得返厂。我个人的建议是：量产项目用OTAA，原型验证可以用ABP图省事。

  我的经验：曾经有个客户，为了省那0.5秒的入网时间，坚持用ABP。结果呢？有一批门锁的密钥被误烧录成一样的，导致服务器无法区分设备，所有门锁都失控了。后来全部返厂重刷，损失惨重。所以，别在安全上省钱。

不管是OTAA还是ABP，有几个参数你必须要搞清楚：

这里要注意：NwkSKey和AppSKey是分开的。网络层只负责传输，不关心数据内容。应用层只关心数据，不参与网络管理。这种分离设计，说白了就是“各司其职”，安全性更高。

好了，关于LoRaWAN协议栈的核心内容，咱们就聊到这儿。下一章我会讲怎么在门锁上实际配置这些参数，以及如何用代码实现OTAA入网。到时候咱们再细聊。