1. LoRaWAN概述：协议栈架构、网络拓扑、设备角色与类
各位同学好，我是老张。做LoRaWAN这行快十年了，踩过的坑比走过的路还多。今天咱们聊聊LoRaWAN的基础框架——协议栈架构、网络拓扑、设备角色和类。这些东西看着简单，但我在项目里见过太多人因为基础没打牢，后面调试到崩溃。
1.1 协议栈架构：从物理层到应用层
LoRaWAN的协议栈，说白了就是四层结构。我习惯把它想象成一栋楼：
- 物理层（PHY）：LoRa射频调制，负责发0和1
- MAC层：信道访问、重传、确认，核心中的核心
- 应用层：数据封装、加密、端口管理
嗯，这里要注意。很多人以为LoRaWAN就是LoRa，其实不是。LoRa是物理层的调制技术，LoRaWAN是上层的协议。我见过一个团队，硬件选型时只看了LoRa芯片参数，没考虑协议栈兼容性，结果网关对接时出了大问题。
关键点：LoRaWAN协议栈中，MAC层负责所有重传和确认逻辑。应用层只管数据，不管传输可靠性。
1.2 网络拓扑：星型结构为什么是主流？
LoRaWAN用的是星型拓扑。终端设备直接连网关，网关再连网络服务器。为什么不搞Mesh？
我刚开始也纳闷。后来在做一个智慧农业项目时想通了——终端设备大多靠电池供电，Mesh网络里每个节点都要转发数据，功耗根本扛不住。星型拓扑下，终端只管发，网关负责收，省电又简单。
你想想看，一个传感器在田里待三年，中间还要帮别人传数据，电池早废了。
我的经验：星型拓扑虽然简单，但网关覆盖范围要留余量。我曾经在工业园区部署，以为覆盖半径5公里够了，结果厂房密集区信号衰减严重，最后加了两个中继网关才搞定。
1.3 设备角色：终端、网关、网络服务器
LoRaWAN网络里主要有三个角色：
| 角色 | 功能 | 我踩过的坑 |
|---|---|---|
| 终端设备 | 采集数据、发送上行帧 | 记得有一次终端发送间隔设得太短，导致网关拥塞 |
| 网关 | 转发数据包，不做解析 | 网关的时钟漂移问题，让我排查了三天 |
| 网络服务器 | 去重、解密、确认、调度 | 服务器端去重逻辑没写好，重复帧满天飞 |
这里有个容易忽略的点：网关只做物理层转发，不解析MAC层数据。所以重传和确认的逻辑，全在终端和网络服务器之间完成。网关就是个传话筒。
1.4 设备类：Class A、B、C的区别
LoRaWAN定义了三种设备类，我建议你记住一个原则：功耗越低，下行越被动。
Class A：最省电，最常用
终端发完上行数据后，开两个短暂的接收窗口（RX1和RX2）。窗口一关，就收不到下行数据了。说白了就是「发完就睡，醒了再说」。
我在智能水表项目里全用的Class A。水表一天发一次数据，电池用五年没问题。但如果你想远程控制阀门开关，Class A就不太行了——你得等它下次上报才能下发指令。
Class B：定时接收，折中方案
Class B在Class A基础上增加了定时接收窗口。终端会同步网关的信标，在指定时间打开接收窗口。功耗比Class A高一些，但下行延迟可控。
我曾经在路灯控制项目里试过Class B。效果不错，但信标同步是个麻烦事。网关时钟漂移、终端晶振不准，都会导致窗口错位。调试那段时间，我几乎住在现场。
Class C：随时接收，功耗最高
Class C的终端几乎一直开着接收窗口，只有发送数据时才短暂关闭。下行延迟最低，但功耗也最高。适合有市电供电的设备。
避坑指南：我曾经在一个项目里把Class C用在电池供电设备上，结果电池撑了不到一个月。后来才意识到，Class C的接收电流虽然只有十几毫安，但24小时开着，电池根本扛不住。
1.5 小结：选类就是选策略
好了，总结一下：
- 协议栈：四层结构，MAC层管重传确认
- 拓扑：星型，简单省电
- 角色：终端、网关、服务器各司其职
- 设备类：Class A省电但被动，Class B折中，Class C实时但费电
我个人习惯是：能用Class A绝不用Class B，除非业务要求下行实时性。毕竟电池寿命是物联网产品的命门。
下一章咱们深入聊聊数据包重传机制。嗯，那才是真正烧脑的地方。