2、LoRaWAN协议基础：网络架构、设备类型与数据包结构
各位同学，咱们今天聊聊LoRaWAN协议的基础。说实话，很多做MQTT安全的工程师，一上来就盯着应用层加密，却忽略了底层链路的特点。我个人习惯是，先搞清楚数据在物理上是怎么跑的，再谈安全策略。LoRaWAN就是这样一条“路”，你得先认识路，才知道在哪设卡。
2.1 LoRaWAN网络架构：星形拓扑的秘密
LoRaWAN用的是星形拓扑，不是Mesh。你想想看，终端设备直接跟网关通信，网关再通过标准IP网络连到网络服务器。为什么这么设计？说白了，就是为了省电。
我在项目中遇到过不少团队，一开始想用Mesh组网，觉得覆盖范围大。结果一算功耗，终端电池根本撑不住。LoRaWAN的星形结构，让终端只管发数据，不用当中继，这才是低功耗的关键。
核心架构组件：
- 终端节点（End Device）：传感器、执行器，负责采集或控制。
- 网关（Gateway）：透明桥接，只负责转发RF数据到网络服务器，不做解密。
- 网络服务器（Network Server）：核心大脑，负责数据去重、解密、速率自适应（ADR）、MAC命令处理。
- 应用服务器（Application Server）：处理业务数据，持有应用会话密钥（AppSKey）。
这里有个容易踩的坑——网关不参与解密。我曾经见过有人把网关当成“边缘计算节点”，想在上面做数据解析。结果发现LoRaWAN的加密是在终端和网络服务器之间端到端的，网关根本拿不到密钥。嗯，这一点对后续MQTT安全设计特别重要，因为MQTT Broker通常部署在应用服务器侧，密钥隔离要做好。
2.2 设备类型：Class A/B/C 的取舍
LoRaWAN定义了三种设备类型，核心区别在于“什么时候能收数据”。我刚开始学的时候也觉得复杂，其实你只要记住一句话：Class A是底线，所有设备都必须支持。
| 特性 | Class A | Class B | Class C |
|---|---|---|---|
| 上行后接收窗口 | 2个（RX1/RX2） | 2个 + 定期开窗 | 几乎一直开 |
| 下行延迟 | 高（依赖上行触发） | 中（有调度时隙） | 低（随时可收） |
| 功耗 | 最低（电池可用数年） | 中等（需同步信标） | 最高（持续监听） |
| 典型场景 | 传感器上报 | 阀门控制、定时采集 | 执行器、固件升级 |
Class A：终端发完数据后，打开两个接收窗口。窗口时间很短，错过就没了。我建议做电池供电的传感器，优先选Class A。曾经有个项目，客户非要Class C，结果电池一个月就废了。
Class B：在Class A基础上，增加了定期接收时隙。网关会广播信标（Beacon），终端同步后按计划开窗。适合需要定时下行的场景，比如每天凌晨同步一次配置。
Class C：除了发送时，接收窗口几乎一直开着。功耗最大，但下行延迟最低。我在做智能路灯控制时用过Class C，因为需要实时响应开关指令。注意，Class C设备通常需要外接电源。
我的经验： 如果你在做MQTT到LoRaWAN的桥接，一定要考虑设备类型对下行延迟的影响。Class A设备的下行消息，必须等它下次上行才能送达。MQTT Broker那边如果发了一条“紧急关闭阀门”的消息，结果设备两小时才上报一次……嗯，后果你懂的。
2.3 数据包结构：从PHY到MAC
LoRaWAN的数据包，从物理层到MAC层，层层封装。我习惯从下往上拆解，这样更容易理解加密覆盖的范围。
2.3.1 物理层（PHY）
LoRa的物理层数据包很简单：
Preamble（前导码） + PHDR（物理头） + PHDR_CRC + PHYPayload + CRC前导码用于接收机同步，PHDR包含编码率等信息。注意，PHDR_CRC只保护物理头，不保护数据。这一点在干扰环境下容易丢包，我踩过坑。
2.3.2 MAC层数据包
PHYPayload里面就是MAC层的内容：
MACHeader（MHDR） + MACPayload + MIC（消息完整性校验）- MHDR（1字节）：包含消息类型（Confirmed/Unconfirmed）、版本号、是否带MAC命令。
- MACPayload：包含帧头（FHDR）、端口（FPort）、帧负载（FRMPayload）。
- MIC（4字节）：用NwkSKey或AppKey计算，防止篡改。
2.3.3 帧头（FHDR）结构
DevAddr（4字节） + FCtrl（1字节） + FCnt（2字节） + FOpts（0-15字节）- DevAddr：设备短地址，类似IP地址，但会变（因为Join过程会重新分配）。
- FCtrl：控制位，包含ACK、ADR、Class B标志等。
- FCnt：帧计数器，防重放攻击的关键。我曾经见过有人把FCnt重置导致重放漏洞，切记FCnt只能递增。
- FOpts：内联MAC命令，不加密，但受MIC保护。
2.3.4 加密与完整性保护
LoRaWAN的加密分两层：
- 网络层加密（NwkSKey）：保护MAC命令和MIC计算。
- 应用层加密（AppSKey）：保护FRMPayload，即真正的业务数据。
注意，FOpts（MAC命令）只受MIC保护，不加密。这意味着网络服务器能看到MAC命令，但应用服务器看不到。反过来，应用服务器能解密FRMPayload，但网络服务器不能。这种密钥隔离，对MQTT安全设计很有启发——Broker和Backend之间也要做类似的权限分离。
避坑指南： 我曾经在调试时发现，某些LoRaWAN模块在FCnt溢出后会自动回绕到0。如果网络服务器没做防回绕检查，攻击者可以重放旧数据包。解决方案是使用32位扩展帧计数器（FCnt32），或者在网络服务器侧做FCnt单调性校验。
2.4 一张图看懂LoRaWAN协议栈
下面这张图，我画了LoRaWAN从物理层到应用层的完整数据流。你可以看到加密发生在哪一层，MQTT消息最终会落在FRMPayload里。
从这张图你可以看到，MQTT消息如果通过LoRaWAN传输，会先被AppSKey加密，然后封装进FRMPayload。网络服务器只能看到设备地址和帧计数器，看不到具体内容。这种设计，说白了就是“最小权限原则”的体现——谁需要谁拿密钥。
2.5 小结
这一章我们聊了LoRaWAN的星形架构、三种设备类型的取舍，以及数据包从物理层到MAC层的封装细节。我个人觉得，理解这些基础对后续MQTT安全设计至关重要。比如，Class A设备的下行延迟决定了MQTT Broker不能依赖即时响应；密钥隔离机制则提醒我们，在MQTT Broker和LoRaWAN应用服务器之间，也要做好权限分离。