蓝牙低功耗初级指南（Bluetooth Low Energy Primer）

Bluetooth LE primer

Bluetooth 的术语定义在 BLUETOOTH CORE SPECIFICATION Version 5.4 | Vol 1, Part A - 1.4 NOMENCLATURE

第一版 Bluetooth 技术为 Bluetooth BR (Basic Rate)，速度大概为 1Mb/s，随后又更新了 Bluetooth BR/EDR (Enhanced Data Rate)，速度达到了 2Mb/s，也称为 Bluetooth Classic。

Bluetooth Low Energy (LE) 第一次在 Bluetooth Core Specification v4.0 发布，用于替换 BR/EDR。

4. Bluetooth LE specification

Bluetooth LE 规范由以下部分组成：

4.1 Bluetooth Core Specification

Bluetooth Core Specification 是 Bluetooth LE 和 Bluetooth Classic 的基础规范，定义了其架构和层级。

4.2 Profile Specifications

当两个 Bluetooth LE 设备通信时，会形成 client/server 关系，server 会包含状态数据，而 client 则去使用这些数据。

假设有一个 Bluetooth key fob，其用途是帮助您在临时放置钥匙并暂时找不到时来重新定位。此时，smartwatch 可能作为 client 设备，而 Bluetooth key fob 则充当 server。按下 smartwatch 屏幕上的按钮会触发 key fob 的状态改变，并使其发出响亮提示音以响应此变化，从而帮助您找回钥匙。

Profile 规范定义了相关设备（如 smartwatch 和 key fob）所承担的角色，具体而言，它规定了 client 设备的行为规范，以及该设备应与已连接 server 上哪些数据进行交互。

4.3 Service Specifications

server 上的状态存储在正式定义的数据项中，这些数据项称为 characteristics 和 descriptors。characteristics 和 descriptors 被分组在称为 services 的结构内。services 为其包含的 characteristics 和 descriptors 提供了赋予意义与定义行为的内容。

一个 service 规范定义了一个独立的 service，包含其所属的 characteristics 和 descriptors。在 service 规范中，还定义了托管该 service 的设备的行为，包括如何响应不同情况及状态数据值。

一个 service 可以被看做一个 server 设备的行为。

在 smartwatch 与 key fob 的示例中，key fob 充当 server 并实现了 Immediate Alert Service。

4.4 Assigned Number

Bluetooth LE 使用 UUID 来定义 service、characteristic 和 descriptor 的类型，UUID 在 Bluetooth 又称为 assigned number，由 Bluetooth SIG 定义，详情查看 Assigned Numbers page

5. Bluetooth LE architecture

Bluetooth LE 由多个层级和多个模块构成，主要分为两个部分，Host 和 Controller，中间由 HCI (host controller interface) 连接。

LC3 (Low Complexity Communication Codec) 用于 Bluetooth LE Audio，不属于标准 Bluetooth LE 架构。

Figure 2 - The Bluetooth LE stack

Bluetooth LE mesh 则是另外一种架构

5.1 Bluetooth LE layer

Layer	Key Responsibilities
Physical Layer	Defines all aspects of Bluetooth technology that are related to the use of radio (RF) including modulation schemes, frequency bands, channel use, transmitter and receiver characteristics. Several distinct, supported combinations of physical layer parameters are defined and are referred to as PHYs.
Link Layer	Defines air interface packet formats, bit stream processing procedures such as error checking, a state machine and protocols for over-the-air communication and link control. Defines several distinct ways of using the underlying radio for connectionless, connection-oriented and isochronous communication known as logical transports.
Isochronous Adaptation Layer (ISOAL)	Allows different frame durations to be used by devices using isochronous communication. Performs segmentation and reassembly of framed PDUs or fragmentation and recombination of unframed PDUs.
Host Controller Interface (HCI)	Provides a well-defined functional interface for bi-directional communication of commands and data between the host component and the controller. Supported by any one of several physical transport implementations.
Logical Link Control and Adaptation Protocol (L2CAP)	Acts as a protocol multiplexer within the host, ensuring protocols are serviced by the appropriate host component. Performs segmentation and reassembly of PDUs/SDUs between the layer below and the layer above L2CAP.
Security Manager Protocol (SMP)	A protocol used during the execution of security procedures such as pairing.
Attribute Protocol (ATT)	A protocol used by an ATT client and an ATT server which allows the discovery and use of data in the server’s attribute table.
Generic Attribute Profile (GATT)	Defines high level data types known as services, characteristics and descriptors in terms of underlying attributes in the attribute table. Defines higher level procedures for using ATT to work with the attribute table.
Generic Access Profile (GAP)	Defines operational modes and procedures which may be used when in a non-connected state such as how to use advertising for connectionless communication and how to perform device discovery. Defines security levels and modes. Defines some user interface standards.

6.The Physical Layer

6.1 Frequency Band

Bluetooth LE 在 2400 MHz 至 2483.5 MHz 的 2.4GHz 免授权频段运行，该频段被划分为 40 个 channel，每个 channel 的间隔为 2 MHz。channel 的使用方式由 Link Layer 和 Data Transport architecture 定义。

6.2 Modulation Scheme

为了在传输前对来自协议栈更高层的数字数据进行编码，并对接收到的无线电信号进行解码，Bluetooth LE 采用了一种称为 Gaussian Frequency Shift Keying (GFSK）的调制方案。GFSK 的工作原理是：以选定 channel（carrier）的中心频率为基准，将信号向上偏移指定幅度以表示数字值 1，或向下偏移相同幅度以表示二进制值 0。通过对信号应用高斯滤波，可减少因频率突变可能伴随的噪声干扰。

6.3 PHY variants

定义了三种调制方案变体。每个变体被称为一个 PHY 并拥有专属名称。physical layer 的传输速率以 symbols per second（符号/秒）而非 bits per second（比特/秒）衡量，因为 physical layer 仅处理模拟无线电信号（analogue radio artefacts），不涉及数字概念。然而，Bluetooth LE 采用二进制调制方案，这意味着单个模拟符号对应协议栈更高层中的单个数字比特。

三种 Bluetooth LE 类型定义：

• The LE 1M PHY uses a symbol rate of 1 Msym/s with a required frequency deviation of at least 185 kHz and uses no special coding. All devices must support the LE 1M PHY.
• The LE 2M PHY is similar to LE 1M but uses a symbol rate of 2 Msym/s and has a required frequency deviation of at least 370 kHz. Support for the LE 2M PHY is optional.
• The LE Coded PHY uses a symbol rate of 1 Msym/s but packets are subject to a coding called Forward Error Correction (FEC) which is defined in the Link Layer. FEC increases the effective range of transmissions but reduces the application data rate. Support for the LE Coded PHY is optional.

三种 PHY 的比较

	LE 1M	LE Coded S=2	LE Coded S=8	LE 2M
Symbol Rate	1 Ms/s	1 Ms/s	1 Ms/s	2 Ms/s
Protocol Data Rate	1 Mbit/s	500 Kbit/s	125 Kbit/s	2 Mbit/s
Approximate Max. Application Data Rate	800 kbps	400 kbps	100 kbps	1400 kbps
Error Detection	CRC	CRC	CRC	CRC
Error Correction	NONE	FEC	FEC	NONE
Range Multiplier (approx.)	1	2	4	0.8
Requirement	Mandatory	Optional	Optional	Optional

定义

Term	Definition
Symbol Rate	The rate at which analogue symbols are transmitted at the physical layer.
Protocol Data Rate	The transmission rate of bits relating to Bluetooth protocol data units (PDUs) including their application data payload but excluding FEC data which is included in packets when the LE Coded PHY is in use.
Approximate Max. Application Data Rate	An approximate maximum rate at which application data can be communicated between applications on connected devices. Application data is transported in the payload part of various PDUs with the remainder of the protocol data rate being consumed by Bluetooth protocol data.
CRC	Cyclic Redundancy Check. A field used in the detection of transmission errors. This field and its use is defined in the Link Layer.

6.4 Time-Division

Bluetooth LE 是一个半双工协议，即传输和接收不能在同一时间进行，但是所用的 PHY 可以使用 TDD (Time Division Duplex) 方案，来让其表现得像全双工。

7. The Link Layer

7.1 Overview of the Link Layer

Link Layer 规范是 Bluetooth Core Specification 最大的一节，仅次于 Host Controller Interface Functional Specification，可以说是最复杂的一部分。

Link Layer 承担多项职责。它定义了通过无线传输的多种 packet 类型及关联的 air interface protocol，其运行遵循明确定义的状态机。根据所处状态，Link Layer 可能以多种截然不同的方式运行，由不同类型的事件驱动。定义了众多影响 link 状态或 link 使用参数的 control procedures。Radio channel selection 与 classification 机制在 Link Layer 规范中定义。

Link Layer 支持连接和无连接通信，以及确定性和（稍微）随机事件定时。它既支持两台设备之间的点对点通信，也支持一台设备并发到无限数量的接收设备的一对多通信。

7.2 Packets

这种 Packet 在 LE controller 规范中称为 Air Interface Packet

Link Layer 定义了两种 packet 类型，第一种用于未编码 PHY (LE 1M, LE 2M)，第二章用于编码 PHY (LE Coded)

Figure 7 - Link layer packet format for the LE uncoded PHYs

Figure 8 - Link layer packet for the LE Coded PHY

所有的 packet 类型都包含 Preamble，Access Address 和 CRC 字段。

Link Layer Packet Field Name	Description
Preamble	The preamble allows the receiver to synchronize precisely on the frequency of the signal, perform automatic gain control and estimate the symbol timing.
Access Address	The access address is used by receivers to differentiate signals from background noise and to determine the relevance or otherwise of a packet to the receiving device. For example, a pair of connected devices exchange packets with the same randomly allocated access address. Devices not participating in the connection will ignore such packets since the access address is not one that is relevant to them. Similarly, all legacy advertising packets use the same access address with a value of 0x8E89BED6 which indicates that these packets may be received by all devices.
CRC	The Cyclic Redundancy Check is used for error detection. Its value is calculated by the transmitter using the value of the other bits in the packet. On receiving a packet, the receiving device also calculates a CRC value from the values of bits in the received packet apart from those making up the CRC field. The receiver’s calculated CRC is then compared with the value of the CRC field in the packet. If the two CRC values match then the packet was received correctly. If not, it is deemed to contain one or more bits in error.

Link Layer packet 的 PDU (Protocol Data Unit) 字段可以包含多种不同类型的协议数据单元，具体取决于 Bluetooth LE 的使用方式。当使用其中一种方向查找方法（到达角度或离开角度）时，CTE (Constant Tone Extension) 才会出现。

PDU 和 CRC 字段在数据包传输之前会经过一个称为白化（whitening）的过程。白化的目的在于避免数据包中出现长序列的零或者一，因为这会导致接收器的频率锁漂移（drift）。接收器会反向执行白化过程，以恢复原始比特流，然后再进行 CRC 校验。

7.3 State Machine

Link Layer 由状态机管理，如图

关于各个状态的解释

State	Description
Standby	Device neither transmits or receives packets.
Initiating	Responds to advertising packets from a particular device to request a connection.
Advertising	Transmits advertising packets and potentially processes packets sent in response to advertising packets by other devices.
Connection	In a connection with another device.
Scanning	Listening for advertising packets from other devices.
Isochronous Broadcast	Broadcasts isochronous data packets.
Synchronization	Listens for periodic advertising belonging to a specific advertising train transmitted by a particular device.

处于 Connection state 时，定义了两个重要的设备角色：Central role 与 Peripheral role。发起连接并从 Initiating state 转换至 Connection state 的设备将担任 Central role；接受连接请求并从 Advertising state 转换至 Connection state 的设备则担任 Peripheral role。

以包含音乐播放器应用的智能手机和便携式 Bluetooth LE 音箱为例。通常，智能手机会承担 Central 角色，音箱则作为 Peripheral 角色。智能手机通过扫描音箱发送的 advertising packets 发现该设备，随后（通常在用户操作下）发起与该音箱的连接。连接建立后，根据相关 LE Audio 规范中定义的附加 procedures，音频流即可完成配置。

状态机实例（state machine instance）同一时间只能处于一种状态（state）。链路层实现（link layer implementation）可支持多个状态机实例（state machine instance）并发运行。

并不是所有的角色和状态组合都是允许的。Bluetooth Core Specification 对此有更多详细信息。

7.4 Channel Selection

如第 6.1 Frequency Band 所述，Bluetooth LE 将 2.4 GHz 频带划分为 40个channel。Link Layer 控制这些channel的使用方式，而这又取决于 Bluetooth LE 用于通信的整体方式（更正式地说，是当前的 physical channel——这是在 7.5 The Data Transport Architecture 中讨论的）。

Bluetooth LE 以多种不同方式使用扩频（spread spectrum）技术，通过多个channel在一段时间内进行数据传输。这降低了碰撞的可能性，从而使通信更可靠。

Bluetooth LE 中一个广为人知的扩频技术应用案例是 adaptive frequency hopping。该技术通过定期更换用于 packet communication 的 radio channel 来实现，具体 channel 的选择基于 channel selection algorithm 和一个名为 channel map 的数据表——该表将每个 channel 标记为 used 或 unused。系统可实时监测各 channel 的 communication quality，若发现某个 channel 因其他信号源干扰等原因性能下降，即可更新 channel map 将其标记为 unused，从而确保 algorithm 不再选择该 channel。通过这种方式，channel selection algorithm 能够根据实际环境动态调整，优化选择最可靠的 communication channel。

如何使用无线电channel将在下面讨论 Bluetooth LE logical transports 及其相关的 physicalchannel时进一步描述。

7.5 The Data Transport Architecture

注意：

这一节，在 BLUETOOTH CORE SPECIFICATION Version 5.4 | Vol 1, Part A - 3 DATA TRANSPORT ARCHITECTURE 有详细的描述，但是初学会容易让人混乱，所以这里重点强调。

Bluetooth Core system architecture 关注整体设计和框架，包括所有核心组件和协议的定义，例如 channel manager、link manager 等。

Bluetooth Data transport architecture 关注数据在蓝牙设备之间的传输过程，包括数据如何在不同的协议层之间被封装和传递。

这两个架构都是从不同角度去描述 Bluetooth 系统，并且都有各自的层次划分，一般应用开发者只需关注 Core system architecture。

Bluetooth Core Specification 的架构部分定义了一些概念，这些概念共同构成了 Bluetooth data transport architecture。其中关键的概念包括 Physical Channel、Physical Link、Logical Link 和 Logical Transport。为支持不同的应用类型，定义了某些组合，每种组合在拓扑、时序、可靠性和 channel 使用等问题上都有特定的要求。

Physical Transport 定义为在某个 RF channel (Physical Channel)上，通过采用一种或多种调制方案实现 PHY packet (air interface packet) 传输或接收。

Physical Channel 定义了使用 Bluetooth 进行通信的多种不同方式之一。例如，两个已连接的设备之间可通过 LE Piconet Physical Channel 进行通信，该 channel 涉及在 37 个 channel 上的自适应跳频。另一种方式是使用 LE Advertising Physical Channel 进行广播式、无连接的通信，允许单一设备向不限数量的其他设备发送数据。LE Periodic Physical Channel 也可用于广播数据，但需基于确定性的时间安排定期发送。Observer（接收端）设备能够识别该时间安排，并利用其同步自身的扫描调度计划。

Physical Link 基于单一特定的 physical channel，并规定了该链接的某些特征，例如是否使用功率控制。

Logical Link 和 Logical Transport 具有各种参数，这些参数旨在提供一种合适的方式，以支持通过 physical link 的特定数据通信要求，使用特定的 physical channel 类型。

例如，在 Bluetooth LE 中，可靠的双向点对点通信使用 LE asynchronous connection-oriented logical (ACL) transport，其中 LE-C link 用于控制数据，LE-U link 用于用户数据，通过基于 LE Piconet Physical Channel 的 Physical Link (LE Active Physical Link)。

另一方面，不可靠的单向广播通信使用 LE Advertising broadcast （ADVB）logical transport，其中 ADVB-C link 用于控制数据，ADVB-U link 用于用户数据，通过基于 LE Advertising Physical Channel 的 Physical Link (LE Advertising physical Link)。

7.6 The Logical Transports (uncomplicated)

该节未完成翻译

7.6.1 LE ACL - LE Asynchronous Connection-Oriented Logical Transport

7.6.1.1 Basics

当两个 Bluetooth LE 设备连接时，它们使用的是 asynchronous connection-oriented logical transport (LE-ACL，简称 ACL)。LE-ACL 是最常用的蓝牙低能耗逻辑传输类型之一，支持数据的面向连接（connection-oriented）通信。实际上，ACL 连接通常简称为连接。

设备可以通过发送一个请求连接的协议数据单元（PDU）来响应收到的广告数据包，从而与广告设备建立连接。请求中指定了一些参数。这些参数包括 access address、connection interval、peripheral latency、supervision timeout 和 channel map。

请求连接的设备从 Standby 状态过渡到 Initiating 状态，然后进入 Connection 状态并承担 Central 角色。另一个设备则从 Advertising 状态过渡到 Connection 状态，并承担 Peripheral 角色。

connection interval 参数定义了无线电多久（以毫秒为单位）可以用于服务该连接。每当 connection interval 到期时，就认为一个 connection event 开始，此时连接中的 Central 设备可以传输 packet 了。给定连接的 connection event 各自都有一个 16 位标识符，这是一个计数器值，在每个事件中递增。在每个连接事件开始时，使用适用的频道选择算法选择要使用的无线电频道。

supervision timeout 参数指定在两个 Link Layer data packets 接收之间可以经过的最大时间，在此时间之前，如果未接收到 packet，则认为连接已丢失。

Peripheral 设备与 Central 设备具有相同的连接参数，知道何时可以预期来自 Central 设备的传输数据包以及在哪个channel上，因此可以选择在精确的同一时间监听该channel，从而接收来自 Central 设备的 packet。Peripheral 可以在接收到 Central 设备 packet 的最后一位后 150 微秒（+/- 2μs）回复中央设备。然后 Central 设备和 Peripheral 轮流交替进行 packet 的传输和接收，在连接 connection event 可以交换实现定义的 packet 数量。请注意，Peripheral 的行为可能会受到非零 Peripheral Latency 参数值的影响。

通过 LE ACL 连接交换的数据包包含 LL Data PDU 或 LL Control PDU，这些 PDU 与 Link Layer 控制过程相关联。

10. The Logical Link Control and Adaptation Protocol

10.1 Basics

Logical Link Control and Adaptation Protocol (L2CAP) 负责协议复用、流量控制以及 service data unit (SDU) 的分段和重组。

L2CAP 使用channel的概念来分隔在协议栈各层之间传递的 packet 序列。固定channel无需设置，立即可用，并且与特定的高层协议相关联。channel也可以通过指定的 Protocol Service Multiplexer (PSM) 值动态创建并与某个协议关联。

10.2 L2CAP and Protocol Multiplexing

在 L2CAP 之上的协议栈中，使用了不同的协议层，如 attribute protocol (ATT) 和 security manager protocol (SMP)。L2CAP协议复用确保服务数据单元（SDU）被传递到协议栈中的适当层进行处理。

当 L2CAP channel处理 Attribute Protocol ，它要么使用一个为 ATT 保留的固定channel，在这种情况下被称为 unenhanced ATT bearer，或者使用一系列一个或多个动态channel，每个channel作为 enhanced ATT bearer。unenhanced ATT bearer 支持按顺序逐个执行的 ATT transaction。 enhanced ATT bearer 支持并行的 ATT transaction，这些事务在并行的L2CAPchannel中按顺序执行。有关详细信息，请参见 11. The Attribute Protocol。

10.3 L2CAP and Flow Control

Flow Control 关注的是确保协议栈中一个层产生的 packet 速率不超过同一协议栈中某一层或远程设备处理这些 packet 的速率。如果没有 Flow Control，就存在 buffer 溢出等问题的风险。

Credit based flow control 是流量控制的众多可能方法之一。其大致工作原理如下：

• 发送设备知道接收设备的容量，它可以在不丢失数据的情况下处理 PDU 的数量（例如，通过其缓冲区溢出）。它通过配置或在数据传输开始之前通过两个设备之间的交换来获取此容量信息。
• 传输器设置一个计数器来限制接收器的容量。每次传输器发送一个 PDU，计数器就减 1。当计数器值达到零时，传输方知道接收方已满负荷，因此在接收方处理其积压时，暂时停止发送进一步的 PDU。
• 在接收方读取并处理一个或多个 PDUs 后，它会向发射方发送相应数量的信用（credits），发射方利用这些信用来增加它的计数器（counter）。当计数器的值为非零时，发射方可以继续发送更多的 PDUs。

L2CAP定义了几种操作模式，主要与流量控制有关。

例如，ATT over an L2CAP unenhanced ATT bearer 使用 Basic L2CAP Mode，这种模式不提供 flow control。这使得 ATT 变得不可靠，应用程序必须考虑到传输的 ATT PDU 可能会被接收设备丢失的情况。对于像 notification 这样的 unacknowledged PDU，传输设备可以通过 link layer acknowledgements 知道 PDU 是否被远程设备的协议栈接收，但无法确定 PDU 是否成功传递到协议栈顶部的接收应用程序。

ATT over an L2CAP enhanced ATT bearer 使用 Enhanced Credit Based Flow Control Mode，这种模式提供了 flow control。因此，EATT 可以被视为可靠的。

10.4 L2CAP Segmentation and Reassembly

L2CAP 的上层和下层都受到 Maximum Transmission Unit (MTU) 大小的限制，该参数指定了由该层创建的 PDU 类型所允许的最大大小。例如，ATT_MTU 参数定义了 ATT PDU 的最大大小。

L2CAP 本身以及协议栈中其上层或下层的各层可能具有不同的 MTU 大小，因此可能需要将某些 PDU/SDU 拆分为一系列较小的部分，以便相邻层能够处理，或者相反，将一系列相关的较小部分重新组装为完整的 PDU/SDU。L2CAP 对上层应用的这些过程称为 segmentation 和 reassembly，而与 L2CAP 及其与下层关系相关的等效过程则称为 fragmentation 和 recombination。

11. The Attribute Protocol

11.1 Basics

attribute protocol (ATT) 由两个设备使用，一个设备扮演 client 的角色，另一个设备扮演 server 的角色。server 暴露一系列称为 attributes 的复合数据项。attributes 由 server 组织在一个称为 attribute table 的索引列表中。

每个 attribute 包含一个 handle、一个 Universally Unique Identifier (UUID)、一个 value 以及一组 permissions。

• handle 是一个唯一的索引值，ATT client 可以通过它引用 attribute table 中的特定条目。
• UUID 用于标识 attribute 的类型。
• permissions 字段是一组标志，指示是否允许读取、写入或两种访问形式，以及访问时必须满足的任何其他安全条件。
• Bluetooth SIG 学习指南 Understanding Security in Bluetooth LE 提供了有关 attribute permissions 的更多信息。
• attribute value 字段是一个字节数组，包含 attribute 的值。字节数组在数据类型和语义方面的解释由协议栈的更高层负责。

Generic Attribute Profile (GATT) 定义了 attributes 如何表示更高层次的构造，例如 services、characteristics 和 descriptors。通常，需要一组位于连续 handle 值范围内的 attributes 来表示这些更复杂的类型，而 attribute protocol 支持通过 handle 值范围标识的 attribute 组进行操作。有关更多信息，请参见第 12 节 The Generic Attribute Profile。

ATT 由 ATT client 用于发现 ATT server 中 attribute table 的详细信息，包括 attributes 的 handle 值或感兴趣的 attribute 类型。当 handle 值已知时，它们可以与某些 PDU 类型一起使用，以识别并操作表中的特定 attributes。例如，ATT_READ_BY_GROUP_TYPE_REQ PDU 可用于查找作为 primary service 定义一部分的所有 attributes 的 handle 和 UUID。简而言之，ATT_READ_BY_GROUP_TYPE_REQ PDU 可用于查找 attribute table 定义的所有 GATT primary services。

当使用支持 discovery operations 的 PDU（如 ATT_READ_BY_GROUP_TYPE_REQ）时，会指定一个 handle 范围，指示要搜索的 attribute table 条目的子集（可能是整个表），以及要查找的 attribute 类型。图 43 展示了这一过程，其中搜索所有 primary services，响应则指示包含与发现的 primary service 相关的 attributes 的 handle 值范围。

ATT 是连接中的 Bluetooth LE 设备应用程序相互交互的主要机制之一，它使用协议定义的 PDUs 以及更高层规范（如 Generic Attribute Profile (GATT)）中定义的过程。

ATT 定义了两种变体：基本的 ATT 和更新的 Enhanced Attribute Protocol (EATT)。
ATT 可以用于 Bluetooth LE 或 Bluetooth BR/EDR。在本文档中，仅考虑与 Bluetooth LE 一起使用的 ATT。

11.2 ATT PDUs

Attribute Protocol 定义了 31 种不同的 PDUs，每种 PDU 都基于六种广泛方法之一。

11.2.1 Commands

ATT command PDU 由 client 发送给 server，且 server 不会返回响应。一个命令的示例是图 44 中所示的 ATT_WRITE_CMD。

11.2.2 Requests and Responses

ATT request PDU 由 client 发送给 server。server 应在 30 秒内回复相应类型的 response PDU 或 error response PDU（ATT_ERROR_RSP）。未能在 30 秒内响应则构成超时。
一个 request / response PDU 配对的示例是图 45 中所示的 ATT_WRITE_REQ 和 ATT_WRITE_RSP PDUs。

11.2.3 Notifications

Notifications 是 server 发送给 client 的未经请求的 PDUs，类型为 ATT_HANDLE_VALUE_NTF。没有定义回复 PDU。参见图 46。

11.2.4 Indications and Confirmations

ATT indication PDU 由 server 发送给 client。client 应在 30 秒内回复相应类型的 confirmation PDU 或 error response PDU（ATT_ERROR_RSP）。未能在 30 秒内响应则构成超时。
一个 indication / confirmation PDU 配对的示例是图 47（Indications and Confirmations）中所示的 ATT_HANDLE_VALUE_IND 和 ATT_HANDLE_VALUE_CFM PDUs。

11.2.5 PDU Format

所有 ATT PDUs 都具有相同的结构，包括一个用于标识 PDU 类型的 opcode、一组 parameters 以及一个可选的 authentication signature。需要注意的是，signature 字段很少使用，并且在 attribute protocol 运行于加密链路上时是冗余的，因为链路层的所有加密数据包都包含认证数据。

11.2.6 Maximum Transmission Unit

ATT PDU 的最大长度取决于已建立的 Maximum Transmission Unit (MTU) 值。根据用于 ATT 的 bearer，可以使用两种机制之一来建立 MTU。

11.3 Transactions

ATT 定义了 transaction 的概念。client 发送的 Request PDUs 期望 server 在 30 秒内返回 response PDU。server 发送的 Indications 期望 client 在 30 秒内回复 confirmation PDU。每个 request/response 对或 indication/confirmation 对构成一个 transaction。如果 transaction 超时，则视为失败，并且不能使用当前的 bearer 发送任何类型的进一步 PDUs。

ATT 采用顺序事务模型。这意味着，若某个 ATT transaction 已启动，则在当前 transaction 完成前，同一 bearer instance 不得处理其他 ATT PDU。当从远端设备接收到预期的 response 或 confirmation PDU，或在等待 30 秒后 transaction 超时，该 transaction 即被视为完成。

11.4 Bearers

ATT 由下层的 L2CAP 层以两种方式之一处理，每种方式称为一个 bearer。这两种 ATT bearer 是 Unenhanced ATT bearer 和 Enhanced ATT bearer。使用哪种 bearer 会影响 ATT 的使用方式，在某些情况下还会影响协议的可靠性。Generic Attribute Profile 规定了 ATT 的使用方式，并声明，例如：

Unenhanced ATT bearer

• 使用固定的 L2CAP channel，因此只能存在一个此 bearer 的实例。
• 无论应用层有多少个 client 使用 ATT，transactions 都是严格顺序的。这意味着一个应用程序启动的 transaction 可能会延迟另一个应用程序希望启动的 transaction。
• 可以交换 ATT_EXCHANGE_MTU_REQ 和 ATT_EXCHANGE_MTU_RSP PDUs 以影响在 Unenhanced ATT bearer 上使用的 ATT MTU 的选择。
• 由于缓冲区溢出等问题而无法处理的 client 接收到的任何 notifications 都会被丢弃。因此，ATT_HANDLE_VALUE_NTF PDU 在 Unenhanced ATT bearer 上使用时被视为不可靠。
• 在使用 Unenhanced ATT bearer 时，对某些 PDU 类型（如 ATT_MULTIPLE_HANDLE_VALUE_NTF、ATT_READ_MULTIPLE_VARIABLE_REQ 和 ATT_READ_MULTIPLE_VARIABLE_RSP）的支持是可选的。
• 支持 Unenhanced ATT bearer 的 L2CAP channel 可以是未加密的或加密的。

Enhanced ATT bearer

• 使用动态的 L2CAP channels，允许多个 channels 和多个 bearer 实例。
• transactions 按顺序处理，但基于每个 bearer。因此，在协议栈内，可以并行处理 transactions，每个 transaction 由单独的 Enhanced ATT bearer 实例处理。这具有明显的优势，避免了某个应用程序使用 ATT 被另一个应用程序阻塞的可能性。
• ATT MTU 自动设置为 L2CAP 层使用的 MTU 值，并且在 Enhanced ATT bearer 上不允许使用 ATT_EXCHANGE_MTU_REQ 和 ATT_EXCHANGE_MTU_RSP PDUs。
• Enhanced ATT bearer 使用一种称为 Enhanced Credit Based Flow Control Mode 的 L2CAP 流控制方法。这使得在 Unenhanced ATT bearer 上不可靠的 PDUs 在使用 Enhanced ATT bearer 时可以被视为可靠。
• 在使用 Enhanced ATT bearer 时，对某些 PDUs（如 ATT_MULTIPLE_HANDLE_VALUE_NTF、ATT_READ_MULTIPLE_VARIABLE_REQ 和 ATT_READ_MULTIPLE_VARIABLE_RSP）的支持是强制性的。
• 支持 Enhanced ATT bearer 的 L2CAP channel 必须是加密的 channel。

11.5 Discovering Support for EATT

定义的 Generic Attribute Profile service 允许 client 确定连接的 server 是否支持 EATT，反之亦然，允许 client 通知 server 其支持 EATT。

若 server 支持 EATT，则必须在 Generic Attribute Profile service 中包含名为 Server Supported Features 的 characteristic。该 characteristic 数值的第一个 octet 的 Bit 0 设为 1 表示支持 EATT。GATT/ATT client 可通过读取该 characteristic 来判断 server 是否支持 EATT。

Client Supported Features characteristic 的数值由多个 bit 位构成，这些 bit 位表示客户端对特定功能的支持情况。Bit 1 表示客户端是否支持 Enhanced ATT Bearer，Bit 2 表示是否支持 ATT_MULTIPLE_HANDLE_VALUE_NTF PDU。客户端必须向该 characteristic 写入适当数值，以向 server 端通报其支持的功能特性。

12. The Generic Attribute Profile

Defined Generic Attribute Profile service

在 BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part G 的第 7 节。详细描述了 GATT 中 GATT service 的定义。

12.1 Basics

Generic Attribute Profile (GATT) 定义了基于 attribute table（见第11章 The Attribute Protocol）中属性的更高级数据类型。这些数据类型称为 services、characteristics 和 descriptors。它还定义了一系列通过 Attribute Protocol (ATT) 使用这些数据类型的相关 procedures。Application 通常使用映射到这些 procedures 的平台 APIs。

Services 是一种分组机制，提供了使用其所包含 characteristics 的 context，并具有定义的类型。通常，services 对应设备的主要功能或能力。

Characteristics 是状态数据的独立项，具有类型、关联值以及一组 property，这些 property 指示数据如何通过相关的 GATT procedures 使用。例如，可以定义连接的 peer device 可以读取特定 characteristic 的值，但不能写入它。

Characteristics 属于某个 service。相同的 characteristic 类型可以是多个 service 的成员，并且基于这些 service 提供的不同 context，使用 characteristic 的规则可能会有所不同。service specification 将提供这些详细信息。

Descriptors 属于某些 characteristics，可以包含元数据，例如 characteristic 的文本描述，或者可能提供控制 characteristic 行为的方式。Characteristics 可以附加零个或多个 descriptors。例如，GATT 定义了一种称为 characteristic value notification 的操作，涉及设备将包含 characteristic 值的 ATT PDU 异步发送到连接的对端设备，而不需要另一设备的响应。如果 characteristic 支持 notifications，通常 notifications 会在 characteristic 值更改时或由计时器控制的定期发送。但只有在对端设备请求 notifications 时才会发送，这是通过在特定类型的 descriptor 中设置标志来完成的，这种 descriptor 称为 Client Characteristic Configuration descriptor。如果 characteristic 支持 notifications，则必须具有此 descriptor。

GATT 定义了两个角色。GATT client 向 GATT server 发送 ATT 命令和请求。GATT server 接受并处理从 GATT client 接收到的命令和请求，并向 GATT client 发送 ATT notifications、indications 和 responses。

在所有 GATT server 中，有两个特殊 service 是必需的。它们是 generic access service 和 generic attribute service。

12.2 Bluetooth SIG vs Custom

一些 services、characteristics 和 descriptors 由 Bluetooth SIG 定义，并具有标识其类型的 16-bit UUID 值。Bluetooth SIG 定义的每种类型的列表可从 https://www.bluetooth.com/specifications/assigned-numbers 获取。实现者可以购买 16-bit UUID 和其他类型的 assigned number，详情请参阅 https://support.bluetooth.com/hc/en-us/articles/360062030092-Requesting-Assigned-Numbers。

实现者可以定义自定义的 services、characteristics 和 descriptors。自定义的 services、characteristics 和 descriptors 可以通过实现者分配的 128-bit UUID 值来标识，或者实现者可以从 Bluetooth SIG 购买 16-bit UUID 值。16-bit UUID 也有等效的 128-bit 值，形式为 0000XXXX-0000-1000-8000-00805F9B34FB，其中 XXXX 是 16-bit UUID 值。实现者不得使用此范围内的 UUID，除非从 Bluetooth SIG 购买了 UUID。

GATT server 可以仅包含 Bluetooth SIG 定义的 services、characteristics 和 descriptors（attributes），也可以包含 Bluetooth SIG 定义的 attributes 和自定义 attributes 的混合。

12.3 Procedures

GATT procedures 涵盖了 service discovery、characteristic discovery、descriptor discovery、读取和写入 characteristic values 以及 notifying 和 indicating characteristic values 等，这些 procedures 被定义在其中。GATT 规范提供了其 procedures 与底层 ATT 协议之间的清晰映射，这些 procedures 必须使用该协议。

12.4 Examples

12.4.1 Bluetooth SIG defined attributes only

图 50 展示了一组 services 及其 characteristics 的示例。其中一个 characteristic 具有关联的 descriptor。本例中的每个 attribute 均由 Bluetooth SIG 定义。

所示的 services 是实现了标准 proximity profile 的设备可能会包含的（immediate alert 和 TX power services 不是强制性的）。请注意 alert level characteristic 出现了两次，一次在 link loss service 中，一次在 immediate alert service 中。每种情况下 UUID 都是相同的。这正是将 characteristic 识别为 alert level characteristic 的依据。但是，characteristic 所属的 service 提供了不同的上下文，并且与 alert level characteristic 相关的规则和行为在这两个 services 中有所不同。

service changed characteristic 具有一个关联的 client characteristic configuration descriptor，因为该 characteristic 支持 notifications。任何支持 notifications 或 indications 的 characteristic 都必须具有 client characteristic configuration descriptor，因为其值（客户端可以写入）控制当前是否启用了 notifications 或 indications。

12.4.2 Mixture of Bluetooth SIG and Custom Attributes

图 51 展示了一个 GATT server，其中混合了由 Bluetooth SIG 定义的 GATT attributes 和一个包含单个自定义 characteristic 的自定义 service。该自定义 service 称为 proximity monitoring service，其 UUID 类型标识符值为 0x3E099910-293F-11E4-93BD-AFD0FE6D1DFD。其 characteristic 称为 Client Proximity characteristic，UUID 值为 0x3E099911-293F-11E4-93BD-AFD0FE6D1DFD。请注意，此 service 和 characteristic 用于教育开发者资源《An Introduction to Bluetooth Low Energy Development》中的项目工作。更多详细信息请参见第 16 节“Additional Resources”。

13. The Generic Access Profile

GAP service and characteristics for GATT

在 BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part C 的第 12 节，详细描述了 GATT 中对于 GAP service 的定义。

13.1 Basics

Bluetooth Core Specification 的 Generic Access Profile (GAP) 部分定义了与设备发现和两台设备之间建立连接相关的流程。GAP 还涵盖了如何执行无连接的数据通信、如何使用 periodic advertising（参见 7.7.3 PADVB - LE Periodic Advertising Broadcast）以及如何设置 isochronous communication（参见 7.7.5 LE BIS 和 LE CIS - Isochronous Communication）等主题。

此外，核心规范的这一部分还涵盖了一些关键的用户接口标准以及 Bluetooth LE 安全的某些方面。

Advertising 数据包（advertising）的传输及其通过 scanning 的接收过程，是 GAP 运作的核心机制。存在多种不同的 advertising 和 scanning 数据包类型，这些类型由 link layer 定义。需注意，载荷字段被称为 AdvData，且该字段并非存在于所有 PDU 类型中。当该字段存在时，其包含的数据会被编码为一系列被称为 AD Types 的长度/标签/值的结构体。AD Types 的定义详见 Core Specification Supplement（CSS）文档，该文档可在 bluetooth.com 的规范页面获取。

GAP 与 Bluetooth LE 和 Bluetooth BR/EDR 均相关。在本节的剩余部分中，仅讨论适用于 Bluetooth LE 的 GAP。此外，需要注意的是，尽管诸如 advertising 和 scanning 等活动对 GAP 至关重要，但这些过程实际上是由 link layer 执行的，所涉及的 PDU 类型也是如此。

13.2 Roles

GAP 定义了四种设备角色。这些角色在表 7 中列出并进行了说明。

Role	Description
Broadcaster	A device which uses some form of advertising to transmit data in a connectionless manner. This includes legacy advertising, extended advertising and periodic advertising. A broadcaster may also transmit a broadcast isochronous stream. A broadcaster has a transmitter but possessing a receiver is optional. A broadcaster does not accept connections from Central devices (unless it is also acting in the Peripheral role).
Observer	An Observer receives advertising packets or broadcast isochronous stream data packets. It does not connect to other devices, contains a receiver and may or may not contain a transmitter. The Observer is able to receive broadcast data in a connectionless manner.
Peripheral	A Peripheral can be connected to by a Central device. It contains a transmitter and a receiver.
Central	A Central is able to initiate the establishment of a connection with a Peripheral device. It contains both a transmitter and a receiver.

请注意，Central 和 Peripheral 这些角色名称也被 link layer 使用。在这两种不同的上下文中，这些术语的含义并不相同。

The GAP roles “Central” and “Peripheral” are related to, but not the same as, the Link Layer roles with the same names and therefore can have different requirements. If a connection is established successfully, the device with one of these GAP roles will also have the corresponding Link Layer role. However, the device can be in the GAP role without a connection being established.

13.3 Discovery

Broadcaster 或 Peripheral 设备要么处于不可发现模式（non-discoverable mode），要么处于 GAP 定义的两种可发现模式之一。当以不可发现模式进行 advertising 时，传输的数据包在无线环境中是可见的（这并不是一种安全特性），但执行 General Discoverable 过程或 Limited Discoverable 过程的 scanning 设备将忽略这些数据包。

可发现设备可能处于 General Discoverable 模式或 Limited Discoverable 模式。当处于 General Discoverable 模式时，设备在无限时间内可被发现，而在 Limited Discoverable 模式下，设备最多可被发现三分钟。

发现设备能够通过检查 AdvData 字段中名为 Flags 的 AD Type 来识别 advertising 设备处于哪种可发现模式。Limited Discoverable 模式通常用于优先处理用户最近交互过的设备，例如按下按钮或简单地拿起并移动设备。

当 Central 或 Observer 设备尝试发现其他设备时，它可能使用 passive scanning 或 active scanning。允许使用哪一种取决于该设备是否尝试发现处于 general discoverable mode 或 limited discoverable mode 的设备。

Passive scanning 涉及接收 advertising PDUs 而不发送任何 scanning PDUs。Active scanning 则涉及接收 advertising PDUs 并通过发送 scanning PDUs 请求更多信息。各类 PDU 类型由 link layer 定义，其概要可参见 7.7.2 ADVB - LE Advertising Broadcast 章节。

Bluetooth Core Specification 指出，部分设备仅使用 legacy advertising，而其他设备可能采用 extended advertising 或交替使用两种 advertising 形式。建议执行任一 discovery procedures 的设备交替对两种 advertising 类型进行扫描。同时建议设备在其支持的所有 PHY 上进行扫描。

图 52 展示了 GAP discovery modes 与其他相关变量的关联关系。

13.4 Connection Modes

Advertising 设备可通过使用的 PDU（legacy advertising）或 AdvMode 字段的值（extended advertising）来表明自身是否可被连接。
图52 展示了 GAP connection modes 与其他相关变量的关联关系。

设备可通过执行 GAP 定义的任一 connection-related procedures 请求与其他设备建立连接。这通常涉及发送 CONNECT_IND PDU（legacy advertising）或 AUX_CONNEXT_REQ PDU（extended advertising），作为对允许此类响应的若干类型接收 PDU 的回应。link layer 定义了 advertising 和 connection request PDU 类型，以及关于可响应发送 connection request 的 PDU 类型的规则。具体可参考 7.7.2.2.3 Legacy Advertising and Associated PDU Types 和 7.7.2.3.5 Extended Advertising and Associated PDU Types 章节。

13.5 Directed vs Undirected

GAP 使用的 advertising 可以是 undirected（非定向）或 directed（定向）。Undirected advertising 表示相关 PDUs 适用于任何接收它们的 Observer 或 Central 设备；directed advertising 则表示只有特定设备应处理此类 PDUs。涉及 directed advertising 的 PDUs 包含 TargetA 字段，其中包含目标接收设备的 Bluetooth address。在 undirected advertising 中，TargetA 字段不存在。

图52 在 GAP discovery 和 connection modes 的上下文中展示了 directed 与 undirected advertising 的关系。

需注意，AD Type Flags 会出现在通过 primary advertising channel 接收的 legacy advertising 数据包中。然而，当使用 extended advertising 时，AdvData 字段不存在于通过 primary channel 接收的 ADV_EXT_IND PDUs 中。若在 extended advertising 中使用 Flags，该字段会出现在 general-purpose channel 上的 auxiliary AUX_EXT_IND PDUs 中。

13.6 Scannable vs Non-scannable

部分 advertising PDU 类型被称为 scannable（可扫描）。这意味着接收此类 PDU 的设备可通过发送适当类型的 scan request PDU 来请求更多 advertising 数据。Advertising PDUs 由 link layer 定义，具体细节可参考 7.7.2.2.3 Legacy Advertising and Associated PDU Types 和 7.7.2.3.5 Extended Advertising and Associated PDU Types 章节。

13.7 GAP and LE Security

GAP 规范定义了若干 security terms、modes 及 procedures。通常，GAP security procedures 涉及协议栈的其他层级（如 Security Manager Protocol (SMP) 和 link layer），但利用这些层级实现特定安全目标的高阶流程定义在《Bluetooth Core Specification》第 3 卷 C 部分（Generic Access Profile）中，具体细节需参考该文档。

13.8 Periodic Advertising

Periodic Advertising 由 link layer 执行（参见 7.7.3 PADVB - LE Periodic Advertising Broadcast），但 GAP 规定了 Broadcaster 进入 periodic advertising mode 的流程，以及 Observer 与 periodic advertising train 同步的流程。此外，GAP 还定义了 Periodic Advertising Synchronization Transfer (PAST) 流程，该流程允许 Observer 从 Broadcaster 获取 periodic advertising 同步参数，并通过 ACL connection 将这些参数传递至另一设备。

13.9 Isochronous Broadcast

) 和 link layer），但利用这些层级实现特定安全目标的高阶流程定义在《Bluetooth Core Specification》第 3 卷 C 部分（Generic Access Profile）中，具体细节需参考该文档。

13.8 Periodic Advertising

Periodic Advertising 由 link layer 执行（参见 7.7.3 PADVB - LE Periodic Advertising Broadcast），但 GAP 规定了 Broadcaster 进入 periodic advertising mode 的流程，以及 Observer 与 periodic advertising train 同步的流程。此外，GAP 还定义了 Periodic Advertising Synchronization Transfer (PAST) 流程，该流程允许 Observer 从 Broadcaster 获取 periodic advertising 同步参数，并通过 ACL connection 将这些参数传递至另一设备。

13.9 Isochronous Broadcast

使用 broadcast isochronous streams 和 connected isochronous streams 实现的 Isochronous communication 由 link layer 负责执行（参见 7.7.5 LE BIS 和 LE CIS - Isochronous Communication），但 GAP 则规定了 Broadcaster 与 Observers 必须遵循的 procedures 以参与此类通信形式。