目录

GATT OverView

service 定义

include 定义

characteristic 定义

HCI log 分析： GATT discover service flow

GATT 是ble 的另一个基本协议，总结了gatt 一些定义，最后通过一份hci log，说明一下GATT在实际应用中如何运作。

两年前初次接触ble 就是从GATT spec 开始入手学习，工作中更多的是下沉到bludroid stack 维护工作中，GATT基础知识通过整理blog，加深了自己的理解。凭着自己的工作经验，总结了GATT部分核心内容，可能仍有些许遗漏。

欢迎有兴趣的朋友留言，有描述不清或者有错误的地方，也欢迎指正

GATT OverView

Gatt 是在ATT基础上的封装，定义了一些服务发现的框架。

整体框架图如上， GATT DataBase主要分为三个部分，service，include，characteristic，首先围绕这三个分别作介绍

service 定义

类型： 服务有两种类型，primary service 和secondary service，

primary service可以被其他service 所包含，可以通过discover 流程发现。

secondary service只能被primary service 或者其他secondary service 所包含，不能独立存在。

一个服务的类型，会在申明中注明。

组成：gatt 数据框架都是有一个或者多个service 并列组成的。

用户通过定义不同的service，实现不同的功能。

一系列ATT数据组成一个group，表示一个service。

所有的service都必须满足相同的数据要求，具体分为三个部分

1. 服务申明（必须）service

2. 包含其他服务（可选）

3. 必须的特征和可选择的特征、

红色部分为一个服务必须包含的部分，蓝色为可选择的部分。

服务申明： 每个定义的service第一条就是服务申明，因此以服务申明可以分隔开所有不同的服务。

服务声明的数据结构，ATT类型（仅有两种）+ ATT value（服务的具体类型，比如电量服务，GAP服务等等）

服务声明为read only，不可以被修改，有server 端在自定义数据表格的时候确定。

申明之后，紧跟include 和 characteristic部分。

include 定义

include 是解释服务之间的关系，secondary service只能被primary service 或者其他secondary service 所包含，不能独立存在。

include 是service 中可选择的部分，不强制要求必须有这一部分。

同服务一个样，include 也是从declaration 开始。

一条ATT仅包含一个include 信息。

include 申明格式：

ATT value：包含的服务handle 是该服务对应的申明， service UUID 是指该服务的类型

通过include 申明，可以查到包含服务的开始handle和结束handle，及服务类型三个信息

该申明也是read only，不可以被修改

characteristic 定义

特征必须要有申明和值申明，可能含有特征描述申明。

同服务一样，相邻的所有特征都是通过申明ATT 间隔开的。一个特征的结束handle 一定是下一个特征的申明handle

特征申明：

同服务申明格式一致，指出实际value对应的handle，及类型（uuid），方便解析

每一个申明都有属性，决定value 可以被操作的方法。

特征属性详解：

broadcast：如果被设置，允许特征值被广播，config descriptor 一定存在

read：如果被设置，可以通过Read ATT相关操作访问特征值

write with respondse：如果被设置，可以通过 Write Request 更改特征值

Notify：如果被设置，特征值可以通过notify 方式通过server 发送到client，config descriptor 一定存在，控制notify发送开关

Indicate：如果被设置，特征值可以通过indicate，从server 发送到client，config descriptor 一定存在，控制indicate 状态开关

Authenticated Singend write：如果被设置，仅能通过signed write的方式去更改特征值

extended propertyies：如果被设置，表明改特征值必然存在一个extended properities descriptor，属性值配置过长，有一些补充的属性配置在descriptor中

特征值申明：

主要包含两个信息：characteristic type（uuid）和value

此处的uuid 与特征申明中，uuid 一样，都是指特征值的uuid

任何特征都必须包含这一项

这一项可以通过属性定义的方法，被访问或操作

特征描述申明：

特征描述是特征的可选项

SIG定义了一些跟特征相关的可用描述，描述有对应的uuid

所有的特征描述紧紧跟着特征值申明之后的ATT handle

扩展属性描述：

可信任写：可以在一个操作中，通过pre write request，按照顺序，依次write 多个att handle，然后最后一次性写入。

Writable Auxiliaries：可写user descriptor，如果这个bit 被置位，可以更改特征中的user 描述内容。

当前仅有两个内容在扩展属性中，后续可能会更新更多

client config 描述:

包含notify 和 indicate的开关

能够被client 配置的描述，比如RC 配置server 端的按键属性

其他位保留

每一个client都有与之对应的一个config，配置client config 仅仅会影响到当前配置的client

server config 描述

包含着发送广播的配置开关

一旦这个config 被设置，会向所有的client 发送广播包

这个值被设置，会在server 端具备发广播的能力的时候，将特征值通过广播发送出去。进入start advertise 阶段，会被自动发送出去。

另外一些其他的特征描述，可以查阅spec ，在这不做一一介绍。

HCI log 分析： GATT discover service flow

ATT数据表是定义在server端的一组数据，在设备初次配对，client 会通过gatt service discover 步骤，获取到client 所持有的ATT 数据表。

GATT 详细定义了discover service 步骤，每一步均是通过handle 实现对ATT数据的操作，逐步获取所有的数据表。

1. 找到所有的primary service

在并不知道DB 中包含有多少个service 的时候，先用priimary service 过滤条件，控制搜索结果的数量

整体上快速定位目标primary service 的起始和结束handle 划分。

第一次read by group type request，会将区间设置为最小值1 到最大值0xffff

然后根据返回结果，不断缩小搜索范围，直至error response 或者到达最大值，表示全部搜索结束。

通过第一轮操作，可以整体上把所有primary service 找到，对应的列表如下：

handle 区间：

1-4 GAP service

5-15 GAP service

25-28 电量 service

29-50 HID service

51-56 自定义服务1

57-59 自定义服务2

60-63 自定义服务3

2.逐个找到所有服务中的include 和特征值

经过第一步，仅仅大概确认了每个primary service的区间分布。

ATT handle 都是依次排列，可以确认handle 15--25 之间，可能是secondary service，或者handle 50 之后仍然有secondary service 仍然没有被发现。

但是通过查找primary service 中的include 信息，可以找到第一步中没有被发现的secondary service.

在这一步中首先使用read by type ，快速找到service 区间内的inclued 申明和characteristic 申明。

由于ATT handle 的连续性，找到申明之后，后续的的值及描述都会被一一确认。

找到特征申明之后，通过find infomation request可以查到characteristic 对应的所有handle

所有的搜索，会不断缩小范围，直到所有联系的handle 都被确认

一一解析hci log 可以得到如下的完整数据分布：

Gatt service 列表数据表
handle	service 申明	characteristic 申明	characteristic value	characteristic descriptor
1	GAP service
2		service change，value：3
3			uuid:service change; value: ; propertis: indicate permite
4				client config descriptor
5	GAP service
6		uuid：device name; value: 7
7			uuid:device name; value: ; propertis:
8		uuid：apperence; value: 9
9			uuid:apperence; value: ; propertis:
10		uuid：Perpherial preferred connection paramterts; value: 11
11			uuid:Perpherial preferred connection paramterts; value: ; propertis:
12		uuid：peripheral privacy flag; value: 13
13			uuid:peripheral privacy flag; value: ; propertis:
14		uuid：Reconnect address; value: 15
15			uuid:Reconnect address; value: ; propertis:
16
17		uuid：Manufacture Name; value: 18
18			uuid:Manufacture Name; value: ; propertis:
19		uuid：Hardware Revision; value: 20
20			uuid:Hardware Revision; value: ; propertis:
21		uuid：System ID; value: 22
22			uuid:System ID; value: ; propertis:
23		uuid：PNP ID; value: 24
24			uuid:PNP ID; value: ; propertis:
25	电量 service
26		uuid：battery level; value: 27
27			uuid:battery level; value: ; propertis:
28				uuid:client config descriptor
29	HID service
30		uuid：report map; value: 31
31			uuid:report map; value: ; propertis:
32		uuid：HID information; value: 33
33			uuid:HID information; value: ; propertis:
34		uuid：HID Control Point; value: 35
35			uuid:HID Control Point; value: ; propertis:
36		uuid：HID report; value: 37
37			uuid:HID report; value: ; propertis:
38				uuid:report reference descriptor;
39				uuid:client config descriptor;
40		uuid：HID report; value: 41
41			uuid:HID report; value: ; propertis:
42				uuid:client config descriptor;
43				uuid:client config descriptor;
44		uuid：HID report; value: 45
45			uuid:HID report; value: ; propertis:
46				uuid:report reference descriptor;
47				uuid:client config descriptor;
48		uuid：HID report; value: 49
49			uuid:HID report; value: ; propertis:
50				uuid:client config descriptor;
51
..........
自定义

51-56 自定义服务1

57-59 自定义服务2

60-63 自定义服务3

handle 16 是secondary service 申明，暂未做解析

至此，GATT service discover 结束，所有handle的信息，均被被client 端知晓。

ble - GATT 协议详解相关推荐

android ble蓝牙接收不到数据_Android蓝牙4.0 Ble读写数据详解 -2
Android蓝牙4.0 Ble读写数据详解 -2 上一篇说了如何扫描与链接蓝牙这篇文章讲讲与蓝牙的数据传输,与一些踩到的坑. 先介绍一款调试工具,专门调试Ble蓝牙的app.名字叫:nRF-Con ...
HTTP协议详解（真的很经典）
转自:http://blog.csdn.net/gueter/archive/2007/03/08/1524447.aspx Author :Jeffrey 引言 HTTP是一个属于应用层的面向对象的 ...
Http 协议详解笔记
HTTP是一个属于应用层的面向对象的协议,由于其简捷.快速的方式,适用于分布式超媒体信息系统.它于1990年提出,经过几年的使用与发展,得到不断地完善和扩展.目前在WWW中使用的是HTTP/1.0的第 ...
Http协议详解（转载）
http://blog.csdn.net/gueter/archive/2007/03/08/1524447.aspx 引言 HTTP是一个属于应用层的面向对象的协议,由于其简捷.快速的方式,适用于分 ...
ARP协议详解之ARP动态与静态条目的生命周期
ARP协议详解之ARP动态与静态条目的生命周期 ARP动态条目的生命周期动态条目随时间推移自动添加和删除. q 每个动态ARP缓存条目默认的生命周期是两分钟.当超过两分钟,该条目会被删掉.所以,生 ...
ARP缓存表的构成ARP协议全面实战协议详解、攻击与防御
ARP缓存表的构成ARP协议全面实战协议详解.攻击与防御 1.4.3 ARP缓存表的构成在局域网的任何一台主机中,都有一个ARP缓存表.该缓存表中保存中多个ARP条目.每个ARP条目都是由一个IP ...
HTTP协议详解转自小坦克
HTTP协议详解转自小坦克 -- 有些文章是引用别人的,为了方便我以后或不再备注;引用目的是因为直接网摘里面的地址经常被重置,找不到原来的文章当今web程序的开发技术真是百家争鸣,ASP.NET, ...
nbns协议_网络协议详解1 - NBNS
NetBIOS 简介 NetBIOS,Network Basic Input/Output System的缩写,一般指用于局域网通信的一套API,相关RFC文档包括 RFC 1001, RFC 100 ...
转:SSL 握手协议详解
SSL 握手协议详解 RSA作为身份认证,ECDHE来交换加密密钥,AES/DES等作为加密. 如果RSA来加解密,那么身份认证后,直接用认证后的RSA公钥解密.不需要再额外交换加密密钥了. 相关报文 ...

ble - GATT 协议详解