Bluetooth profile: ATT/GATT
Bluetooth profile: ATT/GATT
因为看了这篇英文文档介绍Bluetooth ATT/GATT很详细，所以翻译了一下，供参考！
蓝牙4.0版本推出了低功耗规范，引入了两个核心协议：ATT（Attribute Protocol）和GATT（Generic Attribute Protocol）.这两个协议主要目标是BLE，但是也可以运行在传统蓝牙上（BR/EDR).
ATT是wire application protocol（无线应用层连接协议？），GATT基于ATT协议。所有的BLE profile一定基于GATT。也就是所有的BLE服务都使用ATT作为应用协议。
锁定BLE使用这两个协议的好处是：
1，开发和实现新的BLE profile更加容易，因为不需要从头实现wire protocol。
2，ATT针对BLE 设备进行了特别的优化：使用尽可能少的字节，因此可能在存储中使用定长结构来生成PDU。
3，ATT/GATT的简单意味着固件可能提供某种程度的协议支持，省去了微处理器软件的麻烦。
4，对于软件实现的协议栈来说，ATT/GATT在协议栈里实现，省去了应用的麻烦。
5，即使有的场景下，ATT/GATT不够理想。也可以在L2CAP连接上实现平行于ATTchannel的协议。
ATT: Attribute Protocol
ATT协议的唯一基础是属性。每个属性由三个元素构成：
1，一个16bit handle；
2，一个UUID来定义属性的类型；
3，确定长度的属性值
在ATT中，属性值可以是任意长度的byte数组。属性值的实际意义依赖于UUID，而且ATT并不会检查属性值长度是否与给定的UUID定义一致。
Handle是用来唯一识别属性的数字，因为在一个BLE 设备中可能存在多个属性具有相同的UUID。
ATT协议本身没有定义任何UUID。这部分工作留给了GATT和上层协议。
ATT server存储属性。ATT client什么也不存储，它使用ATT协议来读写server端的属性。
和属性相关的还有读写权限。读写权限存在属性值里，由高层协议确定。ATT本身不会关心，也不会试图解释属性值来确定权限。这部分工作也留给了GATT和上层协议。
ATT有一些良好的特征，比如通过UUID来搜索属性，通过handle区间范围来获取所有区间内的属性，因此client不需要提前获得handle的值，也不需要高层协议硬编码这些值。
但是在特定的设备上handle的取值最好保持不变，这样的话client能够缓冲信息。在第一个discovery以后，client能够使用缓冲信息，这样能够减少传输的包数量，也能够节约能量。如果服务端的属性布局已经发生了变换，高层协议应该能够&暗示&client，比如固件升级。
大多数情况下ATT协议都是纯C/S架构，client发起请求，server响应。但是服务端也有通知的能力，在服务端属性发生变化时，server能够通知client，这样避免了client不停的poll。
ATT协议不会显式发送属性值的长度，只能从PDU长度里面获得。因此client最好能够知道某种UUID类型所代表的属性的精确结构。
不发送属性值长度，是为了减少发送的字节，因为LE的MTU只有23bytes。
23bytes的MTU对于较长的属性值来说是个麻烦。因此不得采用&read long&,&write long&这样的操作。
ATT是如此通用，意味着高层协议有太多工作要做。过度的自由也会带来问题，比如：如果一个设备提供多个服务怎么办？对每一个设备只有一个ATT handle空间，多个服务不得不共享同一份空间。
幸运地是，我们还有GATT，它为我们提供了属性用法，并解除了这些限制。
GATT:Generic Attribute Profile
GATT是所有LE顶层协议的基础。它定义了怎么把一堆ATT属性分组成为有意义的服务。
GATT services
GATT service的基础是UUID值为0x2800的属性。所有跟在这个属性后面的属性都属于这个属性定义的服务，直到另一个0x2800属性出现。
比如说，一个设备里面的三个属性布局如下：
Description
Service A definition
Service details
Service B definition
Service details
Service C definition
Service details
每一个属性不知道它自己属于哪个服务，GATT需要根据0x2800属性作为标记来识别出哪个属性属于哪个服务。
按照这个定义，handle值就有意义了。在上面的例子中，属于service B的属性handle必须位于0xff之间。
UUID 0x2800定义了primary服务，
也可以使用0x2801来定义secondary服务。
Secondary服务表示包含于primary服务。
然后我们怎么能知道一个服务是温度计，智能钥匙或者GPS？答案是通过读取属性值。服务属值包含了一个UUID，通过这个UUID区分服务。
因此，每个属性定义事实上包含了两个UUID，0x2800或者0x2801作为属性UUID，另外一个属性值里面存储的UUID。后面这个UUID是服务ID。
举个例子：
Description
Thermometer service definition
UUID 0x1816
Service details
Service B definition
Service details
Service C definition
Service details
在图中，thermometer service的UUID是0x1816。
是不是感觉怪怪的？两个UUID定义一个服务？这是GATT/ATT分层方式导致的后果。
UUID0x2800被GATT用来寻找服务定义边界。一旦找到了边界，属性值，也就是第二个UUID用来指定服务。这样client能够找到所有的服务而不需要知道服务的具体定义。
GATT service characteristics
每一个服务有几个特征。特征存储了有用的值以及权限。
比如，一个温度计可能有只读的温度特征，也可能有可读写的时间戳。
Description
Thermometer service definition
UUID 0x1816
Characteristic: temperature
UUID 0x2A2B
Value handle: 0x0102
Temperature value
20 degrees
Characteristic: date/time
UUID 0x2A08
Value handle: 0x0111
每一个服务可能有几个特征，这些特征也是通过路碑属性来发现的。
主特征的UUID是0x2803，然后主特征的属性值用来定义特征。比如图中 0x2803用来找到特征，0x2A2B用来找到特征包含的信息。
每一个特征至少包含两个属性，主属性0x2803和真正的值属性。主属性知道属性值的handle和UUID。这能够进行一定程度的交叉检测。
特征值的真正格式是由UUID决定的。因此，如果客户端知道如何解释UUID为 0x2A08的特征值，就能够从包含这个特征任何服务里面读取日期和时间。当然如果客户端不知道如何解释这个UUID的话，也可以选择忽略。
Characteristic descriptors
除了特征值，我们也可以为每个特征增加更多的属性。在GATT语法里，这个额外的属性成为描述符。
举个例子子，我们也许需要指定温度的计量单位。
Description
Thermometer service definition
UUID 0x1816
Characteristic: temperature
UUID 0x2A2B
Value handle: 0x0102
Temperature value
20 degrees
Descriptor: unit
Characteristic: date/time
UUID 0x2A08
Value handle: 0x0111
GATT知道handle 0x0104是特征0x0101的描述符，因为：
1，他不是特征的值，因为特征值的handle应该是0x0102
2，他的handle落在了0xf之间，因此也不属于下一个特征。
描述符值的意义依赖于属性UUID。例子中，描述符的UUID是0x2A1F，客户端如果不能识别这个UUId，他可以选择忽略。这样可以实现向下兼容。
每个服务可能定义自己的描述符，但是GATT已经定义了能够覆盖大多数情况的标准描述符，比如：
数值格式和表示；
人类可读的描述；
合理范围扩展属性等等。其中特别重要的描述符是client characteristic configuration。
Client Characteristic Configurationdescriptor
Client Characteristic Configurationdescriptor的UUID是0x2902，具有一个16bit的可读写值，作为一个bitmap来使用。
这个属性被server用来存储和代表每个已经绑定的client的独立实例，每个client只能看到它自己的拷贝。
前两个bit被GATT用来定义通知和暗示。其他bit暂时未使用。
通过设置CCC，client能够让server在特征发生改变时得到通知。比如包含了CCC的属性布局如下：
Description
Thermometer service definition
UUID 0x1816
Characteristic: temperature
UUID 0x2A2B
Value handle: 0x0102
Temperature value
20 degrees
Descriptor: unit
Client characteristic configuration descriptor
Characteristic: date/time
UUID 0x2A08
Value handle: 0x0111
Servicediscovery in Low Energy
因为GATT中所有的服务细节通过ATT来描述，所以不需要像BR/EDR那样设置专门的服务发现协议。ATT负责一切：发现服务，查找特征，读写值等等。
GATT andvanilla Bluetooth
GATT也可以工作在传统蓝牙上面，但是规范规定传统蓝牙仍然使用SDP发送服务，即使通过GATT来进行实际数据交换。
这样的好处是在双模设备上不用设置标识来识别LE-only服务。如果一个服务只能通过GATT发现，就是LE-only。如果能够通过GATT和SDP发现，就是双模。
如果一个profile通过GATT来进行数据交换，并且是双模的，它必须首先发布SDP record。然后这个服务通过SDP来发现，然后通过GATT来查找特征。
当然，现在没有双模的profile。以前的profile是BR/EDR only,并且没有适配到GATT；LE-only只有LE。
如果想要测试GATT而没有LE硬件，可以修改蓝牙协议栈来使BR/EDR可以进行GATT discovery。这是规范不运行的，但是开发者可以。
Notificationsversus connections
通知和暗示使得server可以发送消息给client。这样客户端不需要pollserver来获取新的数据。
另外，典型的GATT server是&小的&外设，像非常需要节能的传感器之类。因此，外设的LE 设备不能发起连接。那么通知怎么发送呢？
在BLE协议栈，如果server有数据发送，它就进入广播模式，并且发送一些信号。每个profile定义了广播时长和频率。时长和频率应该根据使用场景进行了节能和及时性的权衡。
处于中心模式的设备随时处于监听模式。当它监听到广播后，如果发现广播设备是认识的（配对过或者白名单中的），就会向外设发起连接。
连接建立以后，GATT通信能够进行，通知得以发送。所以典型的序列是：1，server发送广播 2，client连接 3server通知
如果没有更多的数据发送，server和client就会超时断开。最佳超时时间依赖于用例；如果服务不会频繁发送通知并且没有实时性要求的话，可以立马断开。因为BLE重连是非常快的。
典型的GATT server是外设设备，但是不是必须的。也可以外设做client，center做server。在这种场景下，client想要读写数据的时候，需要先进入广播模式。蓝牙 SIG 服务描述 - 简书
蓝牙 SIG 服务描述
因为项目需要区别扫描到的设备，一直没有找到合适的方法。不过苹果 sdk 给出了一个 关于 service 和 Characteristics 的描述：
The services and characteristics of a peripheral are identified by 128-bit Bluetooth-specific UUIDs, which are represented in the Core Bluetooth framework by CBUUID objects. Though not all UUIDs that identify a service or characteristic are predefined by the Bluetooth Special Interest Group (SIG), Bluetooth SIG has defined and published a number of commonly used UUIDs that have been shortened to 16-bits for convenience. For example, Bluetooth SIG has predefined the 16-bit UUID that identifies a heart rate service as 180D. This UUID is shortened from its equivalent 128-bit UUID, 00-805F9B34FB, which is based on the Bluetooth base UUID that is defined in the Bluetooth 4.0 specification, Volume 3, Part F, Section 3.2.1.
The CBUUID class provides factory methods that make it much easier to deal with long UUIDs when developing your app. For example, instead of passing around the string representation of the heart rate service’s 128-bit UUID in your code, you can simply use the UUIDWithString method to create a CBUUID object from the service’s predefined 16-bit UUID, like this:
大概意思是 SIG 这个组织 预先定义了一套 常用 UUID。如果蓝牙厂商遵循这个规范，则可以根据这些 UUID 判断出来需要的服务。 SIG 地址：
二、 蓝牙 服务描述
写几个常见的：
自动化输入输出
org.bluetooth.service.automation_io
org.bluetooth.service.device_information
org.bluetooth.service.heart_rate
org.bluetooth.service.indoor_positioning
org.bluetooth.service.object_transfer
三、特征描述
org.bluetooth.characteristic.gap.device_name
序列号字符串
org.bluetooth.characteristic.serial_number_string
软件修订字符串
org.bluetooth.characteristic.software_revision_string
四、服务发现
在服务发现协议（SDP）中使用分配编号，搜索服务、浏览群组列表、文件URL和图标URL。
服务发现协议（SDP）
通用唯一标识符（UUID）简短格式
蓝牙（Bluetooth(R)）服务发现协议（SDP）规格定义了以简短格式代表一系列UUID（名义上为128位）的方式。232个值的保留范围可使用32位（以uuid32表示）代表。其中，216个值的子范围可仅采用16位（以uuid16表示）代表。
本文件中未分配的232范围的所有值予以保留，以待本文件日后的版本处理。换言之，此范围的值不可使用，除本文件或其日后版本规定。此范围以外的UUID值可按[ISO-11578]所述分配作分配者希望用作的任何目的。
基本通用唯一标识符（UUID）
基本UUID用语计算用作计算SDP规格所述“简短UUID”（uuid16和uuid32）的128位UUID。请参阅蓝牙核心规格的服务发现协议（SDP）。
1、#####协议标识符
下表的UUID应仅用于ProfileDescriptorList属性中。
HardcopyControlChannel
硬拷贝替换配置文件 (HCRP)
序列号字符串
org.bluetooth.characteristic.serial_number_string
软件修订字符串
org.bluetooth.characteristic.software_revision_string
下表允许使用服务的UUID，可用于ServiceClassIDList通用属性，但不可用于BluetoothProfileDescriptorList属性，除非下表允许使用配置文件。如果服务类UUID用于产品的SDP数据库，那么包含SDP记录的产品应遵循界定了与UUID相对应的服务的规格。
下表允许使用配置文件的UUID可用于BluetoothProfileDescriptorList通用属性，但不可用于ServiceClassIDList通用属性，除非下表允许使用服务类。
因历史原因，表2的部分UUID用于识别BluetoothProfileDescriptorList通用属性中的配置文件及ServiceClassIDList通用属性的服务类。然而，对于新的配置文件，服务类UUID不可用于BluetoothProfileDescriptorList通用属性，而配置文件UUID不得用于ServiceClassIDList通用属性。
服务类名称
SerialPort
串口配置文件 (SPP)附注：SPP 1.0版中的SDP记录样例不包括BluetoothProfileDescriptorList属性，但部分实施也可使用此UUID作为配置文件标识符。
服务类/ 配置文件
耳机配置文件 (HSP)附注：同时用作服务类标识符和配置文件标识符。
服务类/ 配置文件
AudioSource
高级音频分发配置文件 (A2DP)
对讲机配置文件 (ICP)附注：同时用作服务类标识符和配置文件标识符。[已作废]
传真配置文件 (FAX)附注：同时用作服务类标识符和配置文件标识符。[已作废]
DirectPrinting
基本打印配置文件 (BPP)
ReferencePrinting
参见基本打印配置文件 (BPP)
五、缩写词及核心规格名称
高级音频分发配置文件
基本打印配置文件件
设备信息服务
指定缩写词和规格名词
高级音频分发配置文件
基本打印配置文件件
设备信息服务
六、GATT描述符
既Descriptors，
客户端特征配置
org.bluetooth.descriptor.gatt.client_characteristic_configuration
Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。他们将在任何分布式...
国家电网公司企业标准（Q/GDW）- 面向对象的用电信息数据交换协议 - 报批稿： 前言： 排版 by Dr_Ting公众号：庭说移步 tingtalk.me 获得更友好的阅读体验 Q/GDW XXXX-201X《面向对象的用电信息数据交换协议》是根据《国家...
Spring Boot 参考指南 介绍 转载自:/book/qbgbook/spring-boot-reference-guide-zh/details带目录浏览地址:/sprin...
安卓4.3(API 18)为BLE的核心功能提供平台支持和API，App可以利用它来发现设备、查询服务和读写特性。相比传统的蓝牙，BLE更显著的特点是低功耗。这一优点使android App可以与具有低功耗要求的BLE设备通信，如近距离传感器、心脏速率监视器、健身设备等。 ...
Key Terms And Concepts 关键术语和概念 Here is a summary of key BLE terms and concepts:以下是关于BLE的关键术语和概念的摘要 Generic Attribute Profile (GATT)—The G...
01 宁缺勿滥，寻找真正的Mr right ！这是我的爱情信条。 看完三生三世十里桃花，特别喜欢白凤九。因为，我和她一样，认定一个人，就是一辈子的事情。可惜，我没她那么漂亮！她是九儿，我是小艾。也许，在这个网络情缘盛行的年代，这样的人寥寥无几了。 02 从来没有想过要尝试爱...
翻译自：Faster Logins With Password AutoFill in iOS 11 iOS11 中的 Password AutoFill 有账户功能的App通常需要先登录来获取个人信息。如果用户记得他们的账号密码，通过输入登录，一般需要花费几秒钟时间；否则...
因为之前手机内存太满操作太卡，所以进行了一系列的清理删除，没想到这竟是根本上的彻底删除，把我手机里原有的歌单、图片、音频、表情包什么的全删没了！啊啊啊啊……好心疼好心痛呀，一切都已不复存在！我先冷静会儿(?_?)
首先，什么是熟女？ “熟女”一词从日本传播界流传过来的词汇，现在泛指30岁-50岁的成熟女人。但不是所有成熟的女人都是熟女，我们这里要说的熟女不仅仅是性成熟。真正的熟女应该拥有丰富的人生阅历，有内涵，气质优雅，自爱自信，懂得体贴和关怀。 这是一个“熟女”可以打败“小美眉”的...
好久不见，句号(与自然为伍)
(与自然为伍)
(与自然为伍)
(与自然为伍)
(与自然为伍)
第三方登录：}