1. 课程导论：为什么LPWAN需要数据压缩？核心挑战与优化目标
大家好，我是老张。做物联网这行十几年了，从最早的2G模块一路干到现在的NB-IoT、LoRa。今天咱们聊聊LPWAN数据压缩这件事。
说实话，我刚入行那会儿，压根没想过数据压缩这回事。那时候觉得，传感器采集的数据就那么点，直接发呗，能有多大问题？直到有一次，我在一个水表抄表项目里栽了跟头——电池撑不过三个月，用户天天投诉。拆开一看，问题出在数据包上：每次上报都带着完整的时间戳、设备ID、校验码，真正有用的读数才占20%。
嗯，从那以后，我养成了一个习惯：任何LPWAN项目，第一件事就是算数据效率。
1.1 LPWAN的天然瓶颈
LPWAN（低功耗广域网）的设计初衷，说白了就是「用最少的能量，传最远的路」。但代价是什么？
- 带宽极窄：LoRa一个信道通常只有几百bps，NB-IoT也就几十kbps。你想想看，传一张高清图片？别想了。
- 单次载荷有限：LoRa单包最大也就256字节，NB-IoT虽然大一些，但运营商套餐往往限制单次传输量。
- 功耗敏感：终端设备靠电池供电，发射1秒钟的功耗，够MCU跑好几分钟。
核心矛盾：应用层想要「多传数据」，物理层只能「少发报文」。数据压缩就是解决这个矛盾的钥匙。
1.2 不压缩的代价有多大？
我给大家算一笔账。假设一个温湿度传感器，每分钟上报一次数据：
| 方案 | 原始数据格式 | 单包大小 | 每天流量 | 电池寿命（2000mAh） |
|---|---|---|---|---|
| 不压缩 | JSON: {"temp":25.3,"hum":68.2} | ~40字节 | 57.6KB | 约8个月 |
| 简单压缩 | 二进制: 0xFD 0x44 | 2字节 | 2.88KB | 约2年+ |
看到了吗？压缩比20:1，电池寿命直接翻3倍。我在项目中遇到过最夸张的案例：一个农业大棚项目，压缩前每天要发3000个包，压缩后降到150个包，网关负载也降下来了。
1.3 核心挑战：不是所有压缩都适合LPWAN
你可能会说：「那直接用ZIP压缩不就行了？」
千万别！LPWAN的压缩，跟PC上的压缩完全是两码事。我踩过的坑，给大家列出来：
- 计算开销不能大：MCU主频通常只有几十MHz，跑个LZ77算法，CPU占用率直接飙到80%，传感器采集都受影响。
- 内存占用要小：很多LPWAN芯片RAM只有几KB到几十KB，你搞个字典压缩，字典还没建完，内存先爆了。
- 实时性要求：有些场景（比如报警数据）需要立即上报，不能等压缩缓冲区填满再发。
- 丢包容忍：无线信道不稳定，如果压缩算法依赖前后数据关联，丢一个包整段数据都解不出来。
避坑指南：我曾经在一个项目里用了差分编码压缩温度数据，结果无线信道丢包率超过5%，解出来的数据全是错的。后来改成「带校验的增量压缩」，每个包都携带基准值，才解决问题。
1.4 优化目标：四个维度
做LPWAN数据压缩，不能只盯着压缩率。我个人习惯从四个维度评估：
- 压缩率：原始数据大小 / 压缩后大小。目标通常做到5:1以上。
- 计算复杂度：压缩和解压所需的CPU周期。建议控制在MCU主频的10%以内。
- 内存占用：算法运行时需要的RAM。对于STM32L0这类芯片，建议不超过2KB。
- 鲁棒性：在丢包、错序情况下的恢复能力。至少要能检测到数据异常。
这四个维度往往是矛盾的。压缩率高了，计算量就大；鲁棒性强了，压缩率就低。怎么平衡？嗯，这就是咱们这门课要解决的核心问题。
1.5 知识体系总览
下面这张图，是我梳理的LPWAN数据压缩知识体系。你可以把它当成整个课程的地图：
1.6 这门课能给你什么？
说白了，这门课不讲虚的。30个章节，每个章节都对应一个实战问题：
- 前10章：把数据编码吃透。从最简单的位域打包，到高级的算术编码，每个算法我都会给出MCU上的实测数据。
- 中间10章：协议层优化。CoAP、MQTT-SN、LwM2M这些协议怎么压缩？SCHC标准怎么落地？我会拿实际抓包数据说话。
- 后10章：系统级设计。自适应压缩策略、功耗建模、OTA升级中的压缩技巧——这些都是我踩过坑之后总结出来的。
我的建议：如果你时间紧，可以先看第5章（差分编码）、第12章（SCHC实战）、第25章（功耗优化）。这三个章节覆盖了80%的常见场景。
好了，导论就到这里。记住一句话：在LPWAN的世界里，每一比特都值得被认真对待。接下来，咱们从最基础的二进制编码开始，一步步把数据压缩这件事做到极致。
公众号:蓝海资料掘金营，微信deep3321