第1章 多连接依赖隔离问题全景

1.1 问题定义

多连接依赖隔离问题是指在蓝牙嵌入式系统中，当中央设备（如手机、网关）同时维护多条逻辑连接（经典音频连接、BLE GATT 连接、厂商私有协议连接）时，某一条连接上的异常行为（超时、断连、大流量、错误状态机）导致依赖它的其他连接出现功能退化、数据错乱或系统级崩溃的现象。核心冲突在于：操作系统和蓝牙协议栈为多个连接共享了底层资源（链路层调度、HCI 命令队列、ACL 数据包缓冲、全局连接句柄空间），但上层业务却假设连接之间是相互独立的。

1.2 典型场景

以下四种场景在实践中出现的频率最高，覆盖了消费电子、工业物联网和汽车蓝牙模块的主要痛点：

1.3 业务痛点

从产品交付角度看，依赖隔离问题带来的业务损失非常直接：

• 认证失败风险： SIG 认证的互操作性测试（ICS/IXIT）要求某一连接处于异常状态时，其他连接仍能通过基本功能测试；未做隔离设计的产品在认证过程中需反复打补丁，延误上市。
• 现场 OTA 崩溃： 固件升级过程中，一个已配对的传感器周期性断连，发起重连操作时干扰了升级协议的 ATT 流控，导致升级固件写入不完整，设备变砖。
• 多用户并发体验差： 在会议音箱场景，三个手机同时连接，其中一部电话来电（SCO 连接）导致其余两路的 A2DP 数据流被完全阻塞，用户体验从“三个设备可用”降级为“只有一个设备能用”。

1.4 技术挑战

实现干净的多连接依赖隔离在工程上并不简单，主要面临以下四层挑战：

1. 协议栈层耦合： 蓝牙控制器的 Link Layer 使用同一个调度器仲裁所有连接的活动时隙。没有硬件辅助的 TDMA 或时间片隔离，软件层面的状态隔离只能降低碰撞概率，无法杜绝。
2. 资源竞争与饥饿： HCI ACL 数据包缓冲池是所有连接共享的。一个连接如果持续发送大包（例如 512 字节的 ATT Write Request）且流控窗口不释放，其他连接的 Write 请求被延迟或丢弃。
3. 状态机传染： BLE 连接的状态机（如 Encryption、Connection Update、PHY Update）在 Host 层通过同一个 HCI 命令序列管理。一个连接的 Security Manager Pairing 流程进入等待状态，会阻塞该控制器的 HCI 事件管道，进而影响同控制器下所有连接的状态变更。
4. 信任链路未切割： 很多应用层业务（如配网、OTA、数据透传）在设计时假设“只要蓝牙连接存在，就可以安全地发送任意数据”。没有在架构上设计连接级别的信任域，导致一个连接上的恶意/异常数据直接污染了另一个连接的协议状态机或业务缓存。

1.5 全景总结：问题边界与架构分层对应

下图概括了多连接依赖隔离问题的完整边界，以及后续章节将要分解的架构分层视角。每个节点代表一个可能会成为“依赖传染源”的模块，箭头指示了故障传播路径。

1.6 落地检查清单：验收标准

在进入后续章节的架构设计之前，团队应该对照以下验收标准评估当前系统的依赖隔离成熟度：