蓝牙BLE协议栈解析

本文主要参考：http://www.wowotech.net/bluetooth/ble_stack_overview.html

目录

蓝牙4.0BLE协议栈：

1. 物理层（Physical Layer，简写 PHY）：

1.1 Physical Channel（物理信道）

1.2 Physical Links（物理链路）

2. 链路层（Link Layer，简写 LL）：

2.1 功能介绍

2.2 解决Physical Channel的共享问题

2.3 状态（state）和角色（role）的定义

2.4  Air Interface Protocol

2.5 Link Layer Control 

3. 主机控制接口层（Host Controller Interface，简写 HCI）：

4. 逻辑链路控制及自适应协议层（Logical Link Control and Adaptation Protocol，简写 L2CAP）

4.1 功能介绍

4.2  Protocol/channel multiplexing 

5. 属性协议层（Attribute protocol，简写 ATT）：

6. 通用属性配置文件层（Generic Attribute profile，简写 GATT）：

6.1 功能介绍

6.2 层次结构

 6.3 重要的思考

7. Security Manager（SM）

8. 通用访问配置文件层（Generic Access Profile，简写 GAP）：

蓝牙profile框架：

---

蓝牙4.0BLE协议栈：

图1 BLE协议框架

图2

蓝牙协议分为四个层次：物理层（Physical Layer）、逻辑层（Logical Layer）、L2CAP Layer和应用层（APP Layer）。

物理层：负责提供数据传输的物理通道（通常称为信道）。通常情况下，一个通信系统中存在几种不同类型的信道，如控制信道、数据信道、语音信道等等。

逻辑层：在物理层的基础上，提供两个或多个设备之间、和物理无关的逻辑传输通道（也称作逻辑链路）。

L2CAP层：L2CAP是逻辑链路控制和适配协议（Logical Link Control and Adaptation Protocol）的缩写，负责管理逻辑层提供的逻辑链路。基于该协议，不同Application可共享同一个逻辑链路。类似TCP/IP中端口（port）的概念。

APP层：理解蓝牙协议中的应用层，基于L2CAP提供的channel，实现各种各样的应用功能。Profile是蓝牙协议的特有概念，为了实现不同平台下的不同设备的互联互通，蓝牙协议不止规定了核心规范（称作Bluetooth core），也为各种不同的应用场景，定义了各种Application规范，这些应用层规范称作蓝牙profile。

在以上四个层次的基础上，蓝牙协议又做了以下的细分：

1. 物理层（Physical Layer，简写 PHY）：

任何一个通信系统，首先要确定的就是通信介质（物理通道，Physical Channel），BLE也不例外。在BLE协议中，“通信介质”的定义是由Physical Layer（其它通信协议也类似）负责。

Physical Layer是这样描述BLE的通信介质的：

由于BLE属于无线通信，则其通信介质是一定频率范围下的频带资源（Frequency Band）；

BLE的市场定位是个体和民用，因此使用免费的ISM频段（频率范围是2.400-2.4835 GHz）；

为了同时支持多个设备，将整个频带分为40份，每份的带宽为2MHz，称作RF Channel。

经过上面的定义之后，BLE的物理通道已经出来了，即“频点分别是‘f=2402+k*2 MHz, k=0, … ,39’，带宽为2MHz”的40个RF Channel。

除了物理通道之外，Physical Layer还需要定义RF收发双方的一些其它特性，包括（不影响本文后续的讨论，不用深究）：

RF发射相关的特性（Transmitter Characteristics），包括发射功率（Transmission power、调制方式（Modulation），高斯频移键控（Gaussian Frequency Shift Keying ，GFSK）、Spurious Emissions、Radio Frequency Tolerance等等。（不影响本文后续的讨论，不用深究）；

RF接收相关的特性（Receiver Characteristics），包括接收灵敏度等。

物理层负责提供数据传输的物理信道，蓝牙的物理层分为Physical Channel和Physical Links两个子层。

1.1 Physical Channel（物理信道）

BLE使用2.4GHz ISM(Industrial Scientific Medical) 频段，频率范围是2.400-2.4835 GHz。

• ISM频率范围内被分成40个channel，每一个channel占用2M的带宽，在0 channel和39 channel之外设立guard band（保护带宽，Lower Guard Band为2MHz，Upper Guard Band为3.5MHz）。
• LE技术定义了2种物理信道，LE Piconet channel和LE Advertisement Broadcast Channel。
• LE Piconet Channel用在处于连接状态的蓝牙设备之间的通信，和BR/EDR一样，采用调频技术。和BR/EDR不一样的地方是，只会在40个频率channel中的37个上面跳频。
• LE Advertisement Broadcast Channel用于在设备间进行无连接的广播通信，这些广播通信可用于蓝牙设备的发现、连接（和BR/EDR类似）操作，也可用于无连接的数据传输。
• 和BR/EDR一样，同一时刻，BT 设备只能在其中一个物理信道上通信，为了支持多个并行的操作，蓝牙系统采用时分方式，即不同的时间点采用不同的信道。

1.2 Physical Links（物理链路）

物理链路，则是对这些物理信道的进一步封装。

2. 链路层（Link Layer，简写 LL）：

2.1 功能介绍

• 在这些Physical Channel上收发数据。
• 控制RF收发相关的参数。
• 需要解决Physical Channel的共享问题。因为Physical Layer仅仅提供了有限的40个Physical Channel，而BLE中参与通信的实体的数量，肯定不是这个数量级。
• Link Layer需要提供校验、重传等机制，确保数据传输的可靠性。因为Physical Channel是不可靠的，任何数据传输都可能由于干扰等问题二损毁、丢失，这对有些应用来说，是接受不了的。

2.2 解决Physical Channel的共享问题

BLE系统只有有限的40个Physical Channel，怎么容纳多个通信实体呢？说来也简单，Link Layer将BLE的通信场景分为两类：

1）数据量比较少、发送不频繁、对时延不是很敏感的场景：广播通信

例如一个传感器节点（如温度传感器），需要定时（如1s）向处理中心发送传感器数据（如温度）。

从40个Physical Channel中选取3个，作为广播通道（advertising channel）；

在广播通道上，任何参与者，爱发就发，爱收就收，随便；

所有参与者，共享同一个逻辑传输通道（广播通道），之间的

2）数据量较大、发送频率较高、对时延较敏感的场景：连接通信

BLE的Link Layer会从剩余的37个Physical Channel中，选取一个，为这种场景里面的通信双方建立单独的通道（data channel）。这就是连接（connection）的过程。

同时，为了增加容量，增大抗干扰能力，连接不会长期使用一个固定的Physical Channel，而是在多个Channel（如37个）之间随机但有规律的切换，这就是BLE的跳频（Hopping）技术。

2.3 状态（state）和角色（role）的定义

基于上面2.2小节的思路，BLE协议在Link Layer抽象出5种状态：

• Standby State 
• Advertising State 
• Scanning State 
• Initiating State 
• Connection State

注1：从横向看，协议的每个层次（如这里的Link Layer）都可以当做可相互通信的实体。这里的状态，就是指这每一层实体的状态。因此，在协议的多个层次上，都可能有状态定义，甚至名字也一样，我们阅读协议栈的时候，一定要留意，不要被绕晕了。

并以如下的状态机进行切换（设备在同一时刻只能处于这些状态的一种）：

图片2.3.1 Link Layer状态机

Standby状态是初始状态，即不发送数据，也不接收数据。根据上层实体的命令（如位于host软件中GAP），可由其它任何一种状态进入，也可以切换到除Connection状态外的任意一种状态。

Advertising状态是可以通过广播通道发送数据的状态，由Standby状态进入。它广播的数据可以由处于Scanning或者Initiating状态的实体接收。上层实体可通过命令将Advertising状态切换回Standby状态。另外，连接成功后，也可切换为Connection状态。

Scanning状态是可以通过广播通道接收数据的状态，由Standby状态进入。根据Advertiser所广播的数据的类型，有些Scanner还可以主动向Advertiser请求一些额外数据。上层实体可通过命令将Scanning状态切换回Standby状态。

Initiating状态和Scanning状态类似，不过是一种特殊的接收状态，由Standby状态进入，只能接收Advertiser广播的connectable的数据，并在接收到数据后，发送连接请求，以便和Advertiser建立连接。当连接成功后，Initiater和对应的Advertiser都会切换到Connection状态。

Connection状态是和某个实体建立了单独通道的状态，在通道建立之后，由Initiating或者Advertising自动切换而来。通道断开后，会重新回到Standby状态。

通道建立后（通常说“已连接”），处于Connection状态的双方，分别有两种角色Master和Slave：

Initiater方称作Mater；Advertiser方称作Slave。

2.4  Air Interface Protocol

状态和角色定义完成后，剩下的事情就简单了，主要包括两类：提供某一状态下，和其它实体对应状态之间的数据交换机制；根据上层实体的指令，以及当前的实际情况，负责状态之间的切换。BLE协议中，这些事情是由一个叫做空中接口协议（Air Interface Protocol）的家伙负责，主要思路如下。

2.4.1 定义在Physical Channel上收发的数据包的格式（packet format）

在BLE中，两种类型的Physical Channel（advertising channel和data channel）统一使用一种packet format，如下：

Preamble(1 octet)    Access Address(4 octets)    PDU(2 to 257 octets)    CRC(3 octets)

关于packet format，我们可以关注如下内容：

1）Access Address，用于识别。

2）PDU，BLE在Link Layer的PDU长度最大为257 octets（不知道octets是神马意思？当做bytes就行了）。这决定了上层实体，如L2CAP、Application等，需要拆分、重组才能支持更大数据量的传输。

3）Link Layer总packet长度是9~264bytes。

2.4.2 定义不同类型的PDU及其格式

由2.3小节的描述，Link Layer有5种状态，每种状态下所传输数据的功能不尽相同，基于此，Air Interface Protocol定义出如下的PDU类型（这里只简单列举一下，不深入讨论）：

1）Advertising channel中Advertising有关的PDU

ADV_IND，Advertiser发送的、可被连接的、无方向的广播数据（connectable undirected advertising event）。

ADV_DIRECT_IND，Advertiser发送的、可被连接的、单向广播数据（connectable directed advertising event）。

ADV_NONCONN_IND，Advertiser发送的、不可被连接的、无方向的广播数据（non-connectable undirected advertising event）。

ADV_SCAN_IND，Advertiser发送的、可接受SCAN_REQ请求的、无方向的广播数据（scannable undirected advertising event）。

2）Advertising channel中Scanning有关的PDU

SCAN_REQ，Scanner发送的、向Advertiser请求额外信息的数据包（一般需要在收到ADV_SCAN_IND后才可发送）。

SCAN_RSP，Advertiser发送的、响应SCAN_REQ请求的数据包。

3）Advertising channel中Initialing有关的PDU

CONNECT_REQ，Initiater发起的、请求建立连接的数据包。

4）Data channel中LL data有关的PDU

已连接的双方进行数据通信所用的PDU，有效的payload长度为0~251bytes。

5）Data channel中LL control有关的PDU

用于管理、维护、更新已连接的数据通道的PDU，包括：

LL_CHANNEL_MAP_REQ，请求更改所使用的Physical Channel的数据包；

LL_TERMINATE_IND，告知对方此次连接即将结束，以及结束的原因；

等等

2.4.3 以白名单（White List）的形式定义Link Layer的数据过滤机制 

主要针对广播通道，因为随着通信设备的增多，空中的广播数据将会呈几何级的增长，为了避免资源的浪费（特别是BLE Host），有必要在Link Layer过滤掉一些数据包，例如根据蓝牙地址，过滤掉不是给自己的packet。

2.4.4 执行广播通道上实际的packet收发操作

上层软件只需要定义一些参数，例如：

Advertising State下的Advertising Channel的选择、Advertising的间隔、Advertising PDU的类型等；

Scanning State/Initialing State下的scanWindow、scanInterval等。

Link Layer将会自动发送或者接收数据包。

2.5 Link Layer Control 

经过Air Interface Protocol的抽象，BLE实体已经具备广播通信、点对点连接的建立和释放、点对点通信等基本的能力。除此之外，Link Layer又抽象出来一个链路控制协议（Link Layer Control），用于管理、控制两个Link Layer实体之间所建立的这个Connection，主要功能包括：

更新Connection相关的参数，如transmitWindowSize、transmitWindowOffset、connInterval等等（具体意义这里不再详述）；

更新该连接所使用的跳频图谱（使用哪些Physical Channels）；

执行链路加密（Encryption）有关的过程。

3. 主机控制接口层（Host Controller Interface，简写 HCI）：

为主机和控制器之间提供标准通信接口。这一层可以是软件或者硬件接口，如UART、SPI、USB等。

4. 逻辑链路控制及自适应协议层（Logical Link Control and Adaptation Protocol，简写 L2CAP）

4.1 功能介绍

经过Link Layer的抽象之后，两个BLE设备之间可存在两条逻辑上的数据通道：一条是无连接的广播通道，天高任鸟飞；另一条是基于连接的数据通道，是一个点对点（Master对Slave）的逻辑通道。

广播通道暂且不表，这个数据通道（后面简称逻辑通道，Logical Channel），要怎么使用，还需要一番思索，例如：

Logical Channel只有一条，而要利用它传输数据的上层应用却不止一个，怎么复用？

Logical Channel所能传输的有效payload长度最大只有251bytes，怎是否意味着上层应用每次只能传输少于这个长度的数据？（显然不能！）

Logical Channel仅提供了简单的应答和流控机制，如果传输的数据出错怎么办？

等等…

以上问题，都是由L2CAP，一个介于应用程序（Profile、Application等）和Link Layer之间的protocol负责回答，这也是它的缩写（Logical Link Control and Adaptation Protocol）的意义所在。它提供的功能主要包括： 

Protocol/channel multiplexing，协议/通道的多路复用；

Segmentation and reassembly，上层应用数据（L2CAP Service Data Units，SDUs）的分割（和重组），生成协议数据单元（L2CAP Packet Data Units，PDUs），以满足用户数据传输对延时的要求，并便于后续的重传、流控等机制的实现；

Flow control per L2CAP channel，基于L2CAP Channel的流控机制；

Error control and retransmissions，错误控制和重传机制；

Support for Streaming，支持流式传输（如音频、视频等，不需要重传或者只需要有限重传）；

Fragmentation and Recombination，协议数据单元（PDUs）的分片（和重组），生成符合Link Layer传输要求的数据片（长度不超过251，具体可参考5.4.1中有关的介绍）；

Quality of Service，QoS的支持。

4.2  Protocol/channel multiplexing 

所谓的multiplexing（多路复用），还是很好理解的：

可用于传输用户数据的逻辑链路只有一条，而L2CAP需要服务的上层Profile和Application的数目，肯定远不止这个数量。因此，需要使用多路复用的手段，将这些用户数据map到有限的链路资源上去。

至于multiplexing的手段，简单又直接（称的上“协议”的标配）：

数据发送时，将用户数据分割为一定长度的数据包（L2CAP Packet Data Units，PDUs），加上一个包含特定“ID”的header后，通过逻辑链路发送出去。

数据接收时，从逻辑链路接收数据，解析其中的“ID”，并以此判断需要将数据转发给哪个应用。

这里所说的ID，就是多路复用的手段，L2CAP提供两种复用手段：

4.2.1 基于连接的方法（这里的连接为L2CAP connection，不要和Link Layer的connection混淆了）

这里的连接，是指基于L2CAP的应用程序，在通信之前，先建立一个基于Logical Channel的虚拟通道（称作L2CAP channel，和TCP/IP中的端口类似）。L2CAP会为这个通道分配一个编号，称作channel ID（简称CID）。

L2CAP channel建立之后，就可以把CID放到数据包的header中，以达到multiplexing的目的。这些基于CID实现的多路复用，就称作channel multiplexing（基于通道的多路复用）。

那CID是怎么确定的呢？有一些固定用途的L2CAP Channel，其CID是固定值，另外一些则是动态分配的，具体如下：

 BLE CID分配

4.2.2 无连接的方法 

另外，为了提高数据传输的效率，方便广播通信等应用场景，L2CAP在提供基于连接的通信机制之外，也提供了无连接的数据传输方法。基于这种方法，CID不存在了，取而代之的是一个称作Protocol/Service Multiplexer(PSM)的字段。

这种多路复用的手段则成为Protocol multiplexing（基于协议的多路复用）。

由于Protocol multiplexing只允许在BR/EDR controller中使用，本文就不再详细介绍了。

5. 属性协议层（Attribute protocol，简写 ATT）：

由上面章节的描述可知，在BLE协议栈中：Physical Layer负责提供一系列的Physical Channel；基于这些Physical Channel，Link Layer可在两个设备之间建立用于点对点通信的Logical Channel；而L2CAP则将这个Logical Channel换分为一个个的L2CAP Channel，以便提供应用程序级别的通道复用。到此之后，基本协议栈已经构建完毕，应用程序已经可以基于L2CAP欢快的run起来了。

谈起应用程序，就不得不说BLE的初衷----物联网。物联网中传输的数据和传统的互联网有什么区别呢？抛开其它不谈，物联网中最重要、最广泛的一类应用是：信息的采集。

这些信息往往都很简单，如温度、湿度、速度、位置信息、电量、水压、等等。

采集的过程也很简单，节点设备定时的向中心设备汇报信息数据，或者，中心设备在需要的时候主动查询。

基于信息采集的需求，BLE抽象出一个协议：Attribute protocol，该协议将这些“信息”以“Attribute（属性）”的形式抽象出来，并提供一些方法，供远端设备（remote device）读取、修改这些属性的值（Attribute value）。 

Attribute Protocol的主要思路包括：

1）基于L2CAP，使用固定的Channel ID（0x004，具体可参考“BLE CID分配”）。

2）采用client-server的形式。提供信息（以后都称作Attribute）的一方称作ATT server（一般是那些传感器节点），访问信息的一方称作ATT client。

3）一个Attribute由Attribute Type、Attribute Handle和Attribute Value组成。

Attribute Type用于标示Attribute的类型，类似于我们常说的“温度”、“湿度”等人类可识别的术语，不过与人类术语不同的是，Attribute Type使用UUID（Universally Unique IDentifier，16-bit、32-bit或者128-bit的数值）区分。

Attribute Handle是一个16-bit的数值，用作唯一识别Attribute server上的所有Attribute。Attribute Handle的存在有如下意义： 
        a）一个server上可能存在多个相同type的Attribute，显然，client有区分这些Attribute的需要。 
        b）同一类型的多个Attribute，可以组成一个Group，client可以通过这个Group中的起、始handle访问所有的Attributes。

Attribute Value代表Attribute的值，可以是任何固定长度或者可变长度的octet array（理解为字节类型的数组即可）。 

4）Attribute可以定义一些权限（Permissions），以便server控制client的访问行为，包括：

访问有关的权限（access permissions），Readable、Writeable以及Readable and writable；

加密有关的权限（encryption permissions），Encryption required和No encryption required；

认证有关的权限（authentication permissions），Authentication Required和No Authentication Required；

授权有关的权限（authorization permissions），Authorization Required和No Authorization Required

5）根据所定义的Attribute PDU的不同，client可以对server有多种访问方式，包括：

Find Information，获取Attribute type和Attribute Handle的对应关系；

Reading Attributes，有Read by type、Read by handle、Read by blob（只读取部分信息）、Read Multiple（读取多个handle的value）等方式；

Writing Attributes，包括需要应答的writing、不需要应答的writing等。

6. 通用属性配置文件层（Generic Attribute profile，简写 GATT）：

6.1 功能介绍

ATT之所以称作“protocol”，是因为它还比较抽象，仅仅定义了一套机制，允许client和server通过Attribute的形式共享信息。而具体共享哪些信息，ATT并不关心，这是GATT（Generic Attribute Profile）的主场。

GATT相对ATT只多了一个‘G‘，但含义却大不同，因为GATT是一个profile（更准确的说是profile framework）。

在蓝牙协议中，profile一直是一个比较抽象的概念，我们可以将其理解为“应用场景、功能、使用方式”都被规定好的Application。传统的BR/EDR如此，BLE更甚。上面我们讲过，BLE很大一部分的应用场景是信息（Attribute）的共享，因此，BLE协议栈基于Attribute Protocol，定义了一个称作GATT（Generic Attribute）的profile framework（它本身也是一个profile），用于提供通用的、信息的存储和共享等功能。

6.2 层次结构

作为一个Profile framework，GATT profile提出了如下的层次结构：

 GATT Profile hierarchy

由上面图片可知，GATT profile的层次结构依次是：Profile—>Service—>characteristic。

“Profile”是基于GATT所派生出的真正的Profile，位于GATT Profile hierarchy的最顶层，由一个或者多个和某一应用场景有关的Service组成。

一个Service包含一个或者多个Characteristic（特征），也可以通过Include的方式，包含其它Service。

Characteristic则是GATT profile中最基本的数据单位，由一个Properties、一个Value、一个或者多个Descriptor组成。

Characteristic Properties定义了characteristic的Value如何被使用，以及characteristic的Descriptor如何被访问。

Characteristic Value是特征的实际值，例如一个温度特征，其Characteristic Value就是温度值就。

Characteristic Descriptor则保存了一些和Characteristic Value相关的信息（比较抽象，后续文章会根据实例做进一步的理解）。

以上除“Profile”外的每一个定义，Service、Characteristic、Characteristic Properties、Characteristic Value、Characteristic Descriptor等等，都是作为一个Attribute存在的，具备第8章所描述的Attribute的所有特征：Attribute 
Handle、Attribute Types、Attribute Value和AttributePermissions。

 6.3 重要的思考

蓝牙4.0之后所引入的GATT profile，是一个非常有“心计”的profile，其中有三点，需要我们重点关注：

1）基于GATT架构，Application的存在形式，不再是单一的Profile，很多简单的应用场景，可以直接以Service的形式存在（profile的概念隐藏在了GATT中），这大大简化了一些传感器节点的设计复杂度。

2）仔细瞅一下图片4中的Service，然后回忆一下蓝牙BR/EDR中的服务发现协议（Service Discover Protocol，SDP）中的“Service”，是否有什么关联？你猜对了，非常有关联，在存在GATT的实现中，SDP就没有存在的必要了。Service也是一个普通的Generic Attribute。也正是因为这样的抽象，才使得以往蓝牙协议中的“Service”实例化了。

3）所谓的“Service”实例化，指的是，任何一个profile，都是由service和对应的profile功能组成。

7. Security Manager（SM）

Security Manager负责BLE通信中有关安全的内容（毫无疑问，在物联网时代，安全变得更重要，谁也不想卧室的灯在深夜的时候会无缘无故的亮吧），包括配对（pairing,）、认证（authentication）和加密（encryption）等过程。

8. 通用访问配置文件层（Generic Access Profile，简写 GAP）：

上面4到7章的内容，都是和基于连接的data channel有关，至于无连接的advertising channel，以及连接建立的过程，好像被我们忽略了。虽然Link Layer已经做出了定义（具体可参考第2章的介绍），但它们并没有体现到Application（或者Profile）层面，毕竟Link layer太底层了。

因此，BLE协议栈定义了一个称作Generic Access（通用访问）的profile，以实现如下功能：

1）定义GAP层的蓝牙设备角色（role）

和2.3中的Link Layer的role类似，只不过GAP层的role更接近用户（可以等同于从用户的角度看到的蓝牙设备的role），包括：

Broadcaster Role，设备正在发送advertising events；

Observer Role，设备正在接收advertising events；

Peripheral Role，设备接受Link Layer连接（对应Link Layer的slave角色）；

Central Role，设备发起Link Layer连接（对应Link Layer的master角色）。

2）定义GAP层的、用于实现各种通信的操作模式（Operational Mode）和过程（Procedures），包括：

Broadcast mode and observation procedure，实现单向的、无连接的通信方式；

Discovery modes and procedures，实现蓝牙设备的发现操作；

Connection modes and procedures，实现蓝牙设备的连接操作；

Bonding modes and procedures，实现蓝牙设备的配对操作。

3）定义User Interface有关的蓝牙参数，包括：

蓝牙地址（Bluetooth Device Address）；

蓝牙名称（Bluetooth Device Name）；

蓝牙的pincode（Bluetooth Passkey）；

蓝牙的class（Class of Device，和发射功率有关）；

等等。

4）Security有关的定义，暂不介绍

蓝牙profile框架：

 

profile：可以理解为一种规范，一个标准的通信协议，它存在于从机中。蓝牙组织规定了一些标准的profile，例如 HID OVER GATT ，防丢器 ，心率计等。每个profile中会包含多个service，每个service代表从机的一种能力。每个从机都会有一个叫做profile的东西存在，不管是上面自定义的simple profile，还是标准的防丢器profile，他们都是由一系列service组成，然后每个service又包含了多个characteristic，主机和从机之间的通信，均是通过characteristic来实现。

服务（service）：service可以理解为一个服务，在ble从机中，通常有多个服务，例如电量信息服务、系统信息服务等，每个service中又包含多个characteristic特征值。每个具体的characteristic特征值才是ble通信的主题。比如当前的电量是80%，所以会通过电量的characteristic特征值存在从机的profile里，这样主机就可以通过这个characteristic来读取80%这个数据。

特征（Characteristics）：一个characteristics包含一个单独的value值和0 ~n个用来描述characteristic 值（value）的descriptors。一个characteristics可以被认为是一种类型，类似于一个类。在ble主从机的通信均是通过characteristic来实现，可以理解为一个标签，通过这个标签可以获取或者写入想要的内容。

描述符(descriptor)：descriptor是被定义的attributes，用来描述一个characteristic的值。例如，一个descriptor可以指定一个人类可读的描述中，在可接受的范围里characteristic值，或者是测量单位，用来明确characteristic的值。

UUID：统一识别码，我们刚才提到的service和characteristic，都需要一个唯一的uuid来标识。

      实际产品中，每个蓝牙4.0的设备都是通过服务和特征来展示自己的，服务和特征都是用UUID来唯一标识的。一个设备必然包含一个或多个服务，每个服务下面又包含若干个特征。特征是与外界交互的最小单位。蓝牙设备硬件厂商通常都会提供他们的设备里面各个服务(service)和特征(characteristics)的功能，比如哪些是用来交互(读写)，哪些可获取模块信息(只读)等。比如说，一台蓝牙4.0设备，用特征A来描述自己的出厂信息，用特征B来与收发数据等。