一文带你搞定通信协议的重传机制！

系统层重传机制

有丢包就有重传，针对不同的丢包，重传策略也各不相同。我们还是以ZigBee的重传机制为入口，分析通信协议的重传机制。

CSMA/CA机制

CSMA/CA是配合载波侦听使用的重传机制。我们在讲载波侦听时说过其原理就是接收一段时间，CSMA/CA的重传机制就是去控制侦听时间。

ZigBee的MAC层在发送消息时，会随机侦听一段时间。这个随机时间也是有讲究的，我们都知道ZigBee传输一个字节的时间为32微秒，MAC层规定10个字节的传输时间也就是320微秒为一个“避退周期”。MAC层第一次发送数据时，随机1~8个避退周期的时间来侦听载波，也就是说侦听载波的时间可能是320微秒到2.56毫秒。假设这时有2~3个ZigBee设备同时发送MAC层消息，根据概率散布，它们大概率不会侦测到彼此的载波，因此都有机会成功获得发送窗口。但是如果同时发送的ZigBee设备数据增加，肯定就会有ZigBee设备抢不到发送窗口，造成载波侦听丢包，这时就需要重传。

CSMA/CA的重传也是有讲究的，既然1~8个随机避退周期会有碰撞，索性把避退周期的范围扩大1倍，重传的时候侦听1~16个随机避退周期，这样是不是就降低了避退概率？还不够的话下次重传直接1~32个随机避退周期……但是如果一直有信道冲突，不可能一直无止尽的重传下去，而且每次重传都要扩大随机避退的范围，这是一个无底洞。因此通常ZigBee的MAC层在3次重传都因为载波侦听丢包后会通过“AF Data Confirm”告诉应用层“我已经尽力了”，剩下该怎么办由应用层决定。

MAC层的应答丢包重传

在ZigBee协议中，在发送MAC帧时如果没有收到MAC-ACK，MAC层也会自动重传3次MAC帧。不同于载波侦听的每次重传需要增加间隔时间，MAC层的重传是不会增加间隔时间的。3次重传如果都失败，同样会用“AF Data Confirm”告知应用层丢包且已无力回天。

MAC丢包重传

但是MAC帧的每次重传，还是会进行载波侦听的。如果MAC层的重传再遇上载波侦听冲突，还会诱发CSMA/CA重传。

APS-ACK丢包重传

ZigBee的传输层重传，是用来保证消息有没有传送到最终设备上。APS层在发送消息后，等待6秒钟，没有收到APS-ACK则继续重传。通常APS重传2次，第一次重传是6秒后，第二次重传是12秒后。如果最后一次重传失败，APS层会通过“AF Data Confirm”向应用层报告“死亡通知”。

应用层的重传策略

系统层的重传，无论是CSMA/CA，还是MAC重传，还是APS重传，都是机械呆板的策略。系统层的重传机制，特点就是重传2~3次，如果重传失败就通过“AF Data Confirm”向应用层报告发送失败。

但是应用层是无线传输中智能化程度最高的，也是可以进行重传策略设计的层级。应用层应该根据应用环境、消息的重要性设计丢包重传的策略。我们以ZigBee的应用为例，来设计重传策略。

CSMA/CA失败的重传

通常ZigBee设备出现CSMA/CA失败，要么是环境干扰太强，要么是同时发送消息的ZigBee设备数量太多超过了CSMA/CA的最大窗口。

如果是同时发送消息的设备数量太多，这个时候就要加入“手动避让”机制。比如很多节点同时向协调器上传消息，某个节点通过“AF Data Confirm”检测到载波冲突丢包。这时候可以把丢包的消息记下来，然后同样延时一段随机时间，错开发送高峰进行重传。当然这个随机时间范围就要比MAC层的CSMA/CA的随机时间大得多。应用层的重传可以随机1~4秒进行重传，以0.1秒为最小单位，如果再次发生载波冲突可以加倍随机时间范围。特别是ZigBee网络应用中节点数量是一个动态可变的因素，在节点数量多的时候可以不用在乎数据的实时性，而是要保证每个节点的消息都能被收到，而且“设备越多耗时越多”这个逻辑也是科学合理的道理。

ZigBee系统提供的冲突检测机制，只能检测冲突，但是无法区分是传输冲突还是恶意的信号干扰。因此有可能会出现应用层一直在重传，“AF Data Confirm”一直在报告载波冲突。这个时候应用层就要做“聪明”一点，有可能是ZigBee设备遇到了持续的干扰信号。对于持续的干扰信号只能通过暴力手段解决，可以通过无线电定位设备找到干扰源并摧毁它。

系统应答丢包的重传

系统应答丢包，包括MAC-ACK丢包和APS-ACK丢包，可以采用以下策略。ZigBee的系统层具有Mesh路由设计，数据传输时会寻找一条最短的路由路径。在出现MAC-ACK丢包且MAC重传失败时，ZigBee的路由算法会计算出一条新的路径。而APS-ACK是最终目标丢包，出现这种情况极大可能就是最终目标坏掉，或者这个最终目标根本就不存在。另外如果最终目标不需要经过路由，ZigBee系统直接发送MAC帧，也就直接报告MAC-ACK丢包。

出现应答丢包且重传失败，因为系统层已经做了MAC重传和APS重传。因此可以不用立即重传，可以等待一段时间（10秒~1分钟）再继续重传。如果重传成功则说明目标设备是好的，只是刚才出了点意外；如果重传失败则可以怀疑目标设备出问题了，以后就不要再向出问题的目标设备发送任何消息。在ZigBee网络中如果有故障设备，其它设备向他发送消息都会消耗网络资源对其进行路由寻址，不但会有很长的时延，而且还没有好的结果。因此一旦网络中有故障设备，应用层就应该避免向故障设备发送任何消息。

如何处理应用层的应答？

系统层的应答仅能表示发送的消息是否到达目标，应用层的应答除了表示消息到达目标外，还有表示对消息的执行结果的功能。系统层的应答的英文叫做“acknowledge”简写“ACK”而应用层应答则叫做“response”简写“RSP”。ACK是目标设备收到消息后立即产生的，RSP则是目标设备处理完消息后再回复的，其等待时间要加上目标设备处理消息的时间，这个时间具有很高的不可预测性。因此通常在ZigBee的控制应用中，发送短消息时只使能MAC-ACK而不使能APS-ACK，然后等待RSP。RSP除了可以用来判断是否丢包，还可以判断下次该发送什么消息，这样就可以形成一个闭环控制系统。

闭环负反馈系统，RSP应答可以作为负反馈通道

而接收端收到消息后向发送端发送RSP应答时，为了保证RSP能到达发送端，通常反而会开启APS-ACK。这样即使RSP应答丢包了，传输层的重传机制也会自动让RSP应答重传。另外在ZigBee 3.0中规定ZigBee设备可以用自己的任意状态值作为心跳包报告给另一个设备，心跳包什么时候发出去也是系统层控制不受应用层干预，应用层也不会去干涉心跳包是否丢包。因此心跳包在传送的时候通常也使能APS-ACK而不使能RSP。