蓝牙开发那些事儿（10）——初识BLE

其实LE和BR/EDR完全是两种不同的东西，物理层的channel数减少了一半，AFH调频算法有了新的改进，

应用场景也不同，LE主要是应用于物联网，所以从设计上来讲，有以下考虑：

1. 功耗低，数据量少，基于这个考虑，和传统蓝牙不同的是，很多场景下，BLE并不依赖于有连接的方式，无连接的方式具备功耗低，使用时间更长的优点，比如BLE的beacon技术就是一个设备定时发非连接广播包，通常要求这样一个节点，可以工作一到两年左右。虽然BR也有广播的内容，但是在BLE的领域里，广播的重要性被强化了。
2. 因为都是蓝牙体系的东西，能最大限度地复用BR/EDR的东西，所以虽然LE的物理层和BR不一样，LE的controller在core spec中是单独的第六章，但是协议栈的架构并没有变，LE host和LE controller的交互还是通过HCI接口，数据包也是使用acl data格式，只是其中的CID是fixed channel的，也就是ATT的固定的channel值4。
3. LE协议在HOST加入了ATT和GATT的内容，为什么要加呢？还是因为LE的工作场景，主要是server/client架构的，比如说温湿度传感器，需要定期向服务器上传数据，数据量很小，时延不敏感，诸如此类的场景是很多的。所以需要抽象出ATT这样一个通用的规范来变得很有必要。

ATT全称是attribute protocol，attribute翻译过来是属性，这个和GATT的characteristic（特性）的概念很容易搞起来。

简单来说，属性是一种数据的基本组织形式，包含handle，type，value，任何一条属性都可以通过handle去唯一寻址。Type是蓝牙协会定义好的一些UUID，取值范围是0x2800-0x28ff，比如说，电池服务这个属性，其属性类型是ATT_DECL_PRIMARY_SERVICE（0x2800）。

Value表示该属性的值，比如说电池服务这个属性值，是访问可读和蓝牙标准组织规定的0x180f。

ATT只是一个protocol，还比较抽象，所以上层进一步定义了GATT，虽然只是多了一个”G”,

含义却大不相同，因为GATT已经包含了profile的概念，蓝牙的profile是一个模糊的概念，包含了应用场景、功能、使用方式等意思，我们之前讲经典蓝牙的时候，已经重点介绍了a2dp这个profile，已经相当的复杂了。相比而言，BLE的确要简单很多。从设计上讲，简单就是优雅。

看一下gatt的架构图：

GATT包含了一系列的service，characteristic，service可以通过include 的方式包含其他service，一个service可以包含一个或多个characteristic（特征），characteristic是基本单位，包含了property，value和descriptor，property定义了该特征如何被使用，以及descriptor如何被访问，value就是这个特征的值。

所有的service，characteristic都使用上面ATT的attibute来描述的，新瓶装旧酒而已。

有了GATT的service，经典蓝牙的sdp（服务发现协议）也是不需要的了，所有的东西都用GATT这一套东西来描述，优雅。

我们还是结合实例来看看数据具体是怎样一个状态，在讲解实例前，先对比一下BLE和BR的packet格式。

BR的格式复习一下:

LE的格式和BR的格式有类似的地方，也有不同的地方；其中access address类似于经典蓝牙的access code，和经典蓝牙中有packet header和payload header不同，LE只有在pdu中有个header，基本包含了前者的流控、重传的功能以及LLID等，根据packet 类型的不同（advertising channel包还data channel包）header的格式是不同的。说到这两种包，LE设计的时候其实主要也就是两种应用场景，一种是需要传更多的数据的，需要建立连接，一种是轻量级的，只需要广播。所以，gap层的role分成面向广播的broadcaster，

Observer；以及面向连接的peripheral，central四种。

Link layer的状态机如下：

 

下面是用sniffer抓取的flip4音箱通过手机app连接，并通过BLE读写的一些数据包，看看这个状态机是怎么运作的。

首先是flip4发出可连接广播包等待手机来连接，注意adv包的access address是固定的地址0x8e89bed6，然后要注意的是PDU_Type，广播包有8种格式，有的可连接，有的不可连接，这里是一个可连接的adv_ind，payload内容主要包括了自己的蓝牙地址和生厂商以及名字等等，这里的flip4的地址是04fea100254b, BLE规定的广播包的physical channel是37、38、39，adv包会轮流在三个频道广播，图中的这个包是频道37。BLE的这种特性决定了连接速度理论上可以3ms左右，比经典蓝牙的inquiry、page都是跳频的做法好很多，因为那两种方式说实话都是在凑。此时flip4的状态是处于advertising状态。

此时手机端打开app，可以扫描周围的BLE设备，应该是可以找到flip4的广播包的，手机端处于scanning状态。

手机端点击连接，就会进入initiating状态：

进入initiating状态的手机试图和flip4连接，发出了connect ind包，其中包含了手机的地址（initiator address）和flip4的地址（advertiser address），至此连接就已经完成了，得到了专属access address：0xaf9a8559，整个过程超级简洁。当然，在手机和flip4的内部，还有一些hci层的交互通知到上层连接的完成，流程图如下：

看一下conn ind包具体包含了哪些信息，除了initiator和adverter各自的地址之外，主要是如下内容

这里面的winsize，winoffset，inerval等等都是BLE的重要参数，决定了双方开窗的时间点和窗口长度，我们知道BLE数据交互比BR少很多，约定这些对于功耗的节省非常重要。

这其实也是BLE建立连接的真正奥义，双方约定好了后续通信的时间点，（以interval为周期），以及每次通信跳频的channel（根据Hop序列计算）。

我们这一次的参数conn interval是25ms：

再来看看后面的connection event的时序吧，周期就是25ms的。

BLE的这种方式与BR在随机时间点通信的方式是不同的。

我们实战中经常遇到BLE断链的情况，一方面和软件的鲁棒性有关，一方面与这种松散的约会方式有关——BLE建链后，是维护一个timer的，双方的每次通信叫做一个connection event，会重置这个timer，如果有一段时间失联，超过Timeout（全称应该是connSupervisionTimeout）的值，则认为断链了。

正所谓，纵使齐眉举案，到底意难平……

不过，好在BLE的连接太过快捷，很多时候我们并不care就是了。

连接建立后，双方的role就确定了，手机是发起initiater的一方，是master，从gap层的官方叫法是central，flip4是pheriperal。叫法虽多，就是视角不同而已，central，pheriperal的叫法更符合应用层。