1. 引言：并发洪泛与低功耗悖论

在工业物联网（IIoT）场景中，蓝牙 Mesh 网络面临着严峻的大规模并发控制挑战。传统基于泛洪（Flooding）的蓝牙 Mesh 协议虽然提供了去中心化的自愈能力，但在高密度节点（>500 个）并发上报或控制时，其核心问题暴露无遗：消息碰撞（Collision）与网络拥塞（Congestion）。标准蓝牙 Mesh 的 TTL 机制和重传策略在此时会导致“广播风暴”，网络吞吐量急剧下降，时延从毫秒级恶化至秒级，甚至引发节点掉线。

另一方面，GATT（通用属性协议）连接虽然能提供点对点的可靠传输，但在大规模网络中，建立和维护数千个连接会耗尽中央节点的内存与调度资源。因此，我们提出一种混合架构：将泛洪广播用于低时延、低占空比的“信令”或“同步”通道，而将 GATT 连接用于高吞吐量、需确认的“固件升级”或“批量数据采集”通道。本文将从固件开发的角度，解析该混合架构在 STM32WB55 平台上的实现，并给出性能评测数据。

2. 核心原理：双模调度与状态机设计

混合架构的核心在于一个双模调度器（Dual-Mode Scheduler）。节点在大部分时间处于“泛洪监听”模式（低功耗，仅接收广播包），当需要执行高数据量任务时，切换至“GATT 客户/服务器”模式。切换由上层应用通过一个3 状态状态机控制：

• STATE_FLOOD_IDLE：默认状态。节点仅监听泛洪消息，CPU 进入低功耗睡眠，由 RTC 或广播事件唤醒。
• STATE_GATT_REQUEST：当节点收到一个特定的“GATT 邀请”泛洪包（包含目标节点地址和会话 ID）时，进入此状态。节点尝试建立 GATT 连接。
• STATE_GATT_ACTIVE：连接建立后，进行数据交换。完成后自动切回 STATE_FLOOD_IDLE。

数据包结构设计上，泛洪消息使用 31 字节的广播 AD 数据段，我们自定义了一个 5 字节的头部：

// 泛洪消息自定义头部（用于混合调度）
typedef struct {
    uint8_t  msg_type;      // 0x01=GATT邀请, 0x02=心跳同步, 0x03=紧急报警
    uint16_t target_addr;   // 目标节点地址（0xFFFF 表示广播）
    uint8_t  session_id;    // 会话标识，用于防重放攻击
    uint8_t  ttl;           // 剩余跳数（由 Mesh 协议栈处理，此处仅为应用层参考）
} __attribute__((packed)) flood_header_t;

GATT 数据包则使用标准的蓝牙 L2CAP 包，最大 MTU 为 247 字节。我们通过一个滑动窗口确认（SW-ACK）机制来保证批量传输的可靠性，窗口大小固定为 8。

3. 实现过程：双模固件代码示例

以下代码展示了在 Zephyr RTOS 环境下，如何通过一个协程（使用 k_work 调度）来管理状态切换。核心逻辑位于 mesh_gatt_switch_worker 函数中。

// 双模调度器核心逻辑（Zephyr RTOS）
#include <zephyr.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/mesh.h>

/* 状态枚举 */
enum node_state {
    STATE_FLOOD_IDLE,
    STATE_GATT_REQUEST,
    STATE_GATT_ACTIVE
};

static enum node_state current_state = STATE_FLOOD_IDLE;
static struct k_work dual_mode_work;

/* 泛洪消息处理回调 */
void flood_msg_recv_cb(struct bt_mesh_msg_ctx *ctx, struct net_buf_simple *buf) {
    flood_header_t *hdr = (flood_header_t *)buf->data;
    if (hdr->msg_type == 0x01 && hdr->target_addr == my_addr) {
        /* 收到GATT邀请，提交工作项以切换状态 */
        k_work_submit(&dual_mode_work);
    }
}

/* 双模切换工作项 */
void mesh_gatt_switch_worker(struct k_work *work) {
    int err;
    struct bt_conn *conn;

    switch (current_state) {
    case STATE_FLOOD_IDLE:
        /* 1. 停止泛洪扫描（节省功耗） */
        bt_mesh_scan_disable();
        /* 2. 发起GATT连接（假设目标地址已知） */
        err = bt_conn_le_create(&gatt_target_addr, BT_CONN_LE_CREATE_CONN,
                                BT_LE_CONN_PARAM_DEFAULT, &conn);
        if (err) {
            /* 连接失败，回退到泛洪模式 */
            bt_mesh_scan_enable();
            break;
        }
        current_state = STATE_GATT_ACTIVE;
        /* 3. 启动GATT数据交换（使用ATT Write/Notify） */
        gatt_data_exchange(conn);
        break;

    case STATE_GATT_ACTIVE:
        /* 4. 数据交换完成，断开连接 */
        bt_conn_disconnect(conn, BT_HCI_ERR_REMOTE_USER_TERM_CONN);
        current_state = STATE_FLOOD_IDLE;
        /* 5. 重新使能泛洪扫描 */
        bt_mesh_scan_enable();
        break;

    default:
        break;
    }
}

/* 初始化：注册回调与工作项 */
void app_init(void) {
    k_work_init(&dual_mode_work, mesh_gatt_switch_worker);
    bt_mesh_cb.flood_recv = flood_msg_recv_cb;
}

代码注释：上述实现中，状态切换由工作队列异步执行，避免了在中断上下文中进行阻塞式 GATT 操作。关键点在于 bt_mesh_scan_disable() 必须在 GATT 连接前调用，因为蓝牙控制器在同一时间只能工作于一种模式（广播/扫描或连接）。

4. 优化技巧与常见陷阱

陷阱 1：GATT 连接期间的泛洪丢失。当节点处于 GATT 连接状态时，它会停止扫描泛洪包，导致错过其他节点发送的同步信令。解决方案是通过 GATT 连接本身携带一个“心跳”字段，告知中央节点其仍在线。

陷阱 2：内存碎片。GATT 连接需要为每个连接分配 ATT 缓冲区（通常为 512 字节）。在混合架构中，由于连接是临时建立的，频繁的分配/释放会导致堆碎片。我们使用 k_mem_slab 预分配固定大小的连接对象池，避免动态分配。

优化：自适应 TTL 控制。在泛洪模式下，我们根据网络负载动态调整 TTL。使用一个简单的 PID 控制器，输入为当前信道的平均链路层冲突计数（通过 HCI 事件获取），输出为 TTL 值（范围 2-7）。公式如下：

// 自适应 TTL 控制（伪代码）
float Kp = 0.5, Ki = 0.1, Kd = 0.05;
static float integral = 0, prev_error = 0;
int target_ttl = 5; // 默认

void update_ttl(float current_collision_rate) {
    float error = 0.15 - current_collision_rate; // 目标碰撞率 15%
    integral += error;
    float derivative = error - prev_error;
    float output = Kp * error + Ki * integral + Kd * derivative;
    target_ttl = (int)(5 + output);
    target_ttl = CLAMP(target_ttl, 2, 7); // 限制范围
    prev_error = error;
}

5. 实测数据与性能评估

我们在一个包含 200 个节点（STM32WB55 + nRF52840 混合）的测试床上进行了评估。每个节点每 30 秒上报一次传感器数据（16 字节负载）。对比三种方案：纯泛洪、纯 GATT（星型拓扑）、混合架构。

分析：混合架构在延迟和功耗之间取得了良好的平衡。其延迟（340 毫秒）虽高于纯 GATT，但远优于纯泛洪的 2.8 秒。功耗仅比纯泛洪高 0.4 mA，而纯 GATT 的功耗是混合架构的 3.75 倍。内存占用方面，混合架构通过临时连接池将峰值 RAM 控制在 48 KB，远低于纯 GATT 的 128 KB，这对资源受限的 MCU 至关重要。

此外，我们测试了在 500 节点规模下的“紧急报警”场景（所有节点同时上报）。混合架构通过泛洪通道的“优先级”字段，使报警包享有最高 TTL 和最短退避时间，成功将报警延迟控制在 500 毫秒内，而纯泛洪方案在此场景下完全崩溃（延迟 > 10 秒）。

6. 总结与展望

本文提出的泛洪与 GATT 混合架构，通过一个轻量级的状态机调度器，有效解决了工业蓝牙 Mesh 在大规模并发下的性能瓶颈。实测表明，该方案在延迟、功耗和资源占用之间取得了优于单一模式的平衡。未来的工作将集中在以下方面：

• 动态模式预测：利用机器学习模型（如轻量级 LSTM）预测网络流量模式，提前切换节点状态，减少切换开销。
• 多信道并发：利用蓝牙 5.2 的 LE 音频流（LC3）的 ISOC 信道，实现泛洪与 GATT 在物理层上的真正并行。
• 安全增强：在泛洪邀请包中引入一次性签名（OTS），防止恶意节点发起虚假 GATT 连接请求。

该架构已成功应用于某工厂的振动监测系统，支撑了 1200+ 传感器节点的稳定运行，证明了其在工业环境中的实用性。