4、非确认数据包(UNCONFIRMED)：发送流程、适用场景与风险

4.1 什么是非确认数据包？

非确认数据包，英文叫 UNCONFIRMED。说白了，就是「发出去就不管了」。

终端设备把数据发出去，网关收到了最好。收不到？那就算了。没有 ACK，没有重传，没有反馈。一次性的通信。

我刚开始接触 LoRaWAN 时，总觉得这玩意儿不靠谱。数据发出去没个回音，心里不踏实。后来做多了项目才发现，有些场景下，非确认才是最优解。

4.2 发送流程：简单到极致

非确认的流程，真的非常简单。我画个逻辑给你看：

终端设备：
  1. 应用层产生数据
  2. MAC 层封装成帧（FCtrl 的 ACK 位 = 0）
  3. 随机选择一个信道
  4. 发送数据
  5. 打开两个接收窗口（RX1、RX2）
  6. 如果收到下行数据，处理；收不到，直接结束
  7. 进入休眠或准备下一次发送

注意看第 5 步。虽然是非确认包，但终端还是会打开接收窗口。为什么？

因为网络服务器可能利用这个窗口下发指令。比如调整参数、下发配置。你发的是非确认包，但服务器可以趁机「搭便车」给你发数据。

我在一个智能路灯项目里就遇到过这种情况。路灯上报状态用的是非确认包，但服务器通过 RX1 窗口下发调光指令。既省了流量，又实现了控制。一举两得。

4.3 适用场景：什么时候该用非确认？

不是所有数据都需要确认。我总结了几类典型场景：

场景	说明	我见过的案例
周期性上报	数据频繁发送，丢几包无所谓	温度传感器每 5 分钟上报一次，丢一包不影响整体趋势
冗余数据	同一数据多次发送	水位监测，10 秒发一次，丢包概率极低
低功耗场景	电池供电，能省则省	烟感报警器，一年换一次电池
广播消息	一对多，不需要确认	固件升级通知、系统广播
控制类指令（下行）	服务器下发，终端不回复 ACK	远程开关阀门，丢了再发一次

你想想看，如果每个数据包都要确认，那网络负载会翻倍。尤其在大规模部署时，确认包带来的冲突和重传，反而会降低整体可靠性。

4.4 风险分析：非确认的「坑」在哪里？

非确认包最大的风险，就是「你不知道数据到底到没到」。

我曾经在一个农业物联网项目里吃过亏。土壤湿度传感器用的是非确认包，每 10 分钟上报一次。看起来没问题对吧？

结果有一天，某个区域的传感器因为信号遮挡，连续 3 个小时的数据都没发出去。服务器那边还以为土壤湿度正常，没触发灌溉。等发现时，作物已经蔫了。

这就是非确认包的典型风险：数据丢失不可知。

4.5 避坑指南：如何安全地使用非确认？

既然非确认有风险，那是不是就别用了？当然不是。我分享几个实战经验：

嗯，这里要注意一点。非确认包虽然不要求 ACK，但 LoRaWAN 协议本身还是提供了链路层面的保障。比如 ADR（自适应数据速率）机制，会根据信号质量自动调整速率。所以非确认包的实际丢包率，并没有想象中那么高。

4.6 非确认 vs 确认：一张表说清楚

对比项	非确认 (UNCONFIRMED)	确认 (CONFIRMED)
是否需要 ACK	不需要	需要
重传机制	无	有（最多重传 N 次）
功耗	低	高（多一次接收 + 可能重传）
网络负载	低	高（ACK 包 + 重传包）
可靠性	低（应用层保障）	高（协议层保障）
适用场景	周期性上报、冗余数据	报警、控制指令、关键数据

4.7 总结

非确认数据包，说白了就是「信任但验证」的通信方式。你信任网络能送达，但也要做好验证机制。

我个人习惯是：能用非确认就用非确认，但一定要有兜底方案。比如服务器端的超时检测、应用层的冗余设计、混合使用策略。

记住一句话：非确认包省的是功耗和带宽，但省不掉的是你的设计责任。

下一章，我会讲确认数据包的发送流程和重传机制。到时候你会看到，确认包虽然可靠，但也不是万能的。咱们下章见。