这里写自定义目录标题
1.蓝牙简介
蓝牙因为历史问题，分类太多太杂，这里主要讲BLE蓝牙（毕竟现在BLE是物联网主流）。
涉及知识详细点可以自行查询，这里长话短说只讲框架，有一个大体的了解。
1.1 蓝牙分类
经典蓝牙我们一般说的是BT，低功耗蓝牙我们一般说成BLE。当设备支持蓝牙4.0时，还得进一步确认设备是支持BT单模、BLE单模还是BT和BLE都支持的双模。
- 低功耗蓝牙 (BLE)： 支持蓝牙协议4.0或更高的模块。主打低功耗，多用于物联网类型。
- 经典蓝牙( BT)： 指支持蓝牙协议在4.0以下的模块。主打短距离数据高速传输，多用于蓝牙耳机等。
- 经典蓝牙可再细分为：传统蓝牙和高速蓝牙。
- 传统蓝牙： 2004年推出，蓝牙2.0/2.1协议。
- 高速蓝牙： 2009年推出，蓝牙3.0协议，速率提高到约24Mbps，是传统蓝牙模块的八倍。
- 双模蓝牙： 即兼容BLE和BT，如手机，使用分时机制来达到同时与低功耗蓝牙和经典蓝牙设备通信。
1.2 蓝牙技术
蓝牙协议包括两种技术：Basic Rate(BR) 和 Low Energy(LE)。
Basic Rate又包括可选的EDR（Enhanced Data Rate） 技术，以及 交替使用的（Alternate）的MAC（Media Access Control）层和PHY层扩展（简称AMP）。、
在蓝牙4.0及后面规格中，SIG定义了四种蓝牙技术：BR，EDR，AMP和LE ，由于LE是2010年才提出的，比较新，所以人们把之前的BR/EDR/AMP技术称之为经典蓝牙。
- 经典蓝牙( BT)：
- BR(Basic Rate): 蓝牙基础速率技术。
- EDR(Enhanced Data Rate) : 蓝牙增强速率技术。
- AMP (Alternate MAC/PHYs): 蓝牙核心系统的次要控制器,可切换的媒体访问控制器（Media Access Controller）和物理层（Physical Layer）。
- 低功耗蓝牙 (BLE)：
- LE(Low Energy): 蓝牙低功耗技术。
注意：
EDR 是在 BR 技术基础上升级，所以两者可以同时使用。但是AMP 技术是使用的802.11（WIFI）规范，所以和原有的技术差异过大，所以BR/EDR和AMP只能二选一进行使用。
LE技术相比BR技术，差异非常大，可以说就是两种不同的技术。经典蓝牙和低功耗蓝牙两者物理层调制解调方式是不一样的，所以低功耗蓝牙设备和经典蓝牙设备两者之间是不能相互通信的。。
| 低功耗蓝牙 (LE) | 经典蓝牙 (BR) | |
|---|---|---|
| 频带 (Frequency Band) | 2.4GHz ISM 频段（使用 2.402 – 2.480 GHz） | 2.4GHz ISM 频段（使用 2.402 – 2.480 GHz） |
| 频道 (Channels) | 40 个信道，间隔为 2 MHz 3个广播信道(37,38,39) / 37 个数据通道 | 79 个通道，间隔为 1 MHz |
| 数据速率（Data Rate） | LE 2M PHY：2 Mb/s LE 1M PHY：1 Mb/s LE Coded PHY (S=2)：500 Kb/s LE Coded PHY (S=8)：125 Kb/s | EDR PHY (8DPSK)：3 Mb/s EDR PHY (π/4 DQPSK)：2 Mb/s BR PHY (GFSK)：1 Mb/s |
| 发射功率(Tx Power) | ≤ 100 mW (+20 dBm) | ≤ 100 mW (+20 dBm) |
| 接收灵敏度(Rx Sensitivity) | LE 2M PHY: ≤-70 dBm LE 1M PHY: ≤-70 dBm LE Coded PHY (S=2): ≤-75 dBm LE Coded PHY (S=8): ≤-82 dBm | ≤-70 dBm |
| 通信拓扑(Communication Topologies) | Point-to-Point （点对点：一对一） Broadcast（广播：一对多） Mesh 组网（多对多） | Point-to-Point （点对点） |
1.3 蓝牙协议框架
- 蓝牙协议规定了两个层次的协议，分别为蓝牙核心协议（Bluetooth Core） 和 蓝牙应用层协议（Bluetooth Application）。
- 蓝牙核心协议（Bluetooth Core）： 关注对蓝牙核心技术的描述和规范，它只提供基础的机制，并不关心如何使用这些机制。
- 蓝牙应用层协议（Bluetooth Application）： 是在蓝牙核心协议的基础上，根据具体的应用需求，定义出各种各样的策略，如FTP、文件传输、局域网等等
- 蓝牙核心协议（Bluetooth Core） 由 主机（Host）、控制器（Controller） 和 零个或多个 辅助控制器 组成。控制器又可分为主控制器 和 辅助控制器。两者在不同的蓝牙技术中（BR/EDR、AMP、LE），承担角色略有不同，但大致的功能是相同的，如下图。
- 控制器（Controller）： 负责定义RF、Baseband等偏硬件的规范，并在这之上抽象出用于通信的逻辑链路（Logical Link）。- 下图中整个蓝牙框架中有三种控制器，分别是BR/EDR Controller、LE Controller和AMP Controller。
- 主机（Host）： 负责在逻辑链路的基础上，进行更为友好的封装，这样就可以屏蔽掉蓝牙技术的细节，让 蓝牙应用层协议（Bluetooth Application） 更为方便的使用。
| 蓝牙核心协议（Bluetooth Core） | 名称 | 含义 | 功能 |
|---|---|---|---|
|
|
|
| 1. 定义物理通道(Physical Channel)，带宽为2MHz的40个RF Channel。 2. 定义RF收发双方的特征（发射功率、调制方式等）。 3. 负责物理信道上数据的发送和接收。 |
|
|
| 1. 编解码蓝牙数据包。蓝牙数据包为物理信道、逻辑传输和逻辑链路的相关数据负载和参数。 2. 携带链路控制协议信令（ BR/EDR）或链路层协议（LE），包括流控、确认、重传请求信令。 | |
|
|
| 负责所有无线媒介的访问。 1. 时间调度器，负责给已协商约定的所有访问实体分配物理信道时间。 2. 协商约定，与访问实体协商访问参数，以便于给用户程序提供一个确定的QoS质量。 3. 时间调度和协商约定必须考虑到需要主控制器的所用行为，包括已连接设备在逻辑链路和逻辑通道上的所有数据交互，执行查询、连接、可被发现、可连接、可读等的无线媒介使用情况。 | |
|
|
| 负责创建、修改或释放逻辑链路，以及更新设备之间的相关物理链路参数。 1. 链路管理器利用链路管理协议（LMP, ER/EDR）或链路层协议（LL，LE）与远程蓝牙设备的链路管理器通信。 2. LM、LL协议允许在设备之间创建新的逻辑链路和逻辑通道，控制逻辑链路和通道的属性，如使能链路安全、调整BR/EDR物理链路的发送功率、逻辑链路的QoS设置。 | |
|
|
| 用于控制蓝牙设备的行为，负责除数据传输外的所有蓝牙系统的操作。 1. 搜索附近的蓝牙设备、连接蓝牙设备、标记本地蓝牙设备为可发现的、可连接的等。 2. 为了执行相应的功能，设备管理器需要访问基带资源管理器的传输媒介。 3. 设备资源管理器通过一系列HCI命令控制本地设备的行为，如管理设备名字，存储链路秘钥等。 | |
|
|
|
| 主要负责创建、管理和关闭用于传输服务协议和应用层数据流的L2CAP信道。 1. 信道管理器利用L2CAP协议与远程（对端）终端上的信道管理器进行交互，以创建L2CAP信道。 2. 信道管理器与本地链路管理器或AMP PAL进行交互，以创建新的逻辑链路和配置这些链路，从而为传输数据提供所需的服务质量。 |
|
|
| 1. 主要负责管理传递给基带PDU片段的有序性和信道之间的调度， 以确保具有QoS承诺的L2CAP通道不会因为控制器资源耗尽而被拒绝访问物理通道。 2. 还可能执行流量一致性政策，以保证提交的L2CAP SDU在协商的QoS范围内。 | |
|
|
| 端对端协议。 1. 生成加密秘钥和身份标识秘钥，并存储。 2. 使用专有的固有的L2CAP信道。 3. 生成随机地址，并将随机地址解析为已知设备标识。 4. 直接与控制器交互，在加密和配对过程中提供加密和鉴权的秘钥。 | |
|
|
| 端对端协议，服务器和客户端之间的协议。 1. ATT客户端通过专用的固定L2CAP通道与远程设备上的ATT服务端通信。 2. ATT客户端向ATT服务端发送命令、请求和确认。 3. ATT服务端向客户端发送响应、通知和指示。 4. ATT客户端的命令和请求提供了在ATT服务端的对等设备上读、写属性值的方法。 | |
|
|
| 描述属性服务器的功能，选择性地描述属性客户端的功能。 1. 描述了服务层次、特点，以及属性服务器的属性。 2. 提供发现、读、写以及服务特点和属性的接口。 | |
|
|
| 提供了应用发现可用服务以及确定可用服务特点的方法。 1. 为客户提供搜索所需要服务的能力. 2. 允许基于服务类型搜索服务 3. 可抑执行服务浏览，而不需预先知道服务特征. 4. 提供一种新的方法来搜索新的服务. 5. 提供一种机制来确定在设备离开客户设备邻频时，设备在何时变为不可用. 6. 提供对服务、服务类型和属性的唯一标识 7. 允许在一方设备上的客户在另一方设备上搜索服务，而无需查询第三方设备 8. 在复杂性不高的设备上使用. 9. 提供一种可发现更多服务信息的机制 10. 可通过中介代理支持服务搜索信息缓存 11. 可独立传输. | |
|
|
| 1. 使用专有的L2CAP信号信道与远程设备的AMP管理器进行通信。 2. 直接与AMP PAL交互，以便于AMP控制。 3. 发现远程AMP，并确定其有效性。 4. 收集远程AMP信息，以便于建立和管理AMP物理链路。 | |
|
|
| 描述所有蓝牙设备的通用基本功能。 1. GAP服务包括：设备发现、连接模式、安全、鉴权、服务发现、关联模型。 | |
|
|
|
| |
|
|
| ||
|
|
| AMP MAC与Host之间的接口。 1. 将Host命令或事件转化成MAC服务命令或事件，将MAC服务命令或事件转化为host能明白的命令和事件。 2. 支持AMP信道管理、基于特定流控模板的数据流量管理、电源效率管理等。 | |
|
|
| AMP控制器与主机之间的逻辑接口。 1. 支持AMPs需要额外的与AMP物理信号和逻辑信道管理、QoS、流控相关的HCI命令和事件。 2. 一个AMP控制器对应一个HCI逻辑实体，一个BR/EDR控制器对应一个HCI逻辑实体。当多个控制器在同一个物理单元时，一个物理HCI传输层管理多个复用在同一物理传输线上的控制器。 |
不同类型的蓝牙对蓝牙协议框架的应用：
2.BLE 低功耗蓝牙协议
2.1 BLE协议栈框架
因为开发中应用的是BLE蓝牙，所以这里只把BLE协议框架单独拿出来讲。根据上述，BLE蓝牙协议框架如下图：
- PHY(Physical Layer) ： 定义物理通道(Physical Channel)，带宽为2MHz的40个RF Channel，以及RF的收发特征。
- LL(Link Layer) ： Link Layer需要解决Physical Channel的共享问题。把PHY定义的40个通道进行定义分配，3个广播通道37（2402MHZ）、38（2426MHZ）、39（2480MHZ）和37个数据通道。同时提供校验、重传等机制，确保数据传输的可靠性。另外连接之后选定一个通道作为数据连接通道（跳频切换）。此外BLE协议在Link Layer抽象出5种状态：详见 2.2 Link Layer States
- HCI： 定义Host和Controller之间的通信协议，可基于UART、USB等。
- L2CAP Protocol: 数据通道（Logical Channel）的使用方式由此决定。所以说L2CAP是一个介于应用程序（Profile、Application等）和Link Layer之间的协议，缩写（Logical Link Control and Adaptation Protocol）。详见 2.3 L2CAP Protocol
- ATT(Attribute Protocol)： 上述协议可以让程序运行起来，然后ATT给数据定义了一套机制，仅提供一种协议格式。
- GATT(Generic Attribute Profile)： ATT允许client和server通过Attribute的形式共享信息。而具体共享哪些信息，ATT并不关心，这些由GATT（Generic Attribute Profile）处理。
2.2 Link Layer States
2.2.1 状态描述
- 就绪状态（Standby State）：初始状态，即不发送数据，也不接收数据。根据上层协议的命令（如GAP）可由其它任何一种状态进入，也可以切换到除Connection状态外的任意一种状态。
- 广播状态（Advertising State）：可以通过广播通道发送数据的状态，由Standby状态进入。广播的数据可以由处于Scanning或者Initiating状态的实体接收。上层协议可通过命令将Advertising状态切换回Standby状态。连接成功后可切换为Connection状态。
- 扫描状态（Scanning State）：通过广播通道接收数据的状态，Scanning状态可用于侦听一定区域内的广播数据，有被动扫描和主动扫描两个子状态，被动扫描仅接收广播报文，主动扫描则发送扫描请求给广播态设备，并获取附加的扫描响应数据。Scanning状态的设备只能进入Standby状态，条件是上层协议发送的停止扫描命令。
- 初始化状态（Initiating State）：为了像设备发起连接，链路层需要处于Initiating状态。发起连接，将携带 connection request（连接请求）响应广播者，侦听自己试图连接的设备，如果收到了来自该设备的connectable广播报文，链路层会向其发送连接请求并进入Connection状态，当连接成功后对端的广播设备也会进入Connection状态。Initiating状态由Standby状态进入，如果不再发起连接或连接失败则返回Standby状态，如果连接成功则建立连接的双方都进入Connection状态。
- 连接状态（Connection State）：Connection状态是和某个实体建立了单独通道的状态，在通道建立之后，由Initiating或者Advertising自动切换而来。通道断开后，会重新回到Standby状态。
2.2.2 状态切换
根据上面的链路层状态机的状态切换图状态，拿手机连接BLE蓝牙设备（如小米手环）的流程举例：
| 设备种类 | 状态1⟿ | 状态2 ⟿ | 状态3 ⟿ | 状态4 |
|---|---|---|---|---|
| 主机（Master）/ 客户端 (Client) | 就绪状态（Standby State） | 扫描状态（Scanning State） | 初始化状态（Initiating State） | 连接状态（Connection State） |
| 手机 | 手机打开蓝牙 | 扫描附近的蓝牙设备，接受蓝牙设备的广播数据包 | 向蓝牙设备发送连接请求，并监听应答 | 与蓝牙设备建立连接 |
| 从机（Slave）/ 服务器 (Server) | 就绪状态（Standby State） | 广播状态（Advertising State） | 广播状态（Advertising State） | 连接状态（Connection State） |
| 蓝牙设备 | 上电初始化状态 | 发送自己的广播数据 | 向手机应答连接的广播报文 | 与手机建立连接 |
2.3 L2CAP Protocol
2.3.1 L2CAP描述
L2CAP-全称是逻辑链路控制与适配层。经过Link Layer的抽象之后，两个BLE设备之间可存在两条逻辑上的数据通道：一条是无连接的广播通道；另一条是基于连接的数据通道，是一个点对点（Master对Slave）的逻辑通道。
L2CAP主要功能：
- 协议信道复用（protocol/channel multiplexing）
- 分段与重组（segmentation and reassembly SAR）
- 每个信道流控（per-channel flow control）
- 差错控制（error control）
L2CAP可分为两个部分
- 通道管理器（Channel Manager）： 提供控制层功能，并负责所有内部信令、L2CAP点对点信号和上下层的信令。
- 资源管理器 （Resource Manager）： 负责向通道管理器、重传输和流控制块以及那些不需要重传输和流控制服务的应用程序数据流提供帧中继服务。负责通过底层接口提供的设施，协调与多个L2CAP通道相关的数据包的传输和接收。
L2CAP架构图如下：
2.3.2 L2CAP Channel
基于L2CAP的应用程序，在通信之前，先建立一个基于Logical Channel的虚拟通道（称作L2CAP channel）。L2CAP会为这个通道分配一个编号，称作channel ID（简称CID）。L2CAP channel建立之后，就可以把CID放到数据包的header中，以达到基于CID的多路复用。
有一些固定用途的L2CAP Channel，其CID是固定值，另外一些则是动态分配的。另外分为ACL-U 和 AMP-U 逻辑链路的 CID。其中BLE蓝牙使用0x0004、0x0005、0x0006。固定CID如下表：
| CID | 描述 |
|---|---|
| 0X0000 | 空标识符 |
| 0x0001-0x0003 | 保留 |
| 0x0004 | 属性协议 |
| 0x0005 | 低功耗L2CAP命令通道 |
| 0x0006 | 安全管理器协议 |
| 0x0007-0x001F | 保留 |
| 0x0020-0x003E | 分配的号码 |
| 0x003F | 保留 |
| 0x0040-0x007F | 动态分配 |
| 0x0080-0xFFFF | 保留 |
2.4 ATT (Attribute Protocol)
2.4.1 Attribute Protocol描述
在BLE协议栈中：Physical Layer负责提供一系列的Physical Channel；基于这些Physical Channel，Link Layer可在两个设备之间建立用于点对点通信的Logical Channel；而L2CAP则将这个Logical Channel换分为一个个的L2CAP Channel，以便提供应用程序级别的通道复用。到此之后，基本协议栈已经构建完毕，应用程序已经可以基于L2CAP跑起来了。
BLE蓝牙初衷是应用于物联网，所以信息的采集就很重要。这才有了Attribute protocol协议的使用，该协议将这些“信息”以“Attribute（属性）”的形式抽象出来，并提供一些方法，供远端设备（remote device）读取、修改这些属性的值（Attribute value）。
2.4.2 Attribute Protocol定义
BLE的数据以属性 (Attribute) ⽅式存在，每条属性由四个元素组成：
- 属性句柄 (Attribute Handle)： 正如我们可以使⽤内存地址查找内存中的内容⼀样，ATT 属性的句柄也可以协助我们找到相应的属性，例如第⼀个属性的句柄是0x0001，第⼆个属性的句柄是 0x0002，以此类推，最⼤可以到 0xFFFF。
- 属性类型 (Attribute UUID)： 根据蓝牙 4.2 协议规范(Vol 3, Part B, section 2.5.1 UUID)，UUID 是一个 128 位的唯一标识符，用来标识 服务 (Service) 和 特征(Characteristic) 等。为了减少存储和传输 128 位 UUID 值的负担，蓝牙技术联盟预分配了一批 UUID，这一批 UUID 拥有一个共同部分，被称为 Bluetooth Base UUID，预分配的 UUID 也可以使用 16 位或 32 位表示，其中 16 位 UUID 最为常用，其模板为 ：
0000XXXX-0000-1000-8000-00805F9B34FB。
| 分配类型 | 分配UUID段 | 作用 |
|---|---|---|
| GATT Service | 0x1800 ~ 0x26FF | 服务类型，用来识别具体是哪个服务。 |
| GATT Unit | 0x2700 ~ 0x27FF | 计量单位，如：km/h， kg。 |
| GATT Declarations | 0x2800 – 0x28FF | 声明属性类型，如：首要/次要/包含/特征。 |
| GATT Descriptor | 0x2900 – 0x29FF | 特征描述，如：CCCD（客户端特征配置描述符）、User Description。 |
| GATT Characteristic and Object Type | 0x2A00 – 0x7FFF | 特征类型，如：DeviceName/Version等。 |
- 属性值 (Attribute Value)： 属性值是每个属性真正要承载的信息，其他 3 个元素都是为了让对⽅能够更好地获取属性值。有些属性的⻓度是固定的，例如电池属性(Battery Level) 的⻓度只有 1 个字节，因为需要表示的数据仅有 0~100%，⽽ 1 个字节⾜以表示 1～100 的范围；⽽有些属性的⻓度是可变的，例如基于 BLE 实现的透传模块。
- 属性权限 (Attribute Permissions)： 每个属性对各⾃的属性值有相应的访问限制，⽐如有些属性是可读的、有些是可写的、有些是可读⼜可写的等等。拥有数据的⼀⽅可以通过属性许可，控制本地数据的可读写属性。
属性权限主要有以下四种：- 访问权限（Access Permission）- 只读、只写、读写
- 加密权限（Encryption Permission） – 加密、不加密
- 认证权限（Authentication Permission） – 需要认证、无需认证
- 授权权限（Authorization Permission） – 需要授权、无需授权
2.5 GATT (Generic Attribute Profile)
2.5.1 GATT 配置文件定义的属性类型
在分析之前，先记住一下常用的UUID含义。
| 分配类型 | 分配的UUID | 分配目标 | 中文释义 |
|---|---|---|---|
| 声明 (Declarations) | 0x2800 | Primary Service | 主要服务 |
| 声明 (Declarations) | 0x2801 | Secondary Service | 二级服务 |
| 声明 (Declarations) | 0x2802 | Include | 包括 |
| 声明 (Declarations) | 0x2803 | Characteristic | 特征 |
| 描述符 (Descriptor) | 0x2900 | Characteristic Extended Properties | 特征扩展属性 |
| 描述符 (Descriptor) | 0x2901 | Characteristic User Description | 特征用户描述 |
| 描述符 (Descriptor) | 0x2902 | Client Characteristic Configuration | 客户端特征配置 |
| 描述符 (Descriptor) | 0x2903 | Server Characteristic Configuration | 服务器特征配置 |
| 描述符 (Descriptor) | 0x2904 | Characteristic Presentation Format | 特征描述格式 |
| 描述符 (Descriptor) | 0x2905 | Characteristic Aggregate Format | 特征汇总格式 |
2.5.2 GATT服务框架
ATT主要是规定了协议的格式，允许client和server通过Attribute的形式共享信息。而具体共享哪些信息，ATT并不关心。GATT则根据ATT的协议格式将各种"属性"进行包装，以用于提供通用的、信息的存储和共享等功能。GATT profile的层次结构如下:
- 配置文件 (Profile): Profile 是被蓝牙标准预先定义的一些 Service 的集合，并不真实存在于蓝牙设备中。如果蓝牙设备之间要相互兼容，它们只要支持相同的 Profile 即可。一个蓝牙设备可以支持多个 Profile。
- 服务 (Service): Service 是蓝牙设备对外提供的服务，一个设备可以提供多个服务，比如电量信息服务、系统信息服务等。每个服务由一个 UUID 唯一标识。
- 特征 (Characteristic): 每个 Service 包含 0 至多个 Characteristic。比如，电量信息服务就会有个 Characteristic 表示电量数据。Characteristic 包含一个值 (value)和 0 至多个描述符 (Desciptor) 组成。在与蓝牙设备通信时，主要就是通过读写 Characteristic 的 value 完成。 每个 Characteristic 由一个 UUID 唯一标识。
- 描述符 (Descriptor): Descriptor 是描述特征值的已定义属性。例如，Descriptor 可指定人类可读的描述、特征值的取值范围或特定于特征值的度量单位。
总结：
- GATT服务结构的可以说是一个配置文件(Profile)。
- 配置文件(Profile)由一个或多个服务(Service) 的集合。
- 服务(Service) 是特征(Characteristic) 或对其他服务的引用(Include) 的集合。
- 每个服务(Service) 和特征(Characteristic) 都会有自己的一个UUID去做标识。
2.5.3 服务(Service)
一个服务定义(Service Definition ) 从它的服务声明(Service Declaration) 开始，到下一个服务(Service) 的服务声明(Service Declaration) 结束；或一直持续到最大的属性句柄 (Attribute Handle) 值。
服务(Service) 可以理解为 特征(Characteristic) 的分组，但是 服务(Service) 具有自己的服务声明(Service Declaration)，总的来说就是一个服务包含一个服务声明(Service Declaration) 和 一个及以上的特征(Characteristic)。
一个 服务定义( service definition ) 包含：
- 服务声明（Service Declaration）: Attribute 格式定义如下表
| 属性句柄 (Attribute Handle) | 属性类型 (Attribute UUID) | 属性值 (Attribute Value) | 属性权限 (Attribute Permissions) |
|---|---|---|---|
| 0xNNNN | 0x2800 Primary Service（首要服务项） 的UUID 或者 0x2801 Secondary Service（次要服务项） 的 UUID | 服务(Service) 的 UUID (16bit或者128bit) | 只读（Read Only） 无需认证(No Authentication) 无需授权(No Authorization) |
- 特征(Characteristic)：一个或者多个。
2.5.4 特征(Characteristic)
一个 特征定义(characteristic definition) 必须包含一个 特征声明(characteristic declaration) 和一个 特征值声明(Characteristic Value declaration) ，可以包含任意数量的 特征描述符声明(characteristic descriptor declaration) 。
2.5.4-1 特征声明(characteristic declaration)
特征声明(characteristic declaration) 的Attribute 格式定义如下表
| 属性句柄 (Attribute Handle) | 属性类型 (Attribute UUID) | 属性值 (Attribute Value) | 属性权限 (Attribute Permissions) | ||
|---|---|---|---|---|---|
|
|
0x2803
Characteristic（特征） 的UUID |
|
Characteristic Value Attribute Handle |
|
无需认证(No Authentication) 无需授权(No Authorization) |
| 属性值 (Attribute Value) | *大小 | 描述 |
|---|---|---|
| 属性(Properties) | 1byte | 特征属性的位域 |
| 特征值属性句柄(Characteristic Value Attribute Handle) | 2byte | 包含此特征值的属性句柄 |
| 特征的UUID | 16bit 或者 128bit | 用于特征值的UUID |
- 属性(Properties)： 定义了 特征(Characteristic) 的 值(Value) 如何被使用，以及特征(Characteristic) 的描述 (Descriptor) 如何被访问。
| 属性(Properties) | 对应的值 | 描述 |
|---|---|---|
| Broadcasts | 0x01 | 该 特征 (Characteristic) 会被广播出来。如果设置，服务器特性配置描述符(Server Characteristic Configuration Descriptor) 应存在。 |
| Read | 0x02 | 该 特征 (Characteristic) 可读。 |
| Write Without Response | 0x04 | 该 特征 (Characteristic) 可写,写入完成后Ble设备不需要返回响应 。 |
| Write | 0x08 | 该 特征 (Characteristic) 可写,写入完成后Ble设备需要返回响应。 |
| Notify | 0x10 | 该 特征 (Characteristic) 在值(Value) 改变的时候,Ble设备会发送通知。如果设置了此项，则客户端特征配置描述符CCCD(Client Characteristic Configuration Descriptor) 应存在。 |
| Indicate | 0x20 | 该 特征 (Characteristic) 在值(Value) 改变的时候,Ble设备会发送通知,需要Client (如手机)回复响应。如果设置了此项，则客户端特征配置描述符CCCD(Client Characteristic Configuration Descriptor) 应存在。 |
| Authenticated Signed Writes | 0x40 | 该 特征 (Characteristic) 对特征值进行签名认证才允许写入 。 |
| Properties | 0x80 | 该 特征 (Characteristic) 拥有扩展属性。在特性扩展属性描述符(Characteristic Extended Properties Descriptor) 中定义附加特性属性。如果设置，特性扩展属性描述符(Characteristic Extended Properties Descriptor) 应存在。 |
2.5.4-2 特征值声明(Characteristic Value declaration)
特征的核⼼部分，⼀般紧跟在特征声明后⾯，承载特征的真正内容。
| 属性句柄 (Attribute Handle) | 属性类型 (Attribute UUID) | 属性值 (Attribute Value) | 属性权限 (Attribute Permissions) |
|---|---|---|---|
| 0xNNNN | 0xuuuu16bit或128bit的 UUID | 服务(Service) 的 UUID (16bit或者128bit) | 只读（Read Only） 无需认证(No Authentication) 无需授权(No Authorization) |
2.5.4-3 特征描述符声明(characteristic descriptor declaration)
特征描述符声明(characteristic descriptor declaration) 以对特征(Characteristic) 进⾏进⼀步描述。
现阶段有一下类型：
0x2900:特征扩展属性0x2901:特征用户描述0x2902:客户端特征配置0x2903:服务器特征配置0x2904:特征描述格式0x2905:特征汇总格式
例如： 一个Profile中有一个温度计服务(Service)，这个服务(Service)包含一个只读的温度特征(Characteristic)和一个可读写的时间特征(Characteristic)。温度特征(Characteristic)又包含了一个温度值(value)，和温度单位的描述(Descriptor)；时间特征包含了一个时间值(value)和时区描述(Descriptor)。
这里以最常用的 CCCD(Client Characteristic Configuration Descriptor)客户端特征配置 为例：
| 属性句柄 (Attribute Handle) | 属性类型 (Attribute UUID) | 属性值 (Attribute Value) | 属性权限 (Attribute Permissions) |
|---|---|---|---|
| 0xNNNN | 0x2902 CCCD | 特性配置位 | 无需身份验证或授权即可读取。 可通过更高层规范定义的身份验证和授权写入，或者是特定于实现的。 |
| 配置的属性值 | 值 | 说明 |
|---|---|---|
| Notification | 0x0001 | 设置的话启用 Notify 。仅当特征的属性设置了 Notify 位时才能设置此值。 |
| Indication | 0x0002 | 设置的话启用 Indicate 只有在特性的属性设置了 Indicate 位时才能设置此值。 |
例如： 当一个特征(Characteristic) 的属性(Properties) 是Notify或者Indicate的时候。则需要设置客户端特征配置描述符CCCD(Client Characteristic Configuration Descriptor) [UUID:0x2902]来描述当前特征(Characteristic) 是否打开通知功能。也就是说通知功能是可以通过修改客户端特征配置描述符CCCD(Client Characteristic Configuration Descriptor) 的值(Value) 来主动打开或者关闭的。
4408
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
