多传感器BLE网关容量评估与重连测试

“一台网关能接多少个BLE传感器？”这个问题必须同时说明工作负载。十个传感器每分钟上报一次，与十台设备每20毫秒突发发送数据，属于不同的工程问题。可信的容量规格需要明确无线硬件与软件限制，在目标负载下验证数据新鲜度，并测量多个传感器同时掉线后的恢复过程。

先选择连接式采集还是广播采集

连接式GATT网关维持链路、订阅特征，也可能下发配置命令。广播采集器监听无连接上报。Bluetooth Mesh又采用另一套通信与配网模型。这些架构的发现、交付和安全属性不同，节点数量不能直接互相套用。

先建立设备清单：协议及固件版本、上报格式、采样频率、突发长度、是否可连接、配对要求，以及允许的数据年龄。确定缺失的历史样本是否必须补回，还是只需要最新测量值。若部署有相关安全要求，广播采集还需在应用层定义真实性验证、重复抑制和重放处理方式。

欧蓓特的已交付的ESP32 Wi-Fi与蓝牙网关案例介绍了不同的Wi-Fi及SIG Mesh方案方向，可用于理解架构背景，但其中没有给出连接式GATT传感器容量的实测结论。GATT网关仍需针对终端和负载单独验证。

区分连接数量硬上限与可用容量

核对具体芯片、控制器固件、Host协议栈、SDK版本和构建配置。Host连接对象、控制器链路、ACL缓冲、绑定信息存储以及应用队列分别有各自限制。只提高其中一个配置，无法消除其余瓶颈。

以明确版本的例子说明：Espressif的ESP-IDF v6.0.3 ESP32多连接指南列出，ESP-NimBLE与ESP-Bluedroid均支持最多九条并发连接，需要设置对应Host选项，并匹配控制器设置。这是实现上限，不是所有负载、所有ESP32系列芯片都能保证的传感器数量。Zephyr同样提供CONFIG_BT_MAX_CONN。应核查产品实际版本对应的文档。来源：Espressif多连接指南和Zephyr GAP Shell文档。

对Linux网关而言，增加内存或换用更快的CPU，并不能证明无线控制器支持更多连接。应记录USB/UART控制器型号、固件、内核及BlueZ版本。通知回调应保持简短：校验后入队，将数据库写入和上行任务放到蓝牙回调路径之外执行。

建立有测量余量的流量预算

先计算应用数据量。例如，八个传感器各以5 Hz产生16字节记录，协议开销之前的数据量为每秒640字节。这个算术结果不是射频吞吐量预测。报文交换、空连接事件、确认、重传、扫描和调度都会消耗额外时间。

初步筛选时，可以将每条链路的预计连接事件空口时间除以连接间隔，再将结果求和。还要为扫描、重连和上行共存留出空间。这个估算既不是蓝牙调度保证，也不能代替测量：事件重叠、控制器策略和突发到达，都会导致平均预算看似充足时仍然失败。

测量实际协商的连接间隔、外设延迟、监督超时、PHY、ATT MTU和链路层数据长度。更大的ATT MTU不保证更长的链路层报文，也不保证每次连接事件可以交换更多报文。增加连接间隔可能更利于调度，却也可能恶化延迟或突发缓存需求。应围绕数据新鲜度目标调整参数，而不是直接套用泛化的“最高吞吐量”设置。

将重连实现为有边界的状态机

分别跟踪每个传感器的发现、连接、安全建立、服务解析、订阅和数据流状态。“已连接”不等于“已就绪”。一种有用的就绪判据是：订阅后收到了首个有效、身份正确的应用样本。

DISCOVER -> CONNECT -> SECURE -> RESOLVE -> SUBSCRIBE -> STREAM
failure  -> RELEASE_RESOURCES -> BACKOFF -> DISCOVER

# Illustrative full-jitter backoff, seconds:
delay = random_uniform(0, min(60, 2 ** min(attempt, 6)))
# Reset attempt after a defined healthy-stream interval.
# Limit simultaneous connection/setup attempts globally.

以上时间参数只是设计示例，并非BLE规定值。每个状态都要有超时、取消路径和原因码。对协议版本不兼容、反复认证失败等需要人工处理的故障，应限制重试，显示可操作的故障信息，而不是始终高速重试。

断连后，按接口要求释放失效句柄和回调注册，取消已过时的任务，再恢复所需安全状态与订阅。应通过受支持的绑定/隐私机制或经过认证的应用标识维持稳定身份，不能把轮换的私有地址一概当成新传感器。在BlueZ上，应使用受支持的通知接口并处理文档列出的错误。参见BlueZ GATT API。

使用启动标识及样本序号区分重启、缺失和重复。只持久化产品恢复约定所需要的状态。网关在补传积压数据时重启，不能让旧样本被静默标记为实时读数。

在所有链路繁忙时测试竞争和故障

在共享射频的设计中，BLE采集与Wi-Fi通信会竞争射频资源。Espressif文档说明了基于优先级的共存机制，以及Wi-Fi状态改变时的调度变化。测试既要覆盖稳定上行，也要覆盖Wi-Fi扫描和重连；安静实验台上的连接不能代表这些条件。参见ESP32共存指南，随后核对所选SDK和芯片对应版本。

使用最终产品外壳、天线位置和电源。逐步增加受支持的传感器数量和上报速率，然后在目标工作边界，以受控衰减或具有代表性的摆放方式重复测试。RSSI本身不能作为通过条件。保留一组强信号对照设备，以区分队列或CPU问题和射频问题。

以可用数据定义验收条件

在测试前设定通过阈值。例如，可以要求样本年龄的第99百分位小于两秒、达到规定的去重样本交付比例，并在约定恢复窗口内恢复所有可达传感器。这些只是需求示例，不是已取得的测试结果。每分钟采样一次的慢速传感器，需要不同的新鲜度目标。

必须定义分母：测量窗口内应产生的样本、传感器实际保留的样本，或具备发送条件的样本，是不同的统计口径。重复样本应与唯一交付样本分别计数。记录已知离线时段如何影响目标。同时给出首次尝试成功率和最差节点表现，避免总体平均值掩盖某个传感器长期得不到服务的问题。

只有在时钟已同步，或偏差及漂移有明确边界时，才能从传感器采集时间戳计算样本年龄。否则，应单独报告从网关接收到上行的延迟，并将端到端样本年龄标记为未知。用单调时钟测量本地状态持续时间，完整记录故障、检测、连接、订阅和首个有效样本的时间线。

针对真正失败的层排查

• 链路连上却没有数据：检查服务解析、订阅状态、权限及传感器生产数据的状态。
• 只有较高设备数量才失败：检查控制器限制、缓冲耗尽、事件调度和全局初始化并发数。
• 上行活动后出现故障：对比Wi-Fi共存轨迹、回调耗时及队列增长。
• 一个故障传感器拖慢其他所有设备：检查共享锁、串行且无边界的重试，以及队列公平性。
• 只有重启后才能恢复连接：检查泄漏的连接对象、失效回调，以及没有超时出口的状态。

有效的项目资料应包括传感器样机、固件版本、流量模型、拓扑、上行行为和量化验收目标。欧蓓特的网关集成服务可用于界定这项工作。交付物应针对选定配置给出带版本的容量边界和恢复报告，并以日志支持结论。 架构背景可参阅相关的已交付的ESP32 Wi-Fi与蓝牙网关案例。本文的数值示例和测试计划并非该案例的实测结果。