蓝牙:ATT和GATT
蓝牙:ATT和GATT
包含低能耗规范的蓝牙 4.0 为标准带来了两个新协议:ATT(属性协议)和 GATT(通用属性配置文件)。它们主要针对低能耗模式,每个 LE 配置文件都应使用它们。但它们也可以在传统蓝牙 (BR/EDR) 上使用。
概述
ATT 是一种有线应用协议,而 GATT 规定了如何在服务组合中使用 ATT。每个低功耗配置文件都必须基于 GATT。因此,最终,每个 LE 服务都使用 ATT 作为应用协议。
将 LE 配置文件绑定到这些协议可带来以下几个优点:
- ATT 针对低功耗设备运行进行了优化:它使用尽可能少的字节,并且实现可以使用内存中的固定大小结构来存储数据包(PDU)。
- ATT/GATT 的简单性和统一性促进了互操作性。ATT 和 GATT 往往在 BT 堆栈内实现,从而减轻了应用程序的低级繁琐工作。
- 作为一个统一而简单的协议,操作系统可以为应用程序提供通用的 ATT/GATT API。
最后一点非常重要。它允许应用程序级配置文件支持。在 经典蓝牙 中,支持新配置文件需要系统升级(对于不太常见的配置文件,这可能永远不会发生)。还有一些设备具有专有或非标准配置文件。无论出于何种原因,许多经典蓝牙设备都诉诸于 SPP(串行端口配置文件),而不是其类别的“正确”配置文件。
现在,让我们深入了解每个协议。
ATT: 属性协议
ATT的唯一构建块是attribute
。attribute由以下元素组成 三个要素:
一个具有唯一标记属性的16bitd的
handle
定义attribute的类型的UUID
一定长度的值
从ATT的角度来看,这个值是无定形的;它是一个字节数组 任何尺寸的。该值的实际含义基于UUID,但是 ATT不检查值长度是否与给定的UUID兼容。
在给定的设备中可能有许多具有相同UUID的attribute
。
ATT本身没有定义任何UUID的含义。这留给GATT或者更高层的配置文件。
ATT服务器存储属性。ATT客户端查询服务器属性。查询是否可以读取和写入属性。
在BLE 4.0中,LE报文的最大传输单元(MTU)只有23字节(似乎在以后的版本中有所增加) 版本)。对于ATT提供的大属性值,较小的MTU根本不是问题 “read long”和”write long”操作来传输大块中的大属性。
ATT是非常非常通用的。就其本身而言,会给高层留下太多空间 要定义的概要文件。我们需要额外的结构来确保服务不会 多业务设备冲突。每个设备只有一个ATT句柄空间,所以 多个服务必须协作共享它。
幸运的是,我们有GATT,它规定了如何使用attribute
。
GATT:通用属性配置文件
GATT是所有顶级LE配置文件的基本配置文件。它定义了 一组ATT属性被组合成有意义的服务。
GATT services
GATT服务的基础是UUID为0x2800的属性。 所有以下属性(即句柄值高于这个值的)属于这个服务,直到另一个属性为0x2800。
例如,具有三个服务的设备可能具有 如下属性布局:
如,具有三个服务的设备可能具有 如下属性布局:
Handle | UUID | Description |
---|---|---|
0x0100 | 0x2800 | Service A definition |
… | … | Service details |
0x0150 | 0x2800 | Service B definition |
… | … | Service details |
0x0300 | 0x2800 | Service C definition |
… | … | Service details |
attribute 本身并不“知道”它属于哪个服务。GATT 需要根据句柄范围来计算,范围是发现的 仅基于UUID 0x2800“基石”。
突然间,句柄值被加载了额外的含义。 在本例中,对于属于服务B的属性,其句柄必须 在0x0151和0x02ff之间。
UUID 0x2800定义了主服务。如果还存在二级服务 (UUID 0x2801),则由主服务包含。