第2章：LoRaWAN协议栈：物理层、MAC层、应用层分层架构、各层职责与交互流程
说实话，很多刚接触LoRaWAN的朋友，一上来就被「物理层」、「MAC层」、「应用层」这些词给唬住了。其实没那么玄乎。我当年第一次看LoRaWAN协议栈时，脑子里就一个想法：这不就是一套「谁负责发、谁负责管、谁负责用」的分工体系吗？
嗯，今天我就带你一层层拆开来看。咱们不搞教科书式的罗列，而是从实际工程的角度，聊聊每一层到底在干什么。
2.1 物理层：最底层的「搬运工」
物理层，说白了就是负责把数据变成无线电波发出去，再把收到的无线电波变回数据。它不关心你发的是什么内容，只关心「能不能发出去」、「能不能收回来」。
LoRaWAN的物理层用的是Semtech公司的LoRa调制技术。这是一种扩频调制，好处是灵敏度极高——我实测过，在市区环境下，-130dBm的信号都能解调出来。你想想看，这相当于什么呢？相当于你在北京，能听到上海一根针掉在地上的声音。
物理层核心参数：
- 频段：EU868（欧洲）、US915（北美）、CN470（中国）等
- 扩频因子（SF）：SF7~SF12，数值越大，传输距离越远，但速率越慢
- 带宽（BW）：通常125kHz、250kHz、500kHz
- 编码率（CR）：4/5 ~ 4/8，用于前向纠错
我在一个智慧农业项目里就吃过亏。当时为了追求最远距离，把扩频因子设成了SF12。结果呢？数据包是能传3公里了，但一个包要传将近2秒。网关那边收包超时，直接丢包。后来我改成SF9，距离虽然短了点，但系统稳定多了。
我的经验：别盲目追求SF12。除非你的节点真的在深山老林里，否则SF9~SF10足够用了。速率和距离，永远是个trade-off。
2.2 MAC层：通信的「交通警察」
物理层把路修好了，但车怎么开、谁先走、撞车了怎么办？这些事归MAC层管。
LoRaWAN的MAC层定义了节点和网关之间的通信规则。它主要干这几件事：
- 信道接入：节点什么时候可以发数据？用ALOHA协议，想发就发，撞了重传。
- 数据确认：发出去的包，网关收到没？没收到就重发。
- 自适应数据速率（ADR）：根据信号质量，自动调整速率和发射功率。
- 安全加密：用AES-128对数据进行加密，防止被窃听。
这里有个关键点：LoRaWAN的MAC层是「星型拓扑」的。节点只和网关通信，节点之间不直接通信。你想想看，如果每个节点都去跟其他节点握手，那信道早就挤爆了。
注意：LoRaWAN的MAC层不支持节点之间的直接通信。如果你需要做点对点传输，得用LoRa的私有协议，而不是LoRaWAN。
我记得有一次做城市井盖监测项目，井盖都在地下，信号很差。节点发数据到网关，经常收不到ACK。我一开始以为是物理层的问题，后来抓包分析才发现，是MAC层的重传机制没配置好。默认重传次数是3次，但地下环境干扰大，我改成了5次，问题就解决了。
2.3 应用层：数据的「翻译官」
物理层负责收发，MAC层负责管理，那应用层呢？它负责把收到的二进制数据，翻译成业务能理解的信息。
比如，一个温度传感器发来一串字节：0x01 0x2A。应用层知道：第一个字节是传感器ID，第二个字节是温度值（0x2A = 42°C）。然后它把这个数据交给服务器，服务器再显示到仪表盘上。
LoRaWAN的应用层其实很薄。它主要定义了：
- FPort：端口号，用于区分不同的应用。比如FPort=1表示温度数据，FPort=2表示湿度数据。
- Payload格式：数据内容的编码方式。可以是纯二进制，也可以是JSON、CBOR等。
- 上下行消息：节点上报数据（上行），服务器下发指令（下行）。
应用层设计的关键：Payload格式一定要提前定义好。我见过太多项目，节点和服务器各写各的，结果数据对不上，排查起来非常痛苦。
2.4 三层之间的交互流程
光说理论没意思，咱们走一遍实际流程。假设你有一个温湿度传感器，每隔10分钟上报一次数据：
- 应用层：传感器采集到温度25°C，湿度60%。应用层把数据打包成二进制：
0x19 0x3C（25和60的十六进制）。然后指定FPort=1，交给MAC层。 - MAC层：收到应用层的数据后，MAC层加上帧头（设备地址、帧计数器等），用AES-128加密，然后计算校验码。接着，它检查信道是否空闲，如果空闲就交给物理层。
- 物理层：MAC层的数据到了物理层，物理层用LoRa调制技术，把数据调制成无线电波，通过天线发射出去。
- 网关接收：网关的物理层收到无线电波，解调成二进制数据，交给MAC层。MAC层解密、校验，确认无误后，把原始数据提取出来，交给应用层。
- 服务器处理：服务器的应用层解析数据，得到温度25°C、湿度60%，存入数据库。
整个过程，从传感器采集到服务器收到，大概需要几百毫秒到几秒不等。具体时间取决于扩频因子和数据包大小。
避坑指南：我曾经在一个项目中，应用层打包数据时忘了加帧计数器。结果MAC层发现帧计数器没变，以为是重放攻击，直接把数据包丢弃了。排查了整整两天才找到原因。所以，应用层和MAC层的交互，一定要严格按照协议来。
2.5 分层架构的SVG示意图
下面这张图，是我用SVG画的LoRaWAN协议栈分层架构。你可以看到每一层的位置，以及数据在层与层之间的流动方向。
这张图里，数据上报是从下往上走，数据下发是从上往下走。每一层只和相邻层通信，不能跨层。这就是分层架构的核心思想——各司其职，互不干扰。
2.6 为什么分层这么重要？
你可能会问：搞这么复杂干嘛？直接一股脑把数据发出去不就行了？
嗯，我刚开始做嵌入式开发时也这么想。直到有一次，我需要把一套LoRaWAN方案从868MHz频段移植到915MHz频段。如果协议栈不分层，我得把整个通信代码重写一遍。但因为分层了，我只需要改物理层的频段配置，MAC层和应用层完全不用动。这就是分层架构带来的好处——模块化、可复用、易维护。
总结一下：
- 物理层：管收发，不关心内容。
- MAC层：管规则，保证通信有序。
- 应用层：管解析，让数据有意义。
这三层各干各的，但配合起来，就是一个完整的LoRaWAN通信系统。
好了，这一章的内容就到这里。下一章我们会深入MAC层，聊聊信道接入和ADR的具体实现。到时候我会分享一个我在实际项目中踩过的坑——关于ADR自动调整速率导致节点掉线的案例，挺有意思的。