1. GATT 协议栈分层与特征数据结构

GATT（Generic Attribute Profile）是 BLE 协议栈中定义数据交互规则的最高层。它并不负责物理传输，而是建立在一个名为 ATT（Attribute Protocol）的底层协议之上，将设备间的通信抽象为对“属性”的查找、读、写与通知。本章聚焦 GATT 在协议栈中的位置、特征（Characteristic）如何被声明、属性表（Attribute Table）的构成方式以及句柄（Handle）与属性之间的映射关系。

1.1 BLE 协议栈中的 GATT 层职责

BLE 协议栈自底向上分为：

GATT 的核心职责可归纳为三点：

1. 层次化建模：将数据组织成 Service → Characteristic → Descriptor 三层的树形结构。
2. 属性类型注册：每一个暴露给对端的数据单元都必须以固定格式在属性表中注册。
3. 访问控制：依据属性权限（读/写/通知/指示）决定哪些 ATT 操作被允许。

1.2 特征声明与属性表结构

在 GATT 属性表中，一个 Characteristic 并非单个属性，而是由三个连续的属性条目构成：

属性表在固件中的典型表示方式如下（以 Zephyr 为例）：

// 定义自定义特征声明
struct bt_gatt_attr my_attrs[] = {
    BT_GATT_PRIMARY_SERVICE(&my_service_uuid),      // 主服务声明
    BT_GATT_CHARACTERISTIC(&my_char_uuid,            // 特征声明
                           BT_GATT_CHRC_READ |
                           BT_GATT_CHRC_NOTIFY,
                           BT_GATT_PERM_READ,        // 特征值权限
                           read_my_char,             // 读回调
                           NULL,                     // 写回调（无需写）
                           &my_char_value),          // 特征值缓冲区
    BT_GATT_CCC(my_ccc_changed,                     // CCCD 配置变化回调
                BT_GATT_PERM_READ | BT_GATT_PERM_WRITE),
};

上述代码对应的属性表布局为 5 个条目，其中特征值属性（my_char_value）存储在 RAM 中，对端通过 ATT 读请求直接读取该内存区域。

1.3 句柄映射关系

句柄是 GATT 属性表中每个条目的 16 位逻辑地址，范围 0x0001 ~ 0xFFFF。连接建立后，GATT 客户端通过句柄来定位目标属性。句柄的分配遵循以下规则：

• 递增性：句柄按照属性表中的顺序从 1 开始递增，不允许跳跃或重复。
• 连续性：同一特征的三条属性（声明 + 值 + 描述符）句柄必须连续。
• 分组性：服务的句柄范围由服务声明属性及其包含的所有子属性构成一个闭区间（start_handle ~ end_handle）。

句柄映射的一个实际例子（针对上述 Zephyr 代码）：

• 句柄 0x0001 —— 主服务声明（UUID = my_service_uuid）
• 句柄 0x0002 —— 特征声明（UUID = 0x2803，值中存储特征句柄 0x0003 和我方特征 UUID）
• 句柄 0x0003 —— 特征值（UUID = my_char_uuid）
• 句柄 0x0004 —— CCCD（UUID = 0x2902）

对端执行 Service Discovery 时，会发 Read By Group Type 按组获取服务；再对每个服务执行 Read By Type（UUID=0x2803）得到特征声明的句柄列表，进而通过特征声明中携带的 特征值句柄 字段直接定位到数据属性。

下面使用一张结构图完整展示 GATT 属性表、特征三元组与句柄映射的关系。

1.4 常见错误与调试方法

在实际嵌入式开发中，GATT 属性表配置错误是导致连接后无法发现服务或读写失败的主要原因。