3. LoRaWAN协议架构：网络拓扑、终端类型与MAC层帧结构
各位同学，咱们今天来聊聊LoRaWAN协议的核心架构。说实话，很多初学者一上来就被各种术语搞晕了——什么Class A、Class B、MAC层帧头……其实没那么复杂。我当年第一次接触LoRaWAN时，也是对着协议栈文档发了好几天呆。后来在项目中亲手搭了一套网络，才真正搞明白这些设计背后的逻辑。
咱们今天就把这三块内容拆开揉碎了讲：网络拓扑长什么样？终端设备分哪几类？MAC层的帧结构又是怎么组织的？
3.1 LoRaWAN网络拓扑
LoRaWAN用的是星型拓扑，不是Mesh网。这一点我特别想强调——终端设备不直接互相通信，所有数据都通过网关转发到网络服务器。
你想想看，为什么这么设计？
说白了，就是为了省电。终端设备只需要跟网关打交道，不需要监听其他节点的消息，也不用做路由转发。我在一个智慧农业项目里，传感器节点用两节AA电池，Class A模式，跑了两年多没换过电池。要是用Mesh，早就没电了。
典型的LoRaWAN网络包含四个角色：
- 终端设备（End Device）：传感器、执行器等，负责采集数据或接收指令
- 网关（Gateway）：也叫集中器，负责转发终端和服务器之间的数据包
- 网络服务器（Network Server）：核心大脑，处理MAC层逻辑、去重、确认等
- 应用服务器（Application Server）：处理业务数据，比如温湿度告警、设备控制
这里有个容易踩的坑——网关本身不解析数据内容。它只做物理层转发，把收到的LoRa射频信号转成IP包发给服务器。我曾经遇到一个客户，非要在网关上做数据解析，结果网关负载过高，丢包率飙升。嗯，后来改回标准架构，问题就解决了。
核心要点：LoRaWAN是星型拓扑，终端→网关→网络服务器→应用服务器，数据流是单向或双向的，但终端永远不直接跟其他终端通信。
下面这张图是我自己画的，把整个网络拓扑和消息流向展示清楚了：
3.2 终端设备类型：Class A / B / C
LoRaWAN定义了三种终端类型，核心区别在于下行接收窗口的时机和功耗。我直接说结论：Class A最省电，Class C最费电，Class B是折中方案。
Class A —— 最省电，最常用
Class A是所有LoRaWAN终端必须支持的模式。它的逻辑很简单：终端主动发上行数据，发完之后打开两个接收窗口，等服务器回复。
具体流程是这样的：
- 终端发送上行数据包
- 发送结束后1秒，打开第一个接收窗口（RX1），持续约100ms
- 如果RX1没收到数据，再等1秒，打开第二个接收窗口（RX2）
- 两个窗口都关闭后，终端进入休眠状态
我在一个环境监测项目里，传感器每15分钟上报一次温度数据，Class A模式，两节AA电池用了两年半。为什么这么省电？因为终端99%的时间都在睡觉，只有上报那几毫秒才工作。
我的建议：如果你的应用是传感器周期性上报数据，且下行指令不频繁，优先选Class A。这是LoRaWAN的默认模式，兼容性最好。
Class B —— 定时接收下行
Class B在Class A的基础上，增加了定时接收窗口。终端会从网关接收一个同步信标（Beacon），然后按照约定的时间周期性地打开接收窗口。
说白了，Class B就是「我虽然大部分时间在睡觉，但我定了闹钟，到点就醒过来听听有没有消息」。
Class B的典型应用场景：
- 需要服务器主动下发指令，但终端不能一直开着接收
- 比如智能路灯控制，服务器可能在任意时间下发调光指令
不过Class B有个麻烦——终端需要跟网关保持时间同步。我有个同事在做智能停车项目时，Class B终端在信号不好的地下车库经常收不到Beacon，导致同步失败，最后不得不降级成Class A。嗯，这个坑大家要注意。
Class C —— 实时监听，最费电
Class C的终端几乎一直在监听下行数据。除了发送数据那几毫秒，其他时间接收窗口都是打开的。
你想想看，这意味什么？功耗最高，但延迟最低。服务器随时可以下发指令，终端几乎立即响应。
Class C适合的场景：
- 需要实时控制的执行器，比如阀门、开关
- 有市电供电的设备，不担心功耗
注意：Class C终端如果使用电池供电，可能几天就没电了。我曾经见过一个项目，客户把Class C用在电池供电的传感器上，结果一周换一次电池，运维成本直接爆炸。所以，选Class C之前，先确认供电方式。
三种类型的对比，我整理了一张表：
| 特性 | Class A | Class B | Class C |
|---|---|---|---|
| 下行接收时机 | 上行后两个窗口 | 上行后 + 定时窗口 | 几乎一直监听 |
| 功耗 | 极低 | 中等 | 高 |
| 下行延迟 | 取决于上行周期 | 取决于Beacon周期 | 极低 |
| 典型应用 | 传感器上报 | 定时控制 | 实时控制 |
| 供电要求 | 电池可用数年 | 电池可用数月 | 市电或大容量电池 |
3.3 MAC层帧结构
MAC层帧结构，说白了就是数据包的组织格式。LoRaWAN的MAC帧分为上行帧和下行帧，结构基本一致，但有些字段含义不同。
标准的MAC帧结构如下：
+----------------+----------------+----------------+----------------+----------------+
| MAC Header | MAC Payload | MIC |
| (MHDR) | (FRM_Payload) | (消息完整性码) |
| 1 byte | 1..N bytes | 4 bytes |
+----------------+----------------+----------------+----------------+----------------+咱们拆开来看每个部分：
3.3.1 MAC Header (MHDR)
MHDR只有1个字节，但信息量不小。它包含：
- MType (3 bits)：消息类型，比如Join Request、Unconfirmed Data Up、Confirmed Data Down等
- RFU (3 bits)：保留位，目前必须为0
- Major (2 bits)：LoRaWAN版本号，目前是0x00
我刚开始看协议时，总觉得1个字节能存什么？后来发现，MType决定了整个帧的处理方式。比如Confirmed Data Up要求服务器必须回复ACK，而Unconfirmed Data Up则不需要。这个区别在项目中很重要——确认帧会增加网络负载，但能保证数据可靠到达。
3.3.2 MAC Payload
MAC Payload是帧的核心，它又分为两部分：
+----------------+----------------+----------------+----------------+
| FHDR | FPort | FRM_Payload |
| (帧头) | (端口号) | (应用数据) |
| 7..22 bytes | 1 byte | 0..N bytes |
+----------------+----------------+----------------+----------------+FHDR（帧头）包含：
- DevAddr（4字节）：终端设备地址
- FCtrl（1字节）：流控标志，比如ACK、ADR等
- FCnt（2字节）：帧计数器，防止重放攻击
- FOpts（0~15字节）：可选MAC命令，比如LinkCheckReq
FPort（端口号）：
- 0：用于MAC命令传输
- 1~223：应用数据端口
- 224~255：保留给未来使用
FRM_Payload（应用数据）：
- 最大长度取决于数据速率（DR）
- 数据速率越低，传输距离越远，但Payload越小
- 比如DR0（SF12）下，最大Payload只有51字节
重要提醒：LoRaWAN的Payload长度受限于数据速率。我在一个项目中，为了追求传输距离用了SF12，结果发现一个数据包只能传51字节，传感器数据稍微多一点就得拆包。后来调整了SF和Payload的平衡，才解决问题。
3.3.3 MIC（消息完整性码）
MIC是4字节的校验码，用于验证消息的完整性和真实性。它使用AES-CMAC算法计算，密钥是终端和网络服务器共享的AppKey或NwkKey。
简单说，MIC就是数据包的「防伪标签」。如果接收方计算的MIC跟发送方的不一致，说明数据被篡改或者不是合法设备发的，直接丢弃。
我遇到过一种情况：终端固件升级后，MIC计算逻辑出了bug，导致所有上行数据都被服务器丢弃。排查了两天才发现是密钥配置错了。所以，MIC相关的代码一定要仔细测试。
3.4 小结
好了，这一章的内容就这些。咱们回顾一下：
- 网络拓扑：星型结构，终端→网关→服务器，简单可靠
- 终端类型：Class A最省电，Class B定时监听，Class C实时响应
- MAC帧结构：MHDR + Payload + MIC，每个字段都有明确用途
这些是LoRaWAN协议的基础，也是后续章节的基石。我个人建议，如果你刚开始做LoRaWAN开发，先拿Class A设备跑通一个简单的数据上报流程，把MAC帧抓出来看看，理解每个字节的含义。纸上得来终觉浅，绝知此事要躬行嘛。
公众号:蓝海资料掘金营，微信deep3321