4、自愈能力评估指标：RSSI阈值设定、丢包率与重传率、连接稳定性评分模型

评估自愈能力，不能光靠感觉。你得有数据，有标准。

我见过不少项目，自愈逻辑写得挺花哨，但上线后效果好不好，谁也说不清。为什么？因为没有量化指标。你想想看，没有尺子，你怎么知道东西有多长？

这一章，我们就来聊聊这三把尺子：RSSI阈值、丢包率与重传率、连接稳定性评分模型。这三者组合起来，基本就能把自愈能力摸透了。

4.1 RSSI阈值设定：不是拍脑袋定的

RSSI阈值，说白了就是信号弱到啥程度，系统就该动手了。这个值设高了，设备频繁切换，用户体验反而差；设低了，信号都断流了还不动作，自愈就成了摆设。

我个人习惯，把RSSI阈值分成三个等级：

设定阈值时，还要考虑信号抖动。RSSI本身是瞬时值，波动很大。我建议做一次滑动平均滤波，取最近3~5次采样的均值，再跟阈值比较。这样能避免因为一次信号抖动就误触发自愈。

// 滑动平均滤波示例
#define RSSI_SAMPLE_COUNT 5
int rssi_samples[RSSI_SAMPLE_COUNT];
int sample_index = 0;

int get_filtered_rssi(int new_rssi) {
    rssi_samples[sample_index] = new_rssi;
    sample_index = (sample_index + 1) % RSSI_SAMPLE_COUNT;
    
    int sum = 0;
    for (int i = 0; i < RSSI_SAMPLE_COUNT; i++) {
        sum += rssi_samples[i];
    }
    return sum / RSSI_SAMPLE_COUNT;
}

4.2 丢包率与重传率：自愈效果的照妖镜

RSSI只是信号强度的参考，真正影响用户体验的是丢包率和重传率。这两个指标，才是自愈效果的直接体现。

丢包率：单位时间内，发送的数据包中丢失的比例。我一般用Ping测试或者应用层ACK统计来算。

重传率：MAC层重传次数占总发送次数的比例。这个值能从WiFi芯片的驱动层直接读到。

我习惯把这两个指标组合起来看：

• 丢包率 < 1%，重传率 < 5%：网络健康，自愈无需介入。
• 丢包率 1%~5%，重传率 5%~15%：网络轻度劣化，自愈进入预判阶段。
• 丢包率 > 5%，重传率 > 15%：网络严重劣化，立即触发自愈。

4.3 连接稳定性评分模型：把多维指标变成一个分数

有了RSSI、丢包率、重传率，怎么综合判断？我推荐建立一个连接稳定性评分模型。把多个指标映射成一个0~100的分数，方便决策。

模型公式如下：

Score = w1 * S_rssi + w2 * S_loss + w3 * S_retry

其中：
- S_rssi = (RSSI + 100) / 35 * 100  （假设RSSI范围-100~-30）
- S_loss = (1 - loss_rate) * 100
- S_retry = (1 - retry_rate) * 100
- w1, w2, w3 为权重，且 w1 + w2 + w3 = 1

权重怎么定？ 我个人习惯：

• w1 (RSSI权重) = 0.2：RSSI只是参考，权重不宜过高。
• w2 (丢包率权重) = 0.5：丢包率直接影响用户体验，权重最高。
• w3 (重传率权重) = 0.3：重传率反映链路质量，权重居中。

当然，这个权重不是固定的。我在一个视频监控项目中，把丢包率权重调到了0.6，因为视频流对丢包极其敏感。而在一个IoT传感器项目中，RSSI权重反而调高了，因为传感器数据量小，丢包影响不大，但信号弱会导致频繁离线。

4.4 自愈能力评估框架图

下面这张图，把整个评估体系串起来了。从数据采集到指标计算，再到综合评分，最后触发自愈动作。你一看就明白。

4.5 实战中的几个坑

最后，分享几个我踩过的坑，你遇到了可以绕开走。

1. 阈值设得太死板：不同环境、不同设备，阈值必须动态调整。我建议在后台留一个配置接口，方便远程调参。
2. 只看RSSI不看丢包：RSSI好不代表网络好。干扰严重时，RSSI可能很高，但丢包率也高得吓人。
3. 评分模型权重一成不变：业务场景变了，权重也要变。视频流和IoT传感器的权重，能一样吗？
4. 忽略信号抖动：不做滤波，直接拿原始RSSI做决策，自愈会频繁误触发。相信我，用户会骂娘的。