02-协议栈分层与各层给链路预算的贡献
1.2 协议栈分层与各层给链路预算的贡献
本节摘要：LoRaWAN 协议栈按物理层、MAC 层、网络层、应用层四层分工。本节把每一层摊开，回答同一个问题：这一层的每个设计决策，最终在哪本账上记一笔？位置：1.1 定了生态位，本节建立"分层 × 链路预算"的坐标轴，后面每一章都在这根轴上展开。
四层协议栈的分工
| 层 | 负责什么 | 典型实体 | 对链路预算的贡献科目 |
|---|---|---|---|
| 物理层（PHY） | 调制解调、频率、功率、扩频 | LoRa 射频芯片（SX126x 等） | 灵敏度、发射功率、处理增益 |
| MAC 层 | 信道接入、帧格式、接收窗口、重传 | 端设备协议栈（LoRaMac-node 等） | 空中时间、占空比、重传次数 |
| 网络层（NS） | 入网、路由、去重、ADR、调度 | 网络服务器（ChirpStack、TTN） | ADR 调速率与功率、下行调度 |
| 应用层 | 载荷语义、加密、业务逻辑 | 应用服务器 | 净荷长度、上报频率 |
四层不是简单的"上面调下面"，而是每一层都能独立地让链路预算这本账变化。理解协议栈实现，就是理解"每个字节、每个窗口、每次重传分别花了多少预算"。
物理层：灵敏度是上限
物理层的账本科目是灵敏度与发射功率。CSS 扩频把窄带信号铺展到更宽的频带上，接收端用相同的扩频序列做相关运算，把散开的能量重新聚拢——这个"处理增益"直接体现在灵敏度数字上：SF7 时约 -123dBm，SF12 时约 -137dBm，每升一档 SF 换来约 2.5dB 灵敏度，代价是数据速率减半。发射功率方面，芯片与法规共同设限：EU868 上限 14dBm，部分区域受占空比与跳频要求限制。
物理层的设计决策（SF 档位、带宽、编码率）是链路预算里最"物理"的部分，其余各层都在它定下的基础上做文章。
MAC 层：空中时间与占空比是支出
MAC 层的账本科目是时间。一次上行占用的空中时间由 SF、带宽、净荷长度共同决定（1.3 与 2.2 有完整算法）；而免授权频段普遍有占空比限制（EU868 为 1%，即每小时内发射时间不得超过 36 秒）。空中时间 × 发送次数 = 每小时的发射预算。MAC 层的接收窗口（RX1/RX2 时序）、重传机制、Class A/B/C 切换，全部是在这个时间预算里精打细算。
网络层：ADR 是调账手段
网络层的账本科目是速率与功率的调节。网络服务器根据上行信噪比（SNR）估算链路余量，通过 ADR 指令让设备升速或降速、加功率或减功率：余量充足就升 DR 省电省时间，余量吃紧就降 DR 换灵敏度。ADR 一次只调一档，且只在网络服务器侧发起，设备只负责执行——这是"网络层能改链路预算"的最典型例子。
应用层：净荷与频率是入口
应用层的账本科目是每字节与每次上报的成本。净荷越长，空中时间越长（2.2 有字节到毫秒的换算）；上报越频繁，电池消耗与占空比占用越大。很多实际部署的优化（缩短报文、合并上报、只在变化时上报）都发生在这一层——它离预算最近，也最容易被忽视。
从分层到实现：一次上报的完整开销走查
把四层的账本串起来走一遍，比背分层定义有用得多。以"12 字节水位读数，SF10，每天上报 24 次"为例：
| 环节 | 哪一层 | 开销 | 累计 |
|---|---|---|---|
| 应用打包 12 字节明文 | 应用层 | 0 | 12 |
| 会话密钥加密 | 应用层 | 0（不增字节） | 12 |
| 加 MAC 头（DevAddr+FCtrl+FCnt+FPort） | MAC 层 | +8 字节 | 20 |
| 加 MIC 完整性校验 | MAC 层 | +4 字节 | 24 |
| 加 PHY 层开销（前导码+帧头+编码率） | 物理层 | 约 +10 符号 | 空中约 0.4s（SF10） |
| 占空比消耗（1%） | MAC 层 | 每 24 次约 10s/小时预算内 | 无碍 |
| 电池（每次发送约 40mA×0.4s） | 全栈 | 每次约 16mAs | 每日约 0.11mAh |
这张表回答了实现中最常被问的"我的上报为什么这么费电、这么占信道"——大头不在净荷，而在帧头、MIC 与物理层前导码。一次 12 字节的上报，空口开销约是净荷的两倍，时间与电量按全帧计算。
进一步推导：如果把 24 次合并成 4 次（每次带 3 条读数，用端口或负载切分），空中时间从 24×0.4s 降到 4×1.0s≈4s——信道占用减少 58%，电池消耗减少约 40%。这就是"应用层合并上报"为什么是性价比最高的优化：它同时动了时间账与电量账。
每层的优化杠杆速查
| 层 | 可调的旋钮 | 优化方向 | 注意 |
|---|---|---|---|
| 物理层 | SF、带宽、编码率 | 够用就升速率 | 覆盖率与速率二选一 |
| MAC 层 | 报文长度、重传次数、窗口时序 | 压帧长、免确认 | 重传是隐性成本 |
| 网络层 | ADR、下行调度、网关选择 | 让 NS 自动调账 | 关闭 ADR 需人工维护 |
| 应用层 | 上报频率、载荷合并、事件触发 | 按需上报 | 数据延迟与电池的权衡 |
要点收束：四层各有一本账，也各有各的优化杠杆；优化顺序建议先从应用层（频率与净荷）入手，再动 MAC 层（帧长与重传），物理层与网络层交给 ADR 自动调节。这一章之后，你要能对任何一个"为什么这么设计"给出预算层面的解释。
易错点清单
- 跨层孤军奋战：在物理层调大功率却在网络层关掉 ADR，预算会被两边重复支取；
- 把占空比当网络层的事：占空比是 MAC 层的硬约束，网络服务器无法替你兜底；
- 忽略应用层开销：一个 12 字节的读数，套上 13 字节的帧头与 4 字节的 MIC 后，空中时间可能是净荷的几倍——先算总账再优化单个环节。
要点回顾：物理层定灵敏度上限，MAC 层管时间预算，网络层做速率功率调账，应用层决定净荷与频率。下一节把这张账落到实处：拿一个真实部署需求，半小时手工算出链路余量。
小结与延伸
四层分工可以浓缩成一句记忆线：物理层给上限，MAC 层记时间，网络层调速率，应用层定频率。调试协议栈时，遇到"上报太费电"先看应用层频率与净荷，再看 MAC 层是否开了确认与重传，最后才怀疑物理层配置——按这个顺序排查，能少走一半弯路。延伸思考：如果设备侧不用 LoRaWAN 协议栈，而用纯 LoRa 点对点（不接入网络服务器），网络层与 ADR 的"调账"能力随之消失，链路预算就得完全靠静态规划——这正是很多自组网方案覆盖规划偏保守的原因。