网络数据上报时间调节方法：(20210706修订）

本方案主要在协调器端程序做一些改动，原路由器程序无需变动。

实施本方案之前是静态方案，其中K-Interval和D-Interval分别代表心跳和数据的时间间隔（以秒计）。上位机可设置心跳包和数据包的上报时间间隔，比如41:80，这里心跳上报时间间隔K-Interval=41秒，数据上报时间间隔D-Interval=80秒，这个可作为默认基础值，在上位机设置这两个值后，会广播给下面支架。

动态调节的目标是取代手动设置这两个值，自动实现网络拥堵时扩大上报间隙，网络畅通时减少上了间隙，以更快获取数据。

RRI（0xA1）每十分钟个数RRInumber算是一种网络拥堵指标。本方案以10分钟内的RRI个数和CTS个数作为指标，即RRInumber和CTSnumber, 其中RRInumber不作为直接判断网络拥堵依据，而是作为另一个趋势数据busyIndex的参考值，而CTSnumber直接作为网络拥堵的指标。

RRI的增减趋势称为busyIndex，每十分钟统计一次RRInumber值并和之前值比大小，如果大则busyIndex+1, 如果小则busyIndex-1，当busyIndex累计到N次，就扩大上报时间间隙2秒，广播调节指标K-Interval+2/D-Interval+2，并对busyIndex复位清0；当busyInex小于-N时，就缩短上报间隙，此时广播调节指标K-Interval-2/D-Interval-2，并对busyIdex复位清0。 N为一个经验值，初始建议设置为5~10之间，建议把N放在上位机上设置。

BusyIndex需要设置一个上限和下限，到达上下限时清0，以防止这个变量溢出。也可以就以正负N为上下限。当busyIndex到达上限时（一般不可能），同样广播调节指标K-Interval+2/D-Interval+2，当busyIndex到达下限时（网络好有可能），同样广播调节指标K-Interval-2/D-Interval-2。心跳和数据间隔也设置一个最小值，以防止溢出，比如K-Interval或D-Interval的下限都为20秒，小于20秒就不再改小了。

默认上电的调节指标目前测试下来41/80可作为200节点的默认指标。其它网络大小对应的默认指标待测，也可以就用这个41/80模型，因为反正可以动态调节。考虑到外部干扰，相同位置不同时间下的指标阀值并不一定会相同，这也就是为什么需要动态调节数据上报频次的原因，它可以在任何时候把网络拥堵修复到可自愈的状态。

考虑到RRI在网络已经严重堵塞时趋势并不一定有变化，因此还要引入另一个高权值变量，即CTS变高的次数CTSnumber。每当CTS变高，记录CTSnumbr+1,当10分钟内有N次检查到CTS变高，和BusyIndex超N作一样应对处理，即CTSnumber大于N时，广播调节指标K-Interval+2/D-Interval+2。

综上： 程序每10分钟统计读取RRI个数或CTS变高个数，如果CTS变高达N次，心路数据上报时间各扩大2秒。如果RRI连续N次为增量，即BusyIndex累计到N，同样心跳数据上报间隔时间各扩大2秒，直到上限不到增。 反之如果RRI是减量的，即BusyIndex为负，则心跳数据上报时间间隔各减少2秒，直到下限不再减。间隔变动后，CTSnumber和BusyIndex复位为0。CTSnumber和BusyIndex取或就可以了，不必重复比较。

上位机必须可以设置N的值，以便灵活适当不同场景，如果N在上位机没有设置，可用默认值5. N可以作为BusyINdex或CTSnumber的上限。

原理分析

综合前几天测试的结果得出一些结论：网络拥堵时，由于协调器发过不来，实际上它发送负荷很大，以致缓冲区会慢慢增大到溢出状态，此时可见CTS拉高，使用流控来防止缓冲区溢出。当发送负荷大时，发送优先权也适当提高了，此时下面上发数据更容易发生碰撞，从而导致更不容易发通，此时MTO变多，并且协调器收到的RRI会变多。常见的NETWORK ACK Failure和TX Failure大多是这个原因。实测下来，发送选项不禁用ACK时，会导至重传多次发生并且接收端收到数据包超过发送端，而这些包在网络拥者时大多是没有意义的，反而进一步恶化网络拥堵状况。因为此时协调器应答包是入在发送缓冲区末端，所以即便有应答，也是很久之后，和10秒握手的机制不匹配。路由器收到这包理论上也是不会认为是之前应答，但不排除有时刚好在下次发送的时候收到，这也就是大网络拥堵下你们没有频繁退网的事件发生，只有偶发退网事件的原因。