前文讲解了是什么是无线通信应用中的网络丢包率和无线传输应用有哪些处理机制减少网络丢包率？，本文根据前文整理的文件，整理了以下几点可以解决无线传输中网络丢包问题的办法：
以ZigBee传输协议为例，PHY层、MAC层、NWK层做了很多处理机制，网络丢包率几乎达到0.1%~0.01%。但是如果应用设计没考虑到仅剩的0.1%~0.01%丢包问题，对应用自身的影响就是致命的。在物联网应用中常见的对无线通信网络丢包的容错，有如下解决办法。
重传是大家都能想到的方法，ZigBee模块就提供了CSMA失败检测和ACK失败检测。通常遇到以上两种情况大家的常见做法就是数据重传。但是重传也要讲究合理性，例如CSMA失败，这个时候有可能是很多个节点同时在发射信号；例如设备上电的时候会把上电时的信息上报给DTU无线网关设备，多个设备一起上电肯定会有很大的冲突率，CSMA失败是很常见的事。因此，这时候遇到CSMA失败不要立即重传，可以随机延时100毫秒~1秒再重传，如果再次失败说明同时传输的设备确实太多，再随机延时2~4秒，失败再随机延时4~8秒……。如果是ACK失败则可以根据该次发射数据的实时性，延迟一个固定时间再重传，一般在1秒以上5秒以下，因为有可能上次传输失败是目标节点“不在状态”，下次传输可能就自动好了。
应用数据无线传输时需要考虑出现丢包时该如何处理，例如OTA升级，文件传输。每一帧数据都是必不可少的，而且顺序还要正确。所以这类无线传输应用中，应该对每一帧数据包都标注上序号。发送端一旦检测到丢包，可能会重传数据帧。而接收端有可能是因为ACK没有发送到发送端导致发送端误判。如果接收端收到多一帧或少一帧数据，都可以从每一帧的序号判断出来。
类似接收端不存在，或者信道遇到干扰的问题，通过MAC层都可以侦测到。例如出现连续长时间的ACK失败，可能就是接收端不存在；连续长时间的CSMA失败，可能就是遇到了干扰。接收端不存在的情况下完全可以放弃对这个接收端发送消息。信道被干扰的情况下可以做整体信道切换，也可以暂停全网络的运行，保存当前状态，等待干扰消失后再恢复全部的传输。
无线通信上除了无线信号导致的丢包，还有软件逻辑上的丢包，所以首选需要了解如何检测数据丢包重传。典型的就是通信的数据量超过了发送端或接收端的处理能力。比如ZigBee的传输速率只有250kbps，加上CSMA延迟，路由转发，实际数据传输速率能够达到5kbps~10kbps就很不错了。发射端的应用程序如果向发射端写入数据的速度超过了发射端的传输速度，也会导致软件丢包。
通常各家MCU芯片厂商的IEEE 802.15.4的通信协议栈都会提供一个Send Confirm的回调接口，应用程序向传输接口写入需要传输的消息后，约在几毫秒到几十毫秒内收到Send Confirm回调触发。同时一般射频芯片SoC也会提供缓存来存储写入的数据帧，有可能应用程序一次向射频芯片写入多个数据帧都被芯片SOC缓存起来，再慢慢的一帧一帧发射出去，然后Send Confirm回调被陆陆续续地触发。如果应用程序在发送消息的时候，每次向射频SoC写入传输消息，待Send Confirm触发后再写入下一条消息，就可以很好地规避软件丢包的问题。
对于接收端也是如此，多个发送端向同一个接收端发送消息，CSMA很好地规避了冲突，发送端收到了各自的ACK，但是发送端发送的消息在接收端没有得到正确的响应。那么就有可能是接收端的处理能力有限，各个发送端累计发送的消息全部堆在接收端正在处理，这种情况就要考虑系统设计问题，减少接收端的处理压力。
相关文章推荐：
今天的分享就到这里啦，EBYTE每一天都致力于更好的助力物联化、智能化、自动化的发展，提升资源利用率，更多产品更多资料，感兴趣的小伙伴可以登录我们的亿佰特官网进行了解，还有客服小姐姐在线答疑哦！
