BLE通信基础：GAP与GATT协议详解

1. BLE通信基础：GAP与GATT的角色定位

在低功耗蓝牙（BLE）技术体系中，GAP和GATT就像是一对默契的搭档，共同构成了设备通信的基础框架。作为从事物联网开发多年的工程师，我发现很多初学者容易混淆这两个概念。实际上，它们的职责划分非常清晰：GAP负责"认识新朋友"，而GATT则处理"朋友间的对话"。

GAP（通用访问配置文件）定义了设备如何被发现和连接。想象你参加一个社交聚会，GAP就是决定你是否佩戴姓名标签（广播模式）、如何与他人握手（连接建立）以及谁能获取你的联系方式（安全权限）的那套规则。我曾在智能家居项目中遇到设备无法被发现的问题，最终排查发现正是GAP层的广播参数配置不当所致。

GATT（通用属性配置文件）则规定了连接建立后的数据交互方式。如果把BLE设备比作一本书，GATT就是这本书的目录结构——它用服务（章节）、特征（段落）和描述符（注释）的层级来组织数据。在开发健康监测设备时，我们必须严格遵循GATT规范定义心率服务（0x180D）和心率测量特征（0x2A37），否则主流手机APP将无法识别我们的设备。

2. GAP协议深度解析

2.1 设备发现机制

BLE设备通过广播信道（37/38/39）宣告自己的存在。在实际项目中，广播间隔的设置尤为关键：

• 较短间隔（如20ms）能加快发现速度，但会增加功耗
• 较长间隔（如1s）节省电量，但用户可能感觉响应延迟

我曾测试过某款智能手环，当广播间隔设为500ms时，手机平均需要2.3秒发现设备；调整为100ms后，发现时间缩短到0.8秒，但电池续航下降了15%。这种权衡需要根据具体应用场景决定。

广播数据包（Advertising Data）最多可包含31字节，通常包含：

plaintext复制Flags: 0x06 (LE General Discoverable Mode)
Complete Local Name: "MyDevice"
Service UUID: 0x180A (Device Information)
Tx Power Level: 0xC4 (-60 dBm)

2.2 连接建立流程

典型的BLE连接过程如下：

1. 外围设备持续发送广播包
2. 中心设备扫描到广播后发送连接请求
3. 双方协商连接参数（关键！）：
   • 连接间隔（7.5ms~4s）
   • 从机延迟（0~499）
   • 监控超时（100ms~32s）

重要提示：连接参数设置不当会导致频繁断连。某工业传感器项目曾因将监控超时设为最小值（100ms），在信号干扰环境下出现大规模连接不稳定问题。

2.3 安全机制实现

GAP定义了三种安全模式：

1. 模式1：无安全要求
2. 模式2：未加密的数据签名
3. 模式3：带加密的数据签名

在智能门锁开发中，我们采用模式3的LESC（LE Secure Connections）配对方式，配合MITM（中间人防护）保护，有效防止了重放攻击。具体实现时需要注意：

• 必须正确设置IO Capabilities（如DisplayOnly）
• 配对超时应设置在30-60秒范围
• 绑定信息需要安全存储

3. GATT架构与数据模型

3.1 服务与特征定义

GATT采用树状结构组织数据，以下是一个环境监测设备的典型结构：

code复制Device Information Service (0x180A)
├── Manufacturer Name String (0x2A29)
└── Firmware Revision String (0x2A26)

Environmental Sensing Service (0x181A)
├── Temperature (0x2A6E)
│   ├── Value
│   └── Client Characteristic Configuration
└── Humidity (0x2A6F)
    ├── Value
    └── Client Characteristic Configuration

特征属性（Properties）决定了数据访问方式：

• Read：客户端可读取
• Write：客户端可写入
• Notify：服务器可主动通知（无确认）
• Indicate：服务器可主动指示（需确认）

3.2 数据交互模式

在智能灯泡项目中，我们实现了以下典型交互：

1. 客户端发现服务：

cpp复制// 发现主要服务
ble_discover_primary_services(conn_handle, NULL);

2. 订阅温度通知：

cpp复制// 写入CCC描述符
uint8_t ccc_value[2] = {0x01, 0x00}; // 启用通知
ble_write_char_value(conn_handle, ccc_handle, ccc_value, sizeof(ccc_value));

3. 处理通知数据：

cpp复制void on_temp_notification(const uint8_t *data, uint16_t length) {
    float temperature = (data[0] | (data[1]<<8)) / 100.0f;
    printf("Current temp: %.1f°C\n", temperature);
}

3.3 MTU协商优化

ATT_MTU（最大传输单元）默认23字节，实际数据可用仅20字节（3字节头）。通过MTU协商可提升吞吐量：

sequence复制客户端->服务器: Exchange MTU Request (517字节)
服务器->客户端: Exchange MTU Response (247字节)
双方采用较小值: 247字节

实测数据显示，大文件传输时：

• 默认MTU：耗时12.8秒
• 协商后MTU：耗时仅3.2秒

4. 协议协同工作流程

4.1 完整通信示例

以健身手环连接手机为例：

1. 手环（外围设备）广播包含：

   • 设备名称："FitBand Pro"
   • 服务UUID：0x180D（心率）、0x180F（电量）
   • 发射功率：-8dBm

2. 手机（中心设备）：

   • 扫描到广播后显示设备名称
   • 用户点击连接，建立链路
   • 协商连接参数（间隔=15ms，延迟=0）

3. 服务发现阶段：

   • 手机读取设备信息（厂商、固件版本）
   • 发现心率服务及其特征
   • 订阅心率测量通知

4. 数据传输阶段：

   • 手环定期发送心率数据（如55 BPM）
   • 手机接收并显示数据
   • 低电量时手环发送指示（需确认）

4.2 性能优化实践

在开发BLE网关时，我们总结了以下优化技巧：

1. 连接参数调优：

   • 传感器类：间隔40-80ms，延迟3-5
   • 音频类：间隔7.5-15ms，延迟0

2. 广播数据精简：

   • 使用缩短的本地名称
   • 优先包含关键服务UUID
   • 合理设置Tx Power值

3. 服务设计原则：

   • 高频数据特征放在服务顶部
   • 相关特征分组存放
   • 只读/只写特征明确区分

5. 开发实战问题排查

5.1 常见连接问题

5.2 调试技巧分享

1. 使用nRF Connect等工具抓包分析
2. 监控HCI日志查看底层交互
3. 逐步增加服务复杂度排查问题
4. 注意特征权限与属性匹配

某次调试中发现心率数据异常，最终定位是特征属性误设为Write instead of Notify。这个教训让我养成了双重检查属性设置的习惯。

5.3 兼容性处理

不同平台的特殊要求：

• iOS：必须包含设备名称广播
• Android：对MTU支持更灵活
• Windows：需要特定的服务UUID格式

在开发跨平台设备时，我们维护了不同的广播数据模板，通过编译选项切换。例如iOS专用广播包会确保前5字节包含完整设备名称。