深入解析BLE属性协议：ATT权限与声明机制

1. BLE属性协议（ATT）基础解析

第一次接触BLE开发时，我被一堆术语搞得晕头转向——GATT、ATT、Characteristic、Service...直到真正理解了ATT协议，才发现这些概念原来如此清晰。ATT（Attribute Protocol）就像BLE世界的"快递系统"，它定义了数据如何打包、运输和签收的规则。

想象你有一个智能手环，它每秒都在产生心率数据。这些数据需要传输到手机APP上显示，ATT就是确保这个传输过程可靠有序的底层协议。它采用经典的C/S架构：

• Server：像仓库管理员，存储所有数据属性（比如心率值、电量等）
• Client：像快递员，主动发起请求获取或修改数据

最妙的是ATT的"懒人模式"——当手环的心率数据变化时，Server可以主动通知Client（专业术语叫Notification），避免了手机不断轮询查询的耗电操作。这就像快递员不用每天敲门问"有包裹吗？"，而是等你有了包裹主动打电话叫他来取。

2. ATT权限机制：数据安全的四道门禁

去年给医院做智能体温贴项目时，我们踩过一个坑：患者的体温数据竟然能被隔壁床的手机读取！这才意识到ATT权限配置的重要性。BLE通过四层权限机制构建数据安全防线：

2.1 访问权限（Access Permission）

就像办公室的门禁卡，决定谁能进哪个区域：

#define GATT_PERMIT_READ  0x01  // 只读权限
#define GATT_PERMIT_WRITE 0x02  // 只写权限

实际项目中，体温数据我们配置为只读，防止被恶意篡改；而报警阈值参数则开放读写，让护士可以调整。

2.2 加密权限（Encryption Permission）

数据传送时的"保险箱"：

#define GATT_PERMIT_ENCRYPT_READ  0x40  // 读取需加密
#define GATT_PERMIT_ENCRYPT_WRITE 0x80  // 写入需加密

医疗设备必须开启加密，否则BLE数据包可能被嗅探工具截获。实测用nRF Connect扫描，未加密的数据就像明信片一样一目了然。

2.3 认证权限（Authentication Permission）

相当于"人脸识别"门禁：

#define GATT_PERMIT_AUTHEN_READ  0x04  // 读取需认证
#define GATT_PERMIT_AUTHEN_WRITE 0x08  // 写入需认证  

认证失败时，CH57X芯片会返回0x0105错误码（Insufficient Authentication）。曾有个Bug：iOS设备配对后仍提示认证失败，最后发现是没正确处理LE Secure Connection配对流程。

2.4 授权权限（Authorization Permission）

最高级别的"双重验证"：

#define GATT_PERMIT_AUTHOR_READ  0x10  // 读取需授权
#define GATT_PERMIT_AUTHOR_WRITE 0x20  // 写入需授权

银行级应用会用到这个权限，比如修改转账限额时需要二次密码确认。在BLE中，授权通常在应用层通过回调函数实现。

实际开发中，权限常组合使用。比如智能门锁的密码特征：

permissions = GATT_PERMIT_ENCRYPT_WRITE | GATT_PERMIT_AUTHEN_WRITE

这样既保证传输安全，又确保只有配对过的设备能操作。

3. 属性声明机制：BLE的数据结构设计

如果把ATT属性比作Excel表格，那么声明机制就是定义这个表格的"表头"。每个属性包含四个关键字段：

字段名	长度	说明
Attribute Handle	2字节	类似行号，0x0001-0xFFFF。CH57X中句柄自动分配，从0x0001开始递增
Attribute Type	2/16字节	用UUID标识类型。0x2800-0x2803是服务声明专用UUID
Attribute Value	0-512字节	实际数据。比如心率服务的值是"55 bpm"
Attribute Permissions	1字节	前文介绍的权限组合

最近做智能水杯项目时，GATT数据库是这样构建的：

// 温度特征声明
{0x0002, 0x2803, PERM_READ, sizeof(temp_char), &temp_char_props},
// 温度特征值  
{0x0003, 0x2A6E, PERM_READ|PERM_NOTIFY, sizeof(temp_value), temp_data},
// CCC描述符
{0x0004, 0x2902, PERM_READ|PERM_WRITE, sizeof(ccc_value), ccc_data}

这里有个坑：特征声明(0x2803)必须紧跟着特征值(0x2A6E)，否则手机端会报"Invalid Attribute Order"错误。

4. 典型应用场景分析

4.1 智能穿戴设备数据交互

以华为手环为例，其GATT服务结构如下：

- 心率服务 (0x180D)
  - 心率测量特征 (0x2A37) [Notify]
  - 心率位置特征 (0x2A38) [Read]
- 电池服务 (0x180F)  
  - 电量特征 (0x2A19) [Read,Notify]

关键点在于：

1. 心率数据配置为Notify权限，实现后台持续上报
2. 电量同时支持Read和Notify，既允许主动查询，也支持低电量预警
3. 所有特征启用加密权限，符合GDPR隐私要求

4.2 不同协议栈实现对比

在CH57X和nRF52832上的权限处理差异：

功能点	CH57X实现	nRF52实现
权限校验时机	ATT层直接拦截非法请求	GATT层进行二次校验
错误码返回	立即返回0x0105等标准错误码	可能先返回0x00再触发应用层回调
加密处理	硬件AES加速	软件加密（消耗更多CPU资源）

实测CH57X的权限检查耗时约20μs，而nRF52需要50μs。但在动态权限修改方面，nRF52的softdevice架构更灵活。

5. 开发实战技巧

5.1 权限配置黄金法则

1. 最小权限原则：如无必要，勿增权限。曾有个智能秤因为开放了Write权限被黑客改了校准参数。
2. 通知类特征：务必配置Write权限给CCC描述符，否则客户端无法订阅通知。
3. 权限动态调整：像共享单车锁，未开锁时只读，开锁后临时开放Write权限。

5.2 调试技巧

• 使用Wireshark抓包时，注意观察ATT协议的Opcode字段：
  • 0x01: Read Request
  • 0x12: Write Command
  • 0x1B: Handle Value Notification
• 权限错误会返回Error Response PDU，常见错误码：
  • 0x0102: Read Not Permitted
  • 0x0105: Insufficient Authentication

5.3 内存优化

对于RAM有限的MCU（如STM32F103），可以：

__attribute__((section(".ccmram"))) 
static uint8_t att_db[512]; // 将属性表放在CCM高速内存区

这样处理ATT请求时能减少总线冲突。实测在72MHz主频下，响应速度提升约15%。

6. 前沿发展

BLE 5.3引入了Enhanced ATT协议，主要改进：

1. 支持大于512字节的长属性（需分段传输）
2. 新增Signed Write Command，防篡改
3. 改进错误处理机制，新增0x07错误码（Invalid PDU）

在最新的医疗设备规范中，要求必须使用LE Secure Connection + Authorization权限组合，确保患者数据万无一失。这就像从普通门锁升级到了指纹+密码+虹膜的三重验证。