2、LoRaWAN协议栈：物理层、MAC层、应用层、LoRaWAN帧结构、数据速率与扩频因子
好，咱们正式开始聊LoRaWAN协议栈。
说实话，很多初学者一上来就被「物理层、MAC层、应用层」这些词给唬住了。其实没那么玄乎。我当年刚接触LoRaWAN时，也花了不少时间才把这些层之间的关系理清楚。今天我就用我自己的理解，帮你把这层窗户纸捅破。
2.1 物理层：LoRa的看家本领
物理层，说白了就是「怎么把0和1变成无线电波发出去」。LoRa的物理层用的是Chirp Spread Spectrum（CSS）技术，也就是线性调频扩频。
你想想看，传统的FSK调制，信号窄窄的一条，很容易被干扰。LoRa呢？它把信号展得很宽，像撒网一样。干扰来了？没关系，我能量分散得广，你干扰不掉我全部。
扩频因子（Spreading Factor, SF） 就是控制这个「网」撒多宽的关键参数。
核心概念：扩频因子SF决定了每个数据位用多少个「啁啾（chirp）」来表示。SF越高，每个bit用的chirp越多，抗干扰能力越强，但传输速度越慢。
LoRaWAN常用的扩频因子是SF7到SF12。我给大家列个表，一目了然：
| 扩频因子 | 每个bit的chirp数 | 灵敏度（约） | 典型速率（125kHz带宽） |
|---|---|---|---|
| SF7 | 128 | -123 dBm | 5.47 kbps |
| SF8 | 256 | -126 dBm | 3.13 kbps |
| SF9 | 512 | -129 dBm | 1.76 kbps |
| SF10 | 1024 | -132 dBm | 0.98 kbps |
| SF11 | 2048 | -135 dBm | 0.54 kbps |
| SF12 | 4096 | -138 dBm | 0.29 kbps |
我的经验：我在一个地下停车场项目里，终端设备埋得比较深，SF12都差点扛不住。后来调整了天线位置，才勉强用SF11跑通。所以别迷信SF12，它虽然灵敏度高，但速率实在太慢了，一个包发出去要等半天。
2.2 MAC层：谁先说话，谁后说话
MAC层解决的是「多设备怎么共用同一个信道」的问题。LoRaWAN的MAC层用的是纯ALOHA协议，简单粗暴——想发就发，撞了重来。
为什么会这样？因为LoRa终端大部分是电池供电的，要省电。如果搞个复杂的CSMA/CA（先监听再发送），终端得一直开着接收机，功耗就上去了。
MAC层还负责一件事：确认与重传。终端发完数据后，可以要求网关回复一个ACK。如果没收到ACK，终端就认为丢包了，会在下一个窗口重传。
注意：ACK不是免费的。每发一个ACK，网关就要占用一个接收窗口。如果网络里设备太多，ACK反而会加剧冲突。我建议在非关键数据场景下，尽量不用ACK，靠应用层去补偿丢包。
2.3 应用层：你只管发数据，剩下的交给协议
应用层在LoRaWAN里其实挺「薄」的。它主要定义了数据怎么打包、怎么加密、怎么解析。
LoRaWAN的应用层有两个端口：
- FPort 0：用于MAC命令，比如终端告诉网关「我要换频点」。
- FPort 1-223：用于用户自定义的应用数据。
我个人习惯把FPort 1留给传感器数据，FPort 2留给配置命令。这样解析起来方便，不容易搞混。
2.4 LoRaWAN帧结构：拆开看看里面长啥样
一个LoRaWAN数据帧，从外到内是这样的：
+----------------+----------------+----------------+----------------+
| Preamble | PHDR | PHDR_CRC | PHYPayload |
+----------------+----------------+----------------+----------------+
Preamble是前导码，用来让接收机同步时钟。PHDR是物理层头部，PHDR_CRC是头部的校验。真正有用的数据在PHYPayload里。
PHYPayload又拆成：
+----------------+----------------+----------------+
| MHDR | MACPayload | MIC |
+----------------+----------------+----------------+
- MHDR：1个字节，告诉接收方这是上行还是下行，用的是哪个版本。
- MACPayload：核心数据区，包含帧头、端口、应用数据。
- MIC：4个字节的消息完整性校验码，用来防篡改。
避坑指南：我曾经在调试时发现终端发出去的数据网关收不到，查了半天，结果是MIC计算错了。LoRaWAN的MIC计算要用到NwkSKey和AppSKey，这两个密钥一旦配错，整个帧就会被网关丢弃。所以，密钥配置一定要仔细核对。
2.5 数据速率与扩频因子的关系
数据速率（Data Rate, DR）和扩频因子（SF）是绑定的。LoRaWAN标准里定义了DR0到DR7：
| DR | 配置 | 速率（约） | 典型场景 |
|---|---|---|---|
| DR0 | SF12 / 125 kHz | 0.29 kbps | 深覆盖、远距离 |
| DR1 | SF11 / 125 kHz | 0.54 kbps | 一般远距离 |
| DR2 | SF10 / 125 kHz | 0.98 kbps | 中等距离 |
| DR3 | SF9 / 125 kHz | 1.76 kbps | 城市环境 |
| DR4 | SF8 / 125 kHz | 3.13 kbps | 近距、高数据量 |
| DR5 | SF7 / 125 kHz | 5.47 kbps | 最近距、最高速 |
| DR6 | SF7 / 250 kHz | 11.0 kbps | 特殊场景（如欧洲） |
| DR7 | FSK | 50.0 kbps | 极近距、高速 |
你想想看，DR0和DR5差了将近20倍的速度。但DR0能覆盖的距离，DR5可能连一半都到不了。这就是「鱼和熊掌不可兼得」。
我的建议：在实际项目中，别一上来就用DR0。先试试DR3，如果信号不好再降。我见过太多人为了「保险」直接上SF12，结果一个数据包要发2秒多，电池很快就没电了。
2.6 自适应数据速率（ADR）的底层逻辑
ADR就是让网络侧（网络服务器）根据终端上报的信噪比（SNR）和接收信号强度（RSSI），自动帮终端选择一个最合适的DR。
逻辑很简单：
- 终端上报链路质量（SNR、RSSI）。
- 网络服务器计算「链路余量」——也就是信号比最低要求强多少。
- 如果余量足够，就提高DR（降低SF），让终端发得更快、更省电。
- 如果余量不足，就降低DR（提高SF），保证数据能到达。
嗯，这里要注意：ADR只适用于静态或准静态终端。如果你的终端是移动的（比如装在车上），ADR反而会帮倒忙——信号忽好忽坏，ADR跟不上变化。
我曾经踩过的坑：在一个农业项目中，传感器装在拖拉机上，结果ADR一直在DR0和DR5之间来回跳，导致大量丢包。后来我干脆把ADR关了，固定用DR2，反而稳定多了。所以，移动场景慎用ADR。
好了，这一章的内容就到这儿。下一章咱们会深入聊ADR的具体算法和参数配置，到时候我会拿实际项目里的数据给大家演示。