丢包问题如何解决？方法在这里-电子发烧友网

关于丢包的问题

无线通信最常见的问题就是丢包，无论是简单原始的433MHz通信，还是高精尖的5G 信号，都会有丢包问题。解决丢包问题也是无线工程师的必要工作，丢包不可避免，但是遇到丢包了应该怎么办才是本文要谈的。无线通信最重要的就是设计一套能够解决应用需求的通信协议，而通信协议包含这些要素：无线信号使用什么频段、什么调制方式不被干扰、无线信号发给谁、如何保证无线信号送达目标、多个相同的设备同时使用该怎么办、接收端如何判断收到的信号是否重复收或漏收……其实这些都是围绕解决一个问题——丢包。

所以任何一种普遍使用的无线通信协议，都要分成若干逻辑层，每一个逻辑层。例如常见的Wi-Fi、ZigBee、蓝牙，它们都具备两个共同的逻辑层——PHY物理层，MAC链路层。其中PHY层定义了频段、调制方式以及传输方式。MAC层则定义了谁来发信号，谁来收信号，什么时候发信号。基本的PHY层和MAC层解决了常见的物理丢包问题，但是无线设备的应用场景十分复杂，因此各种通信协议之上还增加了诸如网络层这些逻辑层用于保证通信的稳定性，如Wi-Fi协议上的TCP协议就是为了保证传输稳定而设计的。例如ZigBee的PHY层和MAC层就为了减少丢包做了一些处理机制。

减少丢包处理机制

①PHY层的减少丢包机制：
物理层的丢包，就是发送端发送了信号，但是接收端没有接收到信号。这也是最简单也是最常见的原因，通常就是发射端的功率低了，发射端距离接收端太远。遇到这种情况，通常会想到的办法就是提高发射功率，信号能发射得更远。但是根据香农定律，在相同信道带宽下，信号携带的信息量越少，对信噪比的需求越低，对信噪比需求越低就意味着对功率的需求越低。这时除了提高功率，还有一种方式就是扩频。比如典型的ZigBee上使用的DSSS扩频，原本ZigBee的信道带宽有2MHz，也就是能在1秒钟内输出2M个0或1的信号。通常我们使用8个0或1的信号表示一个字节，但是DSSS的作用下，需要64个0或1的信号来表示一个字节。这样使用无线信号传输一个字节需要64个0或1，即使信号在传输过程中发生了失真，接收端也能对信号进行纠错。这也就是为什么ZigBee的传输稳定性优于433MHz通信。正常情况下，ZigBee在20dBm发射功率的情况下，传输距离可达1公里。还有一种情况，就是天线的问题。任何一种天线都有天线增益系数以及方向性。通常外置天线的增益就优于PCB天线，在设备空间充足的情况下尽量选择外置天线。而天线的方向性也是要考虑的因素，例如棒状天线的信号覆盖范围就是一个扁球体，平行天线的位置信号非常好，而天线轴线延长线位置信号差得多。
②MAC层减少丢包的机制：以ZigBee的IEEE802.15.4系列协议为例，该协议的MAC层具有一下几个重要的功能。载波侦听和CSMA机制：IEEE802.15.4具备基于载波侦听的CSMA机制。设备在每次发射信号前，会侦听当前信道是否繁忙，并在信道空闲的时候发射信号。很多sub-G芯片也带有载波侦听功能的，但是缺少类似CSMA这样的协议机制。CSMA则规定了信道侦听的方法：发射前在一个随机时间内持续侦听信道，这样就能适当避免两个相同的设备同时发射信号；随机时间到达后尝试发送信号，如果发送失败就再侦听一次，并且下一次随机时间范围继续扩大（2倍），这样就能避免更多的设备同时发射信号；如果多次尝试都失败，而且达到了最大次数限制，那么这个信号就算丢包了。自动应答机制：IEEE802.15.4-MAC层有两种主要通信方式：广播和点播。点播到目标时，目标节点会返回ACK帧。发送端没有收到ACK帧，会尝试重传信号，如果多次重传都没收到ACK就算丢包。另外接收端回复MAC-ACK的时候是不受CSMA机制可以强行发送的，发送端在CSMA机制下成功将点播信号送出去后，只需要0.2~0.5毫秒就能收到ACK。

因此，导致MAC层丢包常见的现象就是CSMA失败丢包和MAC-ACK失败丢包，和物理层的丢包不同的是这两种丢包都可以被发送端自己检测到。通常遇到这种丢包，应用上的处理就是重传。但是重传也是要讲究科学性的，比如恶意信号干扰导致CSMA失败重传就没法解决；接收目标不存在导致的 MAC-ACK失败重传也是没法解决的。PHY层和MAC层的一系列处理机制都是为了减少丢包而设计的，但是无法保证绝对没有丢包，因此无线应用设计中，最关键的就是遇到丢包了该怎么办。

无线应用中丢包解决方法

以ZigBee传输为例，PHY层、MAC层、NWK层做了很多处理机制，丢包率几乎达到0.1%~0.01%。但是如果应用设计没考虑到仅剩的0.1%~0.01%丢包问题，对应用自身的影响就是致命的。在应用中常见的对丢包的容错，有如下解决办法。①合理重传：重传是大家都能想到的方法，ZigBee就提供了CSMA失败检测和ACK失败检测。通常遇到以上两种情况大家的常见做法就是数据重传。但是重传也要讲究合理性，例如CSMA失败，这个时候有可能是很多个节点同时在发射信号；例如设备上电的时候会把上电时的信息上报给网关，多个设备一起上电肯定会有很大的冲突率，CSMA失败是很常见的事。因此，这时候遇到CSMA失败不要立即重传，可以随机延时100毫秒~1秒再重传，如果再次失败说明同时传输的设备确实太多，再随机延时2~4秒，失败再随机延时4~8秒……。如果是ACK失败则可以根据该次发射数据的实时性，延迟一个固定时间再重传，一般在1秒以上5秒以下，因为有可能上次传输失败是目标节点“不在状态”，下次传输可能就自动好了。②设计时序规则：应用数据传输时需要考虑出现丢包时该如何处理，例如OTA升级，文件传输。每一帧数据都是必不可少的，而且顺序还要正确。所以这类无线传输应用中，应该对每一帧数据包都标注上序号。发送端一旦检测到丢包，可能会重传数据帧。而接收端有可能是因为ACK没有发送到发送端导致发送端误判。如果接收端收到多一帧或少一帧数据，都可以从每一帧的序号判断出来。③该放弃时要放弃：类似接收端不存在，或者信道遇到干扰的问题，通过MAC层都可以侦测到。例如出现连续长时间的ACK失败，可能就是接收端不存在；连续长时间的CSMA失败，可能就是遇到了干扰。接收端不存在的情况下完全可以放弃对这个接收端发送消息。信道被干扰的情况下可以做整体信道切换，也可以暂停全网络的运行，保存当前状态，等待干扰消失后再恢复全部的传输。

不算丢包的“丢包”

无线通信上除了无线信号导致的丢包，还有软件逻辑上的丢包。典型的就是通信的数据量超过了发送端或接收端的处理能力。比如ZigBee的传输速率只有250kbps，加上CSMA延迟，路由转发，实际数据传输速率能够达到5kbps~10kbps就很不错了。发射端的应用程序如果向发射端写入数据的速度超过了发射端的传输速度，也会导致软件丢包。通常各家芯片厂商的IEEE802.15.4的协议栈都会提供一个Send Confirm的回调接口，应用程序向传输接口写入需要传输的消息后，约在几毫秒到几十毫秒内收到Send Confirm回调触发。同时一般射频芯片SoC也会提供缓存来存储写入的数据帧，有可能应用程序一次向射频芯片写入多个数据帧都被芯片SOC缓存起来，再慢慢的一帧一帧发射出去，然后Send Confirm回调被陆陆续续地触发。如果应用程序在发送消息的时候，每次向射频SoC写入传输消息，待Send Confirm触发后再写入下一条消息，就可以很好地规避软件丢包的问题。