3. LoRaWAN协议栈：物理层、MAC层、应用层架构，Class A/B/C设备类型详解
聊到LoRaWAN协议栈，我脑子里第一个蹦出来的词就是「分层」。说白了，这玩意儿跟咱们平时用的TCP/IP一样，也是把通信这件事拆成了几层来搞。每一层各司其职，互不干扰。我在项目里见过不少新手，一上来就扎进代码里调参数，结果连数据到底卡在哪一层都搞不清楚——嗯，这其实挺要命的。
3.1 物理层：LoRa调制技术的核心
物理层是LoRaWAN的根基。它负责把数字信号变成无线电波发出去。LoRa用的是扩频调制技术，跟传统的FSK、GMSK不太一样。
我个人习惯把物理层的参数比作「三驾马车」：
- 扩频因子（SF）：SF7到SF12，数值越大，传输距离越远，但速率越慢。我在项目中遇到过，SF12虽然能传十几公里，但一个包要发将近1秒，电池扛不住。
- 带宽（BW）：常见125kHz、250kHz、500kHz。带宽越大，速率越快，但灵敏度会下降。
- 编码率（CR）：4/5到4/8，说白了就是冗余度。干扰大的地方用高编码率，代价是有效数据变少。
核心要点：物理层决定了你能传多远、多快、多抗干扰。这三个参数是互相牵制的，调一个就得看另外两个的脸色。
你想想看，为什么LoRa能比WiFi传得远那么多？就是因为扩频技术把信号能量分散到更宽的频带上，接收端再用同样的扩频码去「拼」回来。这就像你在嘈杂的酒吧里喊话，如果喊的内容有规律重复，对方反而能听清——LoRa就是这么干的。
3.2 MAC层：信道接入与通信规则
MAC层是LoRaWAN的大脑。它管着设备什么时候发、怎么发、发完怎么收。这里有个关键概念——纯ALOHA协议。
说白了就是「想发就发，撞了重来」。听起来很粗暴对吧？但LoRaWAN之所以敢这么干，是因为物理层本身就有很强的抗干扰能力。两个设备同时发，只要信号强度差不太多，网关还是能解出来。
MAC层还负责三件大事：
- 入网激活：OTAA（空中激活）和ABP（个性化激活）。我建议生产环境用OTAA，因为安全性更高。曾经有个客户图省事全用ABP，结果设备换了个网关就得重新烧录密钥——那叫一个酸爽。
- 确认与重传：MAC层支持确认帧（ACK）。如果设备发了数据没收到ACK，会在指定窗口重传。注意，重传次数别设太多，否则电池死得快。
- 自适应数据速率（ADR）：网关会根据信号质量，自动建议设备调整速率。离得近就用SF7，离得远就用SF12。这个功能我强烈建议开启，能省不少电。
实战技巧：ADR不是万能的。如果你的设备在移动（比如车载），建议关闭ADR，手动固定一个SF值。否则网关刚建议你用SF7，你跑远了信号变差，数据就丢了。
3.3 应用层：数据格式与安全加密
应用层是离开发者最近的一层。它定义了数据怎么打包、怎么加密、怎么解析。
LoRaWAN的应用层数据帧结构很简单：
| 帧头（MHDR） | 帧载荷（FRMPayload） | 消息完整性校验（MIC） |
| 1字节 | 1~250字节 | 4字节 |帧载荷里装的就是你的业务数据。比如温度传感器上报的25.3℃，或者门磁开关的状态。但注意，这些数据是加密的——LoRaWAN使用AES-128加密，密钥在入网时协商好。
我记得有一次帮客户排查问题，发现数据到了服务器全是乱码。查了半天，原来是应用层的加密密钥和网络层的搞混了。嗯，这种低级错误其实挺常见的，大家写代码时一定要把AppSKey（应用会话密钥）和NwkSKey（网络会话密钥）分清楚。
3.4 Class A/B/C设备类型详解
LoRaWAN定义了三种设备类型，分别对应不同的功耗和延迟需求。我直接说人话：
| 类型 | 接收窗口 | 功耗 | 典型场景 |
|---|---|---|---|
| Class A | 上行后打开两个接收窗口 | 最低 | 传感器、水表、烟感 |
| Class B | 定时打开接收窗口 | 中等 | 阀门控制、定时上报 |
| Class C | 持续打开接收窗口 | 最高 | 执行器、路灯、实时控制 |
Class A：最省电，但最被动
Class A是所有LoRaWAN设备都必须支持的基础类型。它的逻辑很简单：设备主动发一个上行数据，然后打开两个短暂的接收窗口（RX1和RX2），等服务器回复。窗口关了就彻底睡了，直到下次上行。
为什么会这样设计？因为物联网设备大部分时间都在「睡觉」，只有上报数据时才醒一下。Class A的功耗可以做到微安级别，一节电池用三五年不是梦。
注意：Class A设备无法随时接收下行数据。服务器想下发指令，必须等设备主动上报。如果你需要远程控制设备开关，Class A可能不太合适——除非你允许设备频繁上报。
Class B：定时「醒」一下
Class B在Class A的基础上，增加了一个定时接收窗口。设备会同步网关发出的信标（Beacon），然后在约定的时间点打开接收窗口。
说白了，Class B就是「我每隔一段时间主动听一听，看看有没有人找我」。这样服务器不需要等设备上报，也能在固定时间点下发指令。
我在项目中用过Class B做灌溉控制。设备每10分钟打开一次接收窗口，服务器在这期间下发阀门开关指令。功耗比Class A高一些，但比Class C低得多。
Class C：随时待命
Class C是「永远在线」的类型。设备除了发送数据的时候，其他时间接收窗口一直开着。服务器随时可以下发指令，延迟最低。
但代价也很明显——功耗高。Class C设备通常需要市电供电，或者用大容量电池+太阳能板。我曾经给一个路灯项目选型，客户非要Class C，结果电池三天就没电了。后来换成Class B，配合光敏传感器，才把续航拉到半年。
选型建议：
- 电池供电、不常交互 → Class A
- 电池供电、需要定时控制 → Class B
- 市电供电、需要实时控制 → Class C
3.5 协议栈整体架构图
下面这张图是我自己画的，把LoRaWAN协议栈的三层结构和设备类型串在了一起。你看完应该能有个全局印象。
从这张图你能看出来，物理层在最底下，负责「怎么传」；MAC层在中间，负责「什么时候传」；应用层在最上面，负责「传什么」。设备类型则是横跨MAC层和物理层的属性，决定了接收窗口的行为。
我的经验：刚开始学LoRaWAN时，别急着看代码。先把这三层的关系理清楚，再去看Semtech的官方文档，你会发现豁然开朗。我曾经带过一个团队，大家花了一周时间死磕物理层参数，结果MAC层的入网流程没搞懂，设备死活连不上网关——方向错了，努力白费。
好了，这一章的内容就到这儿。协议栈的架构搞明白了，后面咱们聊网关搭建和网络配置时，你就能知道每一步是在操作哪一层了。