Bluetooth LE Primer Paper

Bluetooth SIG提供了大量关于Bluetooth LE的规范、论文和其他教学资源。本文的另一个目的就是为了让大家都意识到它们的存在、它们的用途以及使读者熟悉这个课题和它的辅助资料。绝大多数Bluetooth LE产品要么使用无连接通信(广播)和点对点连接通信的组合来交换数据，要么只通过广播包的方式通信。本资料覆盖了Bluetooth LE协议栈，它用在了上述类别的产品里面。相反地，Bluetooth mesh并没有包含在这里面。Bluetooth mesh是一种对Bluetooth LE的特别的用法，也需要参考其他信息资源。

创作本文的动机是新的Bluetooth LE audio标准的出现，即LE Audio。到目前为止，所有的Bluetooth audio产品都使用的是比较旧的Bluetooth技术，这就是经典Bluetooth—BR/EDR。LE Audio的出现可能意味着许多对经典Bluetooth和它在audio产品中使用有着相当丰富经验的专业人士，现在发现他们自己需要快速的了解Bluetooth LE。本文是为这些人写的，但也不仅仅为他们而写。如果你只是刚刚接触Bluetooth LE并且向学习它，你会发现这篇文章同样有用。所有不要奇怪上面的audio是倾斜的，现在你知道原因啦。

本文的目的不是复制或覆盖与正式规范完全相同的基础或相同的深度。在有意义的情况下，可时不时地包括规范的简要摘录。你应该把这篇文章看作是通过介绍和解释重要的Bluetooth LE概念，定位到其他资源和规范，并希望使学习曲线不那么陡峭。

Introduction

Bluetooth技术从2000就已经出现了。起初创造出来用于两个设备在没有中间网络设备介入的情况下交换无线数据。很快地，它就在无线鼠标和汽车免提套件等产品中找到了用武之地。后者是一个音频产品，音频被证明是Bluetooth技术原始版本的杀手级应用。到如今持续了多年。

Bluetooth技术的第一个版本，用于第一批Bluetooth产品，更正式地称为Bluetooth BR(Basic Rate)。它在物理层提供了每秒一百万bit(1Mb/s)的原始数据。

之后，更快的Bluetooth技术版本被称作Bluetooth BR/EDR(Enhanced Data Rate)。它提供了一个2Mb/s的原始数据速率，但是仍然用于两个设备彼此之间直接交换数据。

Bluetooth Low Energy (LE)第一次实现是在Bluetooth Core协议4.0版本。这是一个新的Bluetooth技术版本，而不是取代先前的版本—Bluetooth BR/EDR，作为一种替代方案，它的能力和品质使其成为新一代产品的完美选择，并能够满足新的、具有挑战性的技术和功能要求。

Bluetooth LE支持两个设备之间的点对点通信以外的拓扑结构，广播模式则允许一个设备同时向无限多个接收者传输数据。这也是Bluetooth mesh网络的基础，mesh网络允许成千上万的设备组成网络，其中任何一个都可以和网络中的另外一个进行通信。

面向连接通信和无连接通信都支持两个设备之间的一对一的通信。无连接广播支持一对多通信。

这个Bluetooth技术变种的最初设计目标之一就是其功耗使用的高效率。设想一下，设备使用硬币大小的电池能够持续运行数天、数周或者更长的时间，这种对于能耗效率的追求可以解释Bluetooth LE中定义的许多定义特征。

特别地，该设计将不对称的能力和责任分配给设备，力求确保具有相对丰富电能的设备(如大型智能手机电池)比使用硬币电池的对端设备承担更多的重担。这和其他的设计决策，比如让Bluetooth LE成为低功耗通信技术，使其在未来几年广泛应用与多种类型的产品中。

The Bluetooth LE Specifications

深入透彻的理解Bluetooth LE，需要熟悉其应用规范。Bluetooth LE

的架构、过程和协议都定义在一个关键的规范中，叫做Bluetooth Core Specification。产品如何使用Bluetooth以使其可互操作，由两种特殊类型的规范集合涵盖，叫做profiles和services。图一展示了Bluetooth LE规范了些和它们之间的关系。

图1 Bluetooth LE规范

The Bluetooth Core Specification

Bluetooth Core Specification是主要的Bluetooth LE和Bluetooth Classic规范。它定义了该技术的架构以及层级，描述和定义了其关键特性，并定义了构成重要操作的合规的步骤和在协议栈的给定的层级上使用的协议，设备间便可以进行通信。这是一个必要的庞大的规格。

Bluetooth Core Specification定义了Bluetooth技术怎样运行，开发者实现Bluetooth协议栈或者一个或多个功能的要求。

Profile Specifications

当两个Bluetooth LE设备在连接上进行通信时，通常组成客户端/服务器关系这种应用场景。服务器包含了状态数据，客户端以某种方式使用此数据。

比如一个Bluetooth钥匙扣，它的目的就是可以帮助你在把要是放到某个地方，临时又忘记放在哪里的时候可以找到它。智能手表可以作为客户端，而Bluetooth钥匙扣作为服务器。按一下智能手机显示屏上的按键，就会使钥匙扣的状态改变并且让它发出声响，以此来响应此状态的改变，这样你就可以找到你的钥匙了。

Profile规范了相关设备(比如智能手表和钥匙扣)所承担的角色，特别是定义了客户端设备的行为和一起运行的、连接的服务器上的数据。

在钥匙扣的例子中，智能手表或者某个其他设备的行为表现为Find Me Profile specification中定义的相同角色。

Service Specifications

服务器上的状态数据以characteristics and descriptors的数据项形式驻留。特征和描述符组合在称作services的结构中。服务提供了一个上下文，在该上下文中，在其中将定义和行为都分配给了服务所包含的特征和描述符。

服务规范定义了单个服务及其包含的特征和描述符。拥有这项服务的设备对于各种条件和状态数据值的响应所表现出的行为定义在了service specification中。

服务规范可以被视为定义服务器设备行为的一个方面。

在智能手表和钥匙扣的例子中，钥匙扣充当了服务器的角色，并实现了Immediate Alert Service.

Assigned Numbers

Bluetooth的各个方面都是用了唯一的标识符。比如，所有的服务、特征和描述符都有一个通用唯一标识符(UUID)，用于标识与之相关的服务、特征或描述符的类型，而不是在特定的设备上有所不同。公司可以通过唯一的公司标识符来识别，这是某些profiles所需要的。

Bluetooth SIG所分配的标识符被称作assigned numbers，可以在Bluetooth SIG网站上的Assigned Numbers page获取到整个标识符列表。

The Bluetooth LE Stack

High-Level Architecture

Bluetooth LE协议栈包含了许多的层级和功能模块，它们中的一些是强制性的，一些是可选的。协议栈的这些部分可以分配在两个主要的架构模块中，被称为host和controller，按照标准的逻辑接口定义的方式，两个部分可以进行通信。

主机通常就像操作系统一样。控制器就像片上系统。然而，情况并非如此，Bluetooth规范并没有强制要求此类的实现细节。重要的是，在次架构中，主机和控制器充当了独立的逻辑容器，可以以某种方式在物理上独立的组件中实现，并为它们之间的通信定义了标准的接口。这就允许Bluetooth系统由来源于不同的制造商的主机和控制器组件组合而成。

图2展示了Bluetooth LE协议栈，它跨越主机和控制器组件的层级和分布。

图2 Bluetooth LE协议栈

Host Controller Interface (HCI)显示了它们之间的逻辑接口，而不是物理组件。HCI可以在底层物理传输方面以多种不同的方式实现，但是逻辑或功能接口总是相同的。

LC3就是Low Complexity Communication Codec，与Bluetooth LE Audio一起使用的默认解码器。它不是标准的Bluetooth LE协议栈的一部分，但是总是会出现在LE Audio的产品中，如图所示，LC3组件可以在主机中或者在控制器中实现。

图3展示了通信系统的标准OSI参考模型。需要注意的是，相比于许多其它只是跨越了OSI的子层级，比如物理和数据链路层的无线系统来说Bluetooth LE协议栈跨越了OSI参考模型中的所有层。Bluetooth技术作为一个贯穿整个通信系统的协议栈拥有一个优势，就是不依赖与外部的其他标准。这种依赖可能阻碍技术的革新。

图3 OSI参考模型图4 Bluetooth mesh

Bluetooth mesh使用了具有链路层和物理层的Bluetooth LE控制器，而主机部分包含了实现Bluetooth mesh协议和过程的替代层集合。本文没有包括Bluetooth mesh，需求与此相关的教学资源的人应该参考后面的第16节Additional Resources。

The Layers at a glance

图2中所示的Bluetooth LE协议栈的各层的主要职责和功能总结如下:

层级	主要职责
PHY	定义了Bluetooth技术在radio使用方面的各个方面，包括调制方案、频带、通道使用、发射器和接收器特性。定义了若干不同的、受支持的物理层参数组合，称为物理层。
LL	定义了空口数据包的格式，bit流的处理过程(如错误检测)，以及无线通信和链路控制的状态机和协议。定义了使用底层无线电进行无连接、面向连接和isochronous通信的几种不同方式，被称作逻辑传输。
ISOAL	允许设备进行同步通信使用不同的frame durations。执行framed PDU的分段和重组，以及unframed的PDU的分段和重组。
HCI	为主机组件和控制器之间的命令和数据的双向通信提供了明确定义的功能接口。由多个物理传输实现中的任何一个支持。
L2CAP	充当主机内的协议多路复用器，确保协议由适当的主机组件提供服务。在L2CAP的下面层和上面层之间执行PDU/SDU的分段和重组。
SMP	执行安全过程(如配对)期间使用的协议。
ATT	ATT客户端和ATT服务器使用的协议，允许发现和使用服务器属性表中的数据。
GATT	根据底层属性表中的属性，定义了被称作服务、特征和描述符的高层数据类型。定义了使用ATT去处理属性表的更高级过程。
GAP	定义了在非连接状态下可以是有的操作模式和过程，比如如何使用广播进行无连接通信以及怎样执行设备发现。定义安全等级和模式定义某些用户接口标准

图2中描述的Bluetooth LE协议栈的每一层，都会更加详细的检查。

The Physical Layer

Bluetooth LE的物理层定义了radio发射器和接收器在发送和接收中怎样用于编码和解码数字数据，以及所使用的另外的与radio相关的参数和特性。

Frequency Band

Bluetooth LE运行在2.4GHz公共频带，范围从2400MHz到2483.5MHz，被分成了40个通道，每一个的宽度是2MHz。这些通道怎么使用是在链路层和数据传输架构中定义。

图5 Bluetooth LE通道

Modulation Scheme

为了在发送之前编码协议栈上层过来的数据以及接收时解码数据，Bluetooth LE使用了一种叫做Gaussian Frequency Shift Keying (GFSK)的调制策略。

GFSK工作原理是，通过取所选信道(载波)的中心频率的信号，并将其向上位移指定量以表示1，或向下位移指定量表示二进制0。高斯滤波应用于此信号以减少可能伴随频率突变的噪声。图6展示了基础的频移键控过程。注意，频率移动的量叫做频率偏差(frequency deviation)，并且至少是+/-185kHz或者+/-370kHz，取决于所使用的PHY的变体(PHY在6.3节中解释)。

图6 Bluetooth LE频移键控

PHY variants

定义了三个调制变体。每一个变体对应一种PHY并且有一个名称。物理层的传输速率是以symbol/s来测量的，而不是bits/s，这是因为物理层只处理模拟radio信号，而不是数字信号。然而，Bluetooth LE使用二进制调制策略，意味着单个模拟symbol就代表了协议栈更高层的一个数字bit。

三个PHY类型定义总结如下:

LE 1M PHY使用了1Msym/s的symbol rate，并且其频率偏移至少是185kHz，不适应特殊编码。所有的设备必须支持LE 1M PHY。
LE 2M PHY和LE 1M类似，但是使用了2Msym/s的symbol rate，并且其需要的频偏是370kHz。对于LE 2M PHY的支持是可选的。

LE Coded PHY使用了symbol rate为1Msym/s，但是数据包要经过链路层中定义的Forward Error Correction (FEC)的编码。FEC增加了有效传输范围，但是减少了应用的数据速率。对于LE Coded PHY的支持是可选的。

三个PHY变体比较如下:

	LE 1M	LE Coded S=2	LE Coded S=8	LE 2M
Symbol rate	1Ms/s	1Ms/s	1Ms/s	2Ms/s
协议数据速率	1Mbit/s	500Kbits/s	125Kbits/s	2Mbits/s
最大应用数据速率	800kbps	400kbps	100kbps	1400kbps
错误侦测	CRC	CRC	CRC	CRC
错误纠正	NONE	FEC	FEC	NONE
距离倍增	1	2	4	0.8
需求	M	O	O	O

术语	定义
symbol rate	物理层上传输的模拟符号的速率
协议数据速率	Bluetooth协议数据单元(PDUs)相关的bits传输速率，包括它们的应用数据载荷，但是不包括在使用LE Coded PHY时的FEC数据。
近似的最大应用数据速率	连接设备的应用之间，可以通信的最大应用数据速率。应用数据在各类PDU的载荷部分传输，协议数据速率的剩余部分由Bluetooth协议数据消耗掉。
CRC	Cyclic Redundancy Check。用于侦测传输错误的字段。该字段的和它的使用在链路层中定义。

Time-Division

Bluetooth LE radio时半双工的设备，可以发送和/或接收，但是，不是在同一时间。然而，所有的PHY都是按照Time Division Duplex(TDD)策略来使用，看上去radio就像全双工。

Transmission Power and Receiver Sensitivity

物理层定义了发射器的特征，包括了输出功耗要求，如规范中描述:

在设置为最大功耗时，输出功率应该介于0.01mW(-20dBm)和100mW(+20dBm)之间。

世界上的不同地区的监管机构可能无视这些要求，实现者必须确保设备符合适用的当地规范。

接收器灵敏度被定义为对于一个特殊的经验值Bit Error Rate (BER)的接收器输入电平。特定BER会因为接收的数据包的长度而变化，因为链路层会对每一个数据包附加一个Cyclic Redundancy Check (CRC)字段，并且将此机制用于检查解码的数据包中的一个或多个错误bit。因为数据包有长度的变化，但是每包只有一个CRC，所有数据包的长度会影响BER的计算。

关于Bluetooth LE接收器灵敏度的讨论中，通常引用BER为0.1%，即长度不超过37个字节的数据包的最大出错率。

另外的由物理层定义的接收器特性有，干扰性能、带外阻塞、互调特性、最大可用输入电平和需要的接收信号强度指示(RSSI)(如果支持的话)。

Antenna Switching

Bluetooth LE支持两种通过接收信号来计算方向的方法。第一种叫做Angle of Arrival (AoA)，另外一种叫做Angle of Departure (AoD)。这两种方法都涉及一个具有天线阵列的设备，以及在测向信号传输期间从一个天线切换到另一个天线的过程(AoD方法)或者接收信号时(AoA)。测向信号是包括Constant Tone Extension(CTE)字段的Bluetooth数据包。

天线阵列有许多不同的设计，从一个天线到下一个天线的切换可以遵循一系列不同的切换模式。这由主机控制，但物理层还定义了一些关于天线切换过程的一般适用规则、相关接收器要求和一些有用的定义。

Bluetooth Core Specification在Volume 6, Part A, section 5中涵盖此主题。关于AoA和AoD侧向功能的更多信息可以在Bluetooth Core Specification version 5.1 Feature Overview 中找到。

The Link Layer

Overview of the Link Layer

链路层规范几乎是Bluetooth Core Specification的Bluetooth LE 章节中的最大章节，仅次于Host Controller Interface Functional Specification章节。但可以说是最复杂的。

链路层有很多职责。它定义了通过空中传输的几种类型的数据包以及相关的空口协议。其操作约束在定义好的状态机中。根据状态，链路层可以按照许多完全不同的方式运行，由多种类型的事件驱动。定义了许多会影响链路状态或者链路使用参数的控制过程。Radio通道选择和分类在链路层规范中定义。

链路层对于连接的和非连接的通信都是支持的，以及支持确定的和稍许随机的事件时序。它支持两个设备之间的点对点通信以及同时从一个设备到无限多个接收设备的一对多通信。

Bluetooth LE的多用性大部分原因在于链路层的复杂性。

Packets

链路层定义了两种数据包类型。第一种用于uncoded PHYs(参见图7)，LE 1M和LE 2M，第二种用于LE Coded PHY(参见图8)。

图7 LE uncoded PHYs 链路层数据包

表格

描述已自动生成

图8 LE coded PHYs 链路层数据包

两种数据包都包含了Preamble, Access Address，和CRC字段。表1解释了这些普通字段。

链路层字段名称	描述
前导码	前导码允许接收器精确地同步信号频率，执行自动增益控制，并且估算symbol时序。
访问地址	接收器使用访问地址来区分信号和背景噪声，并且确定给接收设备的数据包是否相关或者无关。比如，已配对的两个设备使用同样的随机分配访问地址。没有参与到连接的设备将忽略这类的数据包，因为这个访问地址与它们无关。类似地，所有的传统广播包都使用相同的访问地址，该地址为0x8e89bed6
CRC	Cyclic Redundancy Check用于错误侦测。它的值是由发射器使用数据包中的其它bit位计算出来的。接收一个包时，接收设备也要通过接收包中除开构成CRC字段的bit来计算CRC值。接收器计算出的CRC来和包中的CRC字段的值进行比较。如果两者相符，则接收到的包时正确的，如果不相符，包被认为含有一个或多个错误bit。

表1 通用链路包字段

链路包的PDU字段可能包含各种不同的Protocol Data Units (PDUs)，由怎样使用Bluetooth LE来确定。Constant Tone Extension (CTE)只出现在两种测向方法((Angle of Arrival or Angle of Departure)中的一种被使用时。

包被发送之前PDU和CRC字段需经历whitening过程。白化的目的是避免包中有常的0序列或者1序列，那会导致接收器频率锁定漂移。接收器会反转白化过程，以此在CRC检查之前获取原始的bit流。

PDU字段可以被加密，在此情况下，它将包含一个Message Integrity Check字段，用于保护PDU不被篡改。

当使用LE Coded PHY时，bit流在发送前要经历附加的处理。Forward Error Correction (FEC)编码器的应用，接着是Pattern Mapper生成附加数据，用于接收器执行这些过程的逆过程，并且在可能时，纠正任意错误的bit值。

State Machine

链路层由图9中的状态机管理。

参考链路层规范以获取每个状态的详细信息。表2中有一个总结。

注意，有些术语将在本章的后面加以解释。

图9 链路层状态机

State	描述
Standby	设备没有发送和接收数据包
Initiating	响应某个特定设备的广播包，以此请求连接
Advertising	发送广播数据包，潜在地，处理其他设备响应广播包发送的数据包。
Connection	与另一个设备处于连接状态
Scanning	监听其他设备发送的广播包
Isochronous Broadcast	广播isochronous数据包
Synchronization	监听由特定设备发出的特定广播序列的周期性广播

表2 链路层状态

在Connection状态，定义了两个重要的设备角色。它们是Central和Peripheral。发起连接，并且由Initiating状态转换成Connection状态的设备作为Central。接收连接请求，并且从Advertising状态转换成Connection状态的设备作为Peripheral。

举个例子，安装有音乐播放应用程序的智能手机和便携式Bluetooth LE扬声器。通常，只智能手机会作为Central，并且扬声器作为Peripheral。智能手机通过扫描他的广播包来发现扬声器，然后通常在用户的参与下，启动与扬声器的连接。一旦连接上了，随后的附加过程已经在LE Audio规范中定义，音频流就建立好了。

某个时间，一个状态机的实例只能处于一种状态。链路层的实现可以同时支持一个以上的状态机实例。

注意，所有的角色和状态组合都是允许的。Bluetooth Core Specification会有详细的说明。

Channel Selection

如6.1节Frequency Band中描述，Bluetooth LE将2.4GHz频带分成了40个信道。链路层如何使用这些信道，而又取决于Bluetooth LE被用于通信的整体方式(更正式地，当前物理信道，这将会在7.6节Data Transport Architecture中解释)。

Bluetooth LE以各种不同的方式使用扩频技术，以此在一段时间之内通过多个信道进行数据通信。这就减少了冲突，让通信更加可靠。

Bluetooth LE中使用的一个著名的扩频技术就是adaptive frequency hopping。这需要用于数据包通信的无线信道按照一定的间隔改变。信道是通过信道选择算法以及一个用于将每一个信道区分为“可使用”或“不可使用”的信道、被称作信道映射表来选择的。在实现中，可以监控每一个信道的通信质量，如果一个信道表现很差，可能是来自其他信号源的干扰，在信道映射就会更新并将其归类在“不可用”，这就能确保此信道不再被算法选中。以这种方式，信道选择算法就可适应正在经历的状况，并且得到优化，获得最可靠的性能。

怎样使用radio信道会在后续Bluetooth LE logical transports和与之相关的物理信道的讨论中详细描述。

Device Addresses

Bluetooth LE设备有一个地址，作为设备标识用在某些链路层的空口包中。设备地址长度是48-bit，并且定义了几种类型。

全部细节可以在Volume 6, Part B, Section 1.3 of the Bluetooth Core Specification中找到。

Public Device Addresses

Public devices addresses是由Institute of Electrical and Electronics Engineers来分配的。

Random Device Addresses

Random device addresses是随机分配的，但是必须满足Bluetooth Core Specification中描述的规则。随机地址有三个子类型，static、private以及private non-resolvable。

随机地址的子类型可以通过检查地址中最高的两个bit来确定。

最高两bit	子类型
0b00	Non-resolvable private地址
0b01	Resolvable private地址
0b10	保留使用
0b11	Static device地址

Static addresses

静态地址是随机产生的，但是为了保护设备的隐私性，不会以任何方式伪装。每次power-cycled设备都允许使用一个重新生成的静态地址，但是没有要求这样做。在另外的时间点是不允许更改静态地址的。

实例: CC:C1:EE:7B:71:96是一个静态地址。可以通过把最高字节(0xCC)转换成二进制来验证，0b11001100，最高两位0b11，依据7.5.2 Random Device Addresses的表格，表明这是一个static device address。

Non-resolvable Private Addresses

non-resolvable private address是随机产生的，通常在每次重新连接的时候更改。它可以提供私密性，而且不需要通过查找如7.5.3中的 Filter Accept List来处理resolvable private addresses而付出代价。

实例: Example: 2C:C1:EE:7B:71:96是一个non-resolvable private address。可以通过把最高字节(0x2C)转换成二进制来验证，0b00101100，最高两位0b00，依据7.5.2 Random Device Addresses的表格，表明这是一个non-resolvable private address。

Resolvable Private Addresses

resolvable private address(RPA)是周期性变化的。Bluetooth Core Specification建议的周期是15分钟，但最终这个掌控RPA更改的时序，是由具体实现来决定的。

实例: Example: 4C:C1:EE:7B:71:96是一个resolvable private address。可以通过把最高字节(0x4C)转换成二进制来验证，0b01001100，最高两位0b01，依据7.5.2 Random Device Addresses的表格，表明这是一个resolvable private address。

生成RPA的过程涉及一个叫做Identity Resolution Key (IRK)的密钥，该密钥是在两个设备进行绑定时进行交换的，生成RPA的过程涉也涉及哈希函数的应用。已绑定的设备可以使用相同的哈希函数，并且应用来自于绑定设备的IRK值来解析接收包中的RPA，一次一个。当处理过程的结果与收到的RPA相匹配时，设备就明确已经解析出了地址，远端设备的真正标识符。没有与发送设备相互绑定的设备不能解析出RPA。

实例: Example: 5A:C1:EE:7B:71:96是一个resolvable private address。可以通过把最高字节(0x5A)转换成二进制来验证，0b01011010，最高两位0b01，依据7.5.2 Random Device Addresses的表格，表明这是一个resolvable private address。

Filter Accept List

链路层包含了一个特征叫做Filter Accept List。该列表可以填充主机有兴趣从其接收数据包的设备的地址。Bluetooth Core Specification中定义了一系列不同的filter policies，并且定义了当一个设备的地址在或者不在此列表时，该怎样处理。

Filter Accept List的一个好处是允许控制器高效地选择需要向协议栈上层传输到主机的数据包，而丢掉不需要的包。

Resolvable private addresses可以添加到Filter Accept List中，但是其处理过程会使控制器付出一些代价。因为RPA会周期性的改变，存在Filter Accept List中的是解析过的地址，因此，必要时，为了检查RPA是否存在列表中，控制器必须首先解析收到的RPA。

The Data Transport Architecture

Bluetooth Core Specification的architecture章节定义了许多的概念，这些概念共同构成了Bluetooth data transport architecture。这些概念的关键就是Physical Channel、Physical Link、Logical Link和Logical Transport。定义了某些组合，用于支持不同的应用类型，每个组合对拓扑、时序、可靠性和信道使用等方面都有特殊要求。

Physical Channel定义了使用Bluetooth进行通信的几种不同方式之一。比如，通信可以发生在两个已经连接了的、使用LE Piconet Physical Channel的设备之间，这涉及贯穿37个信道的自适应跳频。又或者，LE Advertising Physical Channel可以用于广播，从一个设备到另外无限多个设备的无连接通信。LE Periodic Physical Channel也可用于广播数据，但是定期使用确定的时间表。Observer(接收器)设备能够确定那个时间表，并且用它来同步它们的扫描时间表。

Physical Link是基于单个、特定的物理信道并且明确该链路的某些特性，比如是否使用功率控制。

Logical links and transports有许多的参数，设计这些参数是为了满足在使用特定的物理信道类型的物理链路上，支持一系列特定的数据通信需求。

比如Bluetooth LE中reliable、bi-directional、point to point通信使用基于LE Piconet Physical Channel的物理链路的LE asynchronous connection-oriented logical (ACL)传输，其中，LE-C链路用于控制，LE-U链路用于用户数据。

另一方面，Bluetooth LE中unreliable，unidirectional广播通信使用基于LE Advertising Physical Channel的物理链路的LE Advertising Broadcast (ADVB)逻辑传输，其中，ADVB-C链路用于控制数据，ADVB-U数据用于用户数据。

The Logical Transports

LE ACL - LE Asynchronous Connection-Oriented Logical Transport

Basics

两个已连接的Bluetooth LE设备使用asynchronous connection-orientedlogical transport (LE-ACL，简称ACL)。LE-ACL是Bluetooth LE中最常用的逻辑传输类型之一，用于connection-oriented通信数据。事实上，ACL连接通常简称为连接。

设备可以通过使用请求连接的PDU来响应收到的广播包来与广播设备建立连接。在此请求中会明确许多的参数。这些参数有: access address、connection interval、peripheral latency、supervision timeout和channel map。

请求连接的设备从Standby状态变成initiating状态，然后进入连接状态并且取得Central角色。另一个设备从Advertising状态变成Connection状态并且取得Peripherial状态。

The connection interval参数以ms为单位，定义了radio可以维护此次连接多长时间。当connection interval超时，connection event就开始了，这个时间点，连接中的Central设备可以发送一个包。对于给定的一个连接的连接事件，每一个都有一个16bit的标识符，它是一个计数值，每次连接事件就增加。在每次连接事件开始，要使用的radio信道通过适当的信道选择算法来选择。

supervision timeout参数明确了两个链路层数据包之间的最大间隔时间，超过的话就会认为连接丢失。

具有和Central设备相同协商参数的Peripheral设备，知道何时、在那个信道可以从Central设备收到发送的数据包，所以可以选择在精确的同一时间监听该信道，以此收到来自Central的数据包。Peripheral可以在收到来自Central数据包的最后一个bit之后150us(+/-2us)回答Central设备。然后，Central和Peripheral轮流在发送和接收数据包之间交替，并且可以在连接事件期间交换有实现来定义数量的数据包。注意，Peripheral的行为可以通过non-zero的Peripheral Latency参数值来改进。

图10数据包基础的交换，在两个连接事件之间，C>P表示由Central到Peripheral的数据传输，P>C表示相反过程。

图10 LE-ACL连接上的基本数据包交换

LE ACL上交换的数据包包括了LL Data PDUs或者LL Control PDUs，它们与链路控制过程相关。

Ordering and Acknowledgements

LE-ACL包含一个系统，该系统确保以正确的顺序处理数据，可以确认数据包的接收，并将其用于决定是否继续下一个数据包，还是重新发送前一个数据。

数据包包含有助于通信可靠的三个重要字段。这些字段叫做Sequence Number (SN)、Next Expected Sequence Number (NESN)和More Data field。所有这三个字段都是单比特字段，它们的使用提供了一个确认系统和一种用于检查接收数据包的正确顺序的方法。

通信始于主设备(设备 A)发送一个SN和NESN都设置成0的链路层数据包。从此之后，在发生的每个数据包交换时，如果一切正常，由设备A设置的SN字段的值，会在0和1之间交替。因此，辅助设备(设备B)总是知道下一个将接收到的数据包的SN值是什么，并且检查这一点。

如果设备B从设备a接收到具有预期SN值的数据包，则它用链路层数据包进行响应，该数据包将NESN设置为逻辑值NOT（SN）。因此，例如，如果接收到的SN值为1，则响应中的NESN将为0。当设备A从设备B接收到响应时，NESN设置为设备A打算在其下一个数据包中用于SN的值，设备A将其视为来自设备B的确认，确认其正确地接收了最后发送的分组。图11展示这个过程。

图11 成功的链路层数据包的交换

如果设备B接收到具有错误SN值的数据包，则它假定该数据包是接收到的前一数据包的重传，确认该数据包，但不将其传递到协议栈上层以供进一步处理。

如果设备A在来自设备B的回复中接收到意外的NESN值，或者根本没有接收到回复，则它重新发送具有与最初使用的相同SN值的数据包。不同的控制器实现可以自由地实现关于在结束通信失败之前重发多少次的不同算法。参见图12。

图12链路层重传

每个数据包含CRC字段，加密包也包含MIC字段。一旦收到数据包，链路层就会检查CRC，如果存在的话也会检查MIC。如果任意检查失败，则数据包不被确认，这通常导致数据包的发起者重新发送数据包。参见图13。

图13链路层处理CRC错误

Peripheral Latency

Peripheral不需要监听在每一个连接事件期间，Central发送的数据包。peripheral latency参数就定义了Peripheral可以连线几个连接事件不去监听。这可以使Peripheral省电。

图14展示了peripheral latency = 1时Peripheral的行为，以此指示监听交替连接事件。Central可以在Peripheral没有监听这些事件时发送，但是这类的数据包不会被接收到，以此也不会被应答，从而结束连接事件。

图14 ACL connection with Peripheral Latency = 1

Channel Use

LE-ACL使用的策略叫做adaptive frequency hopping。在每次连接事件的开始，调频就会出现，使用的radio信道由信道选择算法在一系列可用的信道中确切地选择出来。连接中的每一个设备都会切换到所选择的信道上，随着时间的推移和一系列连接事件，将使用分布在2.4GHz频带上的一系列频繁改变的信道上进行通信，从而大大降低冲突的概率。Bluetooth LE定义的40个信道中，37(称为通用信道)可供LE-ACL连接使用。

在给定环境中，某些Bluetooth无线信道可能无法正常工作，可能是因为干扰正在影响它们，而其他信道工作可靠。随着时间的推移，随着环境中其他无线通信设备的来去，可靠信道和不可靠信道的列表可能会改变。

连接中的Central设备维护了一个channel map，它将通用信道分类成“可用的”和“不可用的”。这个信道映射是通过链路过程和Peripheral分享的，它们对于哪些信道“可用的”，哪些“不可用”是有相同信息的。信道选择算法可以确保信道指定可以避开那些“不可用的”。

默认的所有通用信道都被指定为“可用的”，但是Central设备可以使用特定于实现的技术去监控每一个信道的工作情况。如果Central确定一个或多个信道工作状况不好，它可以更新这些信道在信道映射中的类别为“不可用”。相反的，如果发现先前的一个bad信道工作状况良好，就可以将其在信道映射中的分类跟新为“可用的”。然后，信道映射更新会与Peripheral设备共享。

Peripheral也可以执行自己的信道监控，并且在空隙时，将通道状态报告给Central，每个信道分类为good, bad 或者 unknown。然后，Central可以确定带信道在信道映射中的分类，同时会将自己的和Peripheral正在经历的radio状况考虑进去。

通过这种方式，Bluetooth LE就可能只使用可用信道中优化过后的子集。例如，与使用静态分配信道的其他无线技术有效共存。这就是Bluetooth adaptive frequency hopping系统的adaptive方面。

注意: 监管机构可以定义与Bluetooth Core Specification不同地adaptive frequency hopping相关术语。建议在产品开发生命周期的早期审查有关目标市场频谱使用的法规，因为这可能会为某些实施决策提供信息。

图15展示了测试期间两个连接设备使用信道的方式，也展示了radio使用在ISM 2.4 GHz频谱上扩展的方式。图标的底部，你可以看见channel index和frequencies in MHz。channel index是引用radio信道的间接方式。

图表, 条形图, 直方图

描述已自动生成

图15 自适应跳频、跨信道分布式通信

Link Layer Control

链路层规范明确了许多控制过程。一系列例子如表3所述。

控制过程	描述
Connection Update	允许Central或者Peripheral请求改变连接参数，如connection interval、peripheral latency和supervision timeout
Channel Map Update	允许Central将最新的信道映射发送给Peripheral
Encryption	允许Central或者Peripheral使能数据包加密
Feature Exchange	允许Central或者Peripheral开启每个设备支持的链路层特性交换，按照bitmap编码
Periodic Advertising Sync Transfer	允许Central或Peripheral通过LE ACL连接向另一设备传送与已发现的周期性广告序列相关的周期性的广告同步信息。
CIS Creation Procedure	允许Central设备与Peripheral创建Connected Isochronous Stream
Power Control Request	允许一端请求另外一端调整发射功率。
Channel Classification Reporting	允许Peripheral向已连接的Central报告信道分类数据

表3 链路层控制过程实例

Subrated Connections

Subrated连接是LE ACL连接，具有以下附加的特性，某些方面表现不同。附加的特性叫做subrate factor、subrate base event以及continuation number。

Subrated连接特性提供了一种机制，用于指示只有特定的连接事件的子集才能被已连接的设备使用，radio在其他的连接事件中不能被使用。因此，subrated连接有较短的ACL连接间隔，但是仍然表现出低占空比。

图16展示了与subrated相关的基础概念。

图16 Abasic subrated connection with subrate factor=5

我们可以看见在上述的5个连接事件中，只有一个可以使用。另外的4个被跳过了，因此在这些连接时间中没有radio活动。“使用的”对“跳过的”连接事件比例是由subrate factor参数决定，在此例中设定为5。

radio用来发送和接收链路层数据包的连接事件就叫做subrated connection event。

在给定的基于ACL连接参数和控制connection subrating之间的关系，在subrating参数被使用之后，subrated连接可以被认为是同时具有用于控制ACL连接事件的频率的连接间隔和决定这些ACL连接事件可以被实际用到的effective连接间隔。

Subrated连接使用了不同的链路控制过程集合，特别地，subrated连接参数的更新过程与通常的Control Update过程不同。至关重要的是，对于subrated连接参数的更改几乎可以瞬间被使用，而对于通用参数的修改需要花费大量的事件才能起作用。因此，subrated连接的优势就是可以建立具有低占空比和消耗很少功率的持久连接，并且可以让任何用户注意到的无延迟地切换到高占空比，高带宽连接。该功能在某些LE Audio场景中具有特别的适用性，例如涉及助听器和智能手机的场景。

Bluetooth Core Specification Version 5.3 Feature Enhancements中有一章专门讨论了subrated连接的主题，建议作为更多信息的来源。

ADVB - LE Advertising Broadcast

Basics

LE Advertising Broadcast (简称advertising)提供了一种无连接的通信模式。可以被用在传输数据或者指示Peripheral设备被连接的可行性。

通常来说，广播包用于在范围内的扫描设备接收，因此，广播可以用于同时向多个扫描设备传输数据，按照一对多拓扑结构。然而定义了一种特别形式的广播叫做directed advertising，它允许无线通信数据从一个设备到另一个特定的扫描设备，通过Bluetooth设备地址来标识。

广播本身仅仅支持单向的数据通信，从广播设备到扫描设备，但是此类设备可能会以请求更多信息或者建立连接的PDU来回答广播包。当扫描设备回答要求获取更多的信息时，就说它正在做active scanning。如果没有，就说它在做passive scanning。

广播通常是一种不可靠的传输，因为接收者不会发送应答。

Bluetooth Core Specification定义了两种类型的广播过程，legacy advertising和extended advertising。

Legacy Advertising

Channel Use and Packet Size

Legacy advertising packets使用ADV_IND PDU类型(参见7.7.2.2.3 Legacy Advertising以及Associated PDU类型)，有37个字节，其中6个字节是header，最多31个字节的payload。相同的广播包会在专用的信道37、38和39上面发送，这些信道叫做primary advertising channels，一次一个信道，按照某种顺序。

图17 legacy advertising和信道的使用

Scheduling

广播包的传输发生在任意advertising event出现的时候。

广播包的时序是由时序参数控制的，并且在基本情况下，故意使其稍微的不规则一点，这样就可以避免和其他广播设备出现持续的冲突。

在每次advertising event时，叫做advDelay的参数使用一个0~10ms的伪随机数，把它加在不变的advertising interval(advInterval)上，这样的话，advertising event在时序上就有波动。

图18 使用advDelay让Advertising events波动

按这种方式安排advertising events可以帮助避免冲突，但是也让接收者很难高效的接收广播包，需要更高的RX占空比以适应不可预知广播事件时序。

Legacy Advertising and Associated PDU Types

定义了几个与legacy advertising一起使用的PDU类型。不同类型的PDU用于以任何扫描设备为目的的undirected advertising数据包，以寻址到一个特定设备的directed advertising数据包。PDU类型也表明了允不允许active scanning(接收者以请求更多的数据来应答)，该广播设备允不允许被连接。所有的legacy advertising都发生在一个或更多的primary channels，37，38和39，可以只使用LE 1M PHY。

表4列出了legacy advertising PDUs。

PDU 名字	描述	通道	PHY	发送者	可扫描否	可连接否
ADV_IND	Undirected advertising	primary	LE 1M	Peripheral	Y	Y
ADV_DIRECT_IND	Directed advertising	primary	LE 1M	Peripheral	N	Y
ADV_NONCONN_IND	Undirected non-connectable non-scannable advertising	primary	LE 1M	Peripheral	N	N
ADV_SCAN_IND	Undirected Scannable advertising	primary	LE 1M	Peripheral	Y	N
SCAN_REQ	Scan request	primary	LE 1M	Central	N/A	N/A
SCAN_RSP	Scan response	primary	LE 1M	Peripheral	N/A	N/A
CONNECT_IND	Connect request	primary	LE 1M	Central	N/A	N/A

表4 Legacy Advertising PDUs

Bluetooth Core Specification中Link Layer规范的章节由全部详细的PDU类型。

Extended Advertising

第5版Bluetooth Core Specification对如何执行广播进行了一些重大的更改。8个有关advertising、scanning以及connecting的新PDU加入了进来并且定义了新的过程。这些广播能力合在一起共同称为extended advertising。

Extended advertising允许多很多的数据用于广播，允许广播按照确定好的时序执行，并且，允许发送多种因不同配置而影响的、有区别的广播数据集。它也提供了对竞争和占空比的重要改进。

Extended advertising用于ADVB和PADVB逻辑传输。

Channel Use and Packet Size

radio信道的使用方式与执行legacy advertising时不同，primary advertising信道37、38以及39承载少量的数据general-purpose信道0~36承载大部分数据。在extended advertising语境下，general-purpose信道也被称作secondary advertising信道。

如7.7.2.2 Legacy Advertising中描述的，legacy advertising在三个不同的primary advertising信道上，传送相同的载荷，最多三次。Extended advertising仅仅传送一次载荷，载荷小小的header来自于primary信道。因此，同等情况下，传送数据的总量是小于使用legacy advertising的，所有有效占空比是减少的。

图19 减少了的contention and duty cycle

图20 Extended advertising支持更大的广播包和信道负载

Extended advertising允许达到255字节长度的包。这是通过将部分的负载丢到编号0~36的secondary信道来完成的。

当执行extended advertising时，primary信道37、38和39上只传输header数据。它包含量叫做AuxPtr的字段。

AuxPtr字段引用将要在编号0~36的secondary信道上传输的、里面含有payload的auxiliary packet。AuxPtr包含了auxiliary packet将要在哪个general-purpose信道上传输的索引，这样的话，接收者就知道在哪里去找到它了。在secondary信道上面传输、引用来自primary上的包的AuxPtr field字段的包叫做subordinate包，而引用的数据包叫做superior包。

AuxPtr中，信道选择的索引值是特定于实现的，Bluetooth Core Specification指示建议“充分使用信道，以避免冲突”。

Packet Chaining

对于那种应用想发送更多数据(高达1650字节)的应用场景，controller可以将数据分段，并将包含该数据子集的数据包链接在一起。每一个链接的数据包可以在不同的信道上面传输，在这个链条中，将AuxPtr的header字段引用到下一个信道。如图21所示:

图20 使用packet chaining的Extended advertising

Advertising Sets

Legacy advertising并没有对广播有效载荷和参数变化做出正式的规定。Extended advertising包含了对于用于多个、不同广播数据集和的标准机制。

广播集有一个ID用于指示给定的数据包术语哪一个集和，并且每组有自己的广播参数，比如要使用的advertising interval和PDU类型。

调度和传输不同的数据集的任务落在了controller中的Link Layer，而不是由host驱动，主机驱动会大大降低效能。Host仅仅需要初始化地将advertising集和与之相关的参数告知给controller，之后由Link Layer接管。

Periodic Advertising

Extended advertising包含了一个使用确定调度的广播方法，它的细节可能是被scanning设备发现和同步。这叫做Periodic Advertising。将Periodic Advertising定义为一个不同的逻辑传输，并在7.7.3 PADVB - LE Periodic Advertising Broadcast描述。

Extended Advertising and Associated PDU Types

针对使用extended advertising，定义了一些PDU类型。表5列出了这些extended advertising PDUs。

PDU	描述	信道	PHY	发送方
ADV_EXT_IND	Extended advertising	primary	LE 1M, LE Coded	Peripheral
AUX_ADV_IND	Subordinate extended advertising	secondary	LE 1M, LE 2M, LE Coded	Peripheral
AUX_CHAIN_IND	Additional advertising data	secondary	LE 1M, LE 2M, LE Coded	Peripheral
AUX_SYNC_IND	Periodic advertising synchronization	periodic	LE 1M, LE 2M, LE Coded	Peripheral
AUX_SCAN_IND	Auxiliary scan request	secondary	LE 1M, LE 2M, LE Coded	Central
AUX_SCAN_RSP	Auxiliary scan response	secondary	LE 1M, LE 2M, LE Coded	Peripheral
AUX_CONNECT_REQ	Auxiliary connect request	secondary	LE 1M, LE 2M, LE Coded	Central
AUX_CONNECT_RSP	Auxiliary connect response	secondary	LE 1M, LE 2M, LE Coded	Peripheral

表5使用packet chaining的Extended advertising

ADV_EXT_IND、AUX_ADV_IND、AUX_SCAN_RSP、AUX_SYNC_IND、AUX_CHAIN_IND以及AUX_CONNECT_RSP类型PDU的payload都定义成同样的格式，叫做Common Extended Advertising Payload Format。它包含了AuxPtr字段和AdvMode。AdvMode使用两个不同bit来标识广播模式的connectable and scannable特性，而不是使用不同的PDU类型。

Bluetooth Core Specification中的Link Layer规范的第4.4节给出了所有的advertising PDU types的全部细节。

Scheduling

Extended advertising发生在extended advertising事件。extended advertising事件与广播事件同时开始，并且含有携带AuxPtr字段的superior packet，和与其相关subordinate packets。

Comparing Legacy Advertising and Extended Advertising

图6展示了legacy广播和extended广播的比较总结。

	Legacy广播	Extended广播
最大host广播数据大小	31	1650	Extended广播支持分片，能够支持50倍最大主机广播数据大小
每个数据包最大广播数据	31	254	Extended广播PDU使用Common Extended Advertising Payload Format，它支持8倍广播数据字段。
TX信道	37，38，39	0~39	Extended广播使用37个通用功能信道作为次级广播信道。ADV_EXT_IND PDU类型仅仅在初级广播信道(37,38,39)上传输。
PHY支持	LE 1M	LE 1M LE 2M (除ADV_EXT_IND PDU) LE Coded	除了ADV_EXT_IND之外，所有的Extended广播PDU都可以使用三种LE PHY的任意一种传输，ADV_EXT_IND可以在LE 1M或者LECoded PHY上传输。
广播配置	1	16	Extended广播包含了能使广播设备一次支持16中不同的广播配置的广播设定，并且对于每个广播设定，可以根据设定中的时间间隔定义来交叉广播
通信类型	异步	异步同步	Extended广播包含周期性广播，使能发送者和接收者之间的时间同步广播数据通信。

表6 legacy和Extended 广播比较

PADVB - LE Periodic Advertising Broadcast

Basics

如ADVB逻辑传输(参见7.7.2 ADVB - LE Advertising Broadcast)展现的广播那样，在广播包的传输时序里包含了一定程度的随机性。0到10ms之间的随机延迟被故意放到广播事件时序里面，以此帮助避开持续性冲突。当执行legacy广播时，这是广播得以运行的唯一方法。

Periodic广播需要数据包的传输按照确定的时序，并且提供了一种允许另外的设备将它们数据包扫描同步到广播设备的这种时序上。Periodic广播总是non-scannable以及non-connectable的。

Periodic广播有利于observer设备，通过提供一个更加节能的方式执行扫描，并且，在LE Audio broadcast解决方法中是一个关键的组件。

广播发生在固定间隔，这个间隔佳作periodic advertising interval，并且广播的数据载荷是可以改变的。一连串的AUX_SYNC_IND以及相关的AUX_CHAIN_IND PDUs就做成了所谓的periodic advertising train。

在每一个periodic广播事件，单个的AUX_SYN_IND PDU就被发送了，紧接着是0个或者更多的AUX_CHAIN_IND PDUs，取决于host提供的载荷是不是需要分片。

AUX_ADV_IND PDU包括了叫做SyncInfo的字段，它是Common Extended Advertising载荷的一部分，并且，SyncInfo也包含了信道和时序偏移信息。

Channel Use

Periodic广播使用37个次级广播信道。选择信道是在每一个periodic广播事件开始时，使用信道选择算法#2，使用叫做一个event counter字段作为输入，叫做paEventCounter。这个计数器在每一个periodic广播事件增加。任意与AUX_SYNC_IND PDU相关的auxiliary AUX_CHAIN_IND PDUs都有他们选好的信道，使用一个特定于实现的算法选择，并且，信道已在AuxPtr中指定了。参见图22。

Scheduling

Periodic广播讲过决定了对于一个给定广播设定，多久periodic广播可以出现。它以发送AUX_SYNC_IND PDU为开始，并且以一串0个或更多AUX_CHAIN_IND PDUs为继续，如图22所示。

图22 Periodic广播事件

注意，图22已经简化过了，不同的primary广播信道上面潜在地有多个ADV_EXT_IND PDUs，在这里用单个方框表示。

Synchronization Establishment

扫描设备可以通过两种方式与周期性广播序列同步。一种是通过扫描AUX_ADV_IND PDU并且使用其中的SyncInfo字段，以此确定要使用的周期性广播间隔、时序偏移和信道信息，另外一种是通过LE-ACL连接从另外的、已经拥有从AUX_ADV_IND PDU来的信息的设备接收到此类信息。这种方法叫做Periodic Advertising Sync Transfer procedure。

LE BIS and LE CIS - Isochronous Communication

这一节强调isochronous通信的关键部分。更多的信息，推荐

Nick Hunn的Introducing Bluetooth LE Audio这本书。这本书可以在电子论坛免费下载https://www.bluetooth.com/bluetooth-resources/le-audio-

book/。Bluetooth Core Specification包含了全部的细节。

Basics

Isochronous通信提供了一种使用Bluetooth LE，在设备之间传输有时间限定的数据。它提供了一种机制，允许多个sink设备，在不同的时间从相同的source设备接收数据，以此同步它们的数据处理。LE Audio就是使用的isochronous通信。

当使用isochronous通信时，数据有一个时间限定的有效周期，周期的最后叫做失效。没有发送的失效数据会被丢弃。意味着，设备只接收按照规则有效的数据，规则是有关时间和可以接受的latency的，可能是profile规定的。

数据是在isochronous streams中传输，stream属于isochronous groups。

设备等待一个时间周期，允许所有属于同一个组的stream，在处理接收数据之前可以有同时传送相关数据包的机会。比如，可以使用两个streams传送stereo music，一个是左立体声声道，另一个是右立体声声道。两个stream应该是相同的组的成员，以此，同时呈现来自两个stream的数据包，用户可以听到想要的立体声。

两个使用LE Isochronous物理信道的逻辑传输就定义好了。Connected Isochronous Streams(LE CIS，或简称CIS)使用connection-oriented通信，并且支持双向数据传输。Broadcast Isochronous Streams(LE BIS，或简称BIS)使用connectionless广播通信，并且提供无方向数据通信。

Connected Isochronous Streams

CIS Overview

单个CIS stream提供在两个已连接设备之间的点对点isochronous通信，并且传输数据在叫做CIS PDU的链路层PDU之中。如图23描述的全部数据传输架构中的LE-CIS(CIS)逻辑传输。

图23 Bluetooth数据传输架构中的LE-CIS(CIS)

定义了两个逻辑链路，LE-S和LE-F并提供对unframed(LE-S)和framed (LE-F)数据的支持。LE-S和LE-F的使用是Isochronous Adaptation Layer的关注点。

使用LE Isochronous Physical Channel的CIS可能使用任意的Bluetooth LE PHYs。CIS支持双向通信，并且使用应答协议。

CIS stream是组的成员，这种组叫做Connected Isochronous Groups(CIGs)，每个组里面可以包含1个或多个CISes。参见图24.

图24 一个CIG包含两个CISes

Channel Use

Connected Isochronous Streams 使用#2信道选择算法的使用自适应跳频。

Scheduling

CIG和它的成员CIS的时序是由CIG events、CIS events以及subevents体系来控制的。

CIG event标志着跨越整个属于该CIG的CIS的时序的开始，并且它出现在该组的第一个CIS的anchor点。CIG events事件出现在一个特定的间隙，叫做ISO_Interval.参数。

每一个CIS event被分成一个或多个subevents。使用的subevents的个数是在一个叫做NSE的stream参数中。在connected isochronous stream中，subevent之间，Central传送一次，Peripheral响应一次，如图25所示。除了Number of Subevents (NSE)，每个CIS都有一些重要参数，包括Flush Timeout (FT)和Burst Number (BN)。

图25 CIS events和subevents

每个负载(比如，如LC3音频编解码器输出的音频数据块)都给予一个最大的CIS events数目，CIS events用于成功(有应答表示)传输负载，并且他是在FT参数中明确的。可以在每个CIS event的subevents去尝试，如果没有在TF event之内成功，这个数据包就会被冲掉(丢掉)。有时候，同时有多个PDU包含不同的数据(比如，负载)，CIS允许在同一个CIS event中，发送多个不同的PDU。用在每个CIS event中的不同PDU的数量是在Burst Number (BN)明确的。

Processing Synchronization

CIG有一个与时序相关的参数叫做CIG_Sync_Delay。同一个CIG中的CISes每个都有一个时序参数叫做CIS_Sync_Delay，被接收者用作isochronous data处理(典型地，音频呈现)的同步，跨越组内的所有stream。接收者在呈现接收到的数据之前会等待此参数中指示的这段时间。

如图26所描述，每个steam都有一个不同的CIS_Sync_Delay值。CIG中的第一个CIS stream，它被设置成分组级别的参数CIG_Sync_Delay。分组里面的其他streams的每一个CIS_Sync_Delay都会设置成一个减小的值。这意味着，在分组里面，越早接收到的stream在呈现内容之前就会等的越久。更高层规范，比如profile可以规定更进一步的呈现延迟的使用，以此把允许的本地的处理延迟也计算在内。

图26 CIG中CIS数据的同步呈现

这种分层的延迟系统就是每一个sink设备都将同时处理接收到的数据。

CIS Stream Creation

建立connected isochronous stream之前，首先需要建立ACL连接。该连接有两个目的。第一个是用于交换链路层control PDU。其次，它提供了一个时序参考点，一旦建立好了stream，就可以根据该参考点调度CIS。

Central设备总是初始化该过程，以此建立一个CIS。需要通过发送链路层叫做LL_CIS_REQ的控制PDU来实现。一切正常的话，Peripheral用LL_CIS_RSP来响应，当Central发送LL_CIS_IND PDU时，就可以说stream已经建立好了。这个PDU包含了重要的参数，用来确定CIS event的时序和呈现之前用到的delay。特别地，CIS_Offset以us为单位提供了ACL anchor点(连接事件中发送第一个包的时间点)和此stream的第一个CIS event之间的偏移。CIG_Sync_Delay包含了以us为单位的全局CIG同步延迟，CIS_Sync_Delay包含了的被该stream所使用的同步延迟。

在stream建立之后，它是独立地、伴着创建它时用到的ACL连接运行的。如果该ACL断开了，相关的CIS也必须终止。

CIS Encryption

如果两端设备已经配过队了，CIS所使用的link可以是加密的。

Broadcast Isochronous Streams

BIS Overview

BIS stream 提供在一个发送者(source)和许多接收者(sink)之间的broadcast isochronous通信。数据是在链路层的PDU中发送，该PDU叫做BIS Data PDU。控制信息是在BIS Control PDU中发送。

全部数据传输架构中的LE_BIS(BIS)逻辑传输如图27描述。

图27 Bluetooth数据传输架构中的LE_BIS

BIS上广播的数据可以是framed和unframed，相应的逻辑链路类型是LE-S以及LE-F。LEB-C逻辑链路承载控制信息。

BIS stream使用LE Isochronous Physical Channel并且可以使用任意Bluetooth LE PHY。

BIS streams是叫做Broadcast Isochronous Groups (BIG)的成员，每个BIG可以包含一个或多个BIS。参见图28。

图28 BIG包含两个BISes

每个BIG可以最多有31个BIS。Central设备可以创建多个BIG。然而，可用的广播时间和其他的实现细节常常会降低这个值。

BIS只支持单向通信。

与CIS相反，BIS不包括确认协议。这使得BIS传输天生不可靠。然而，为了对抗这种问题，unconditional packet retransmission方法应运而生。因为通信是单向的，BIS不需要为Peripheral response预留slot(如CIS那样)。因此，在给定的广播时间，两倍多的subevent可以用作传输调度，因此对于reliability-enhancing retransmissions有更多的机会。更进一步，因为重传发生在不同的subevent，因此，它们是在不同的信道上传输的。选好的信道必须至少和上一次传输的信道相差6MHz，以此帮助缓和在某些特别的信道上因为干扰而潜在的数据包丢失。

Channel Use

Connected Isochronous Streams 使用#2信道选择算法的使用自适应跳频。

Scheduling

BIG和它的成员BIS的时序是由BIG event、BIS event以及subevent体系控制的。此外，定义了特别的control subevent用于传送有关整个BIG的控制PDU。

BIG event标志着横跨整个属于该BIG的BIS的时序的开始。BIS event以intervals开始，该intervals是一个BIG中叫做BIS_Spacing的参数的倍数，从BIG开始(也被叫做BIG anchor point)。

每一个BIS event被分成一个或更多subevent。subevent的数量是在一个叫做NSE的stream参数中明确的。在subevent期间，广播设备发送单个数据包。通信是单向的，没有必要去接收数据包。subevent被一个叫做Sub_Interval的BIG参数持续时间给分开了。

对于每一个connectionless isochronous groups，BIG中BIS event的时序可以是顺序的也可以是交错的。

BIG event可能包含一个control subevent，总是被安排在BIG的最后一个subevent。

注意，信道在每一个subevent都会改变。

图28展示了一个BIG event、BIS event以及subevent的例子，按照顺序来安排时序。注意，在BIG event#1的最后传送的的BIG control subevent(名为Tc)。

图29 BIG/BIS event时序

Processing Synchronization

BIG中整个broadcast isochronous streams数据的同步处理与connected isochronous communication中使用相似方式。接收者拥有BIG的信息和它所有的参数，并且知道它们选择接收哪些stream。对于所有的stream，BIG的时序参数都是一致的。使用全局的BIG_Sync_Delay和BIS_Spacing参数，接收者能够计算出在处理接收到的数据以使其与其他stream同步之前，要等待多长时间。

BIS Stream Creation

在其他同一个BIG的成员设备接收其他stream的同时，设备要能够接收BIS的广播数据包，并且要呈现或者处理这些数据包的内容，要求是设备必须首先发现BIG和参数，参数用来定义BIG，比如它包含的stream数量、每个stream event和subevent之间的空间以及用来从anchor point计算时序的时序偏移信息。称为BIGInfo的复合字段在ACAD(Additional ControllerAdvertising Data)字段内的AUX_SYNC_IND PDU中广播，并包含所需的数据。

有两种方式可以接收BIGInfo。第一情况，接收者必须使用定义好的过程，直接地同步到periodic广播序列(参见7.7.3.1 Basics)，接收AUX_SYNC_IND PDU，并且从ACAD中提取出BIGInfo。然而，就功耗而言，扫描周期性广播并与之同步可能是一个过多耗费的过程。所以在第二种情况中，一个设备可以代替另一个设备执行发现周期性广播序列并与之同步的行为，典型地，这个设备据有更多的能源。拥有获取到的BIGInfo，然后这个代理扫描设备将此信息通过一个更加高效的ACL 连接传递给想要收到broadcast isochronous stream 的设备。这是通过叫做Periodic Advertising Sync Transfer(PAST)的过程完成的。

BIG Encryption

BIG可以被加密。这不需要设备和广播设备配对才能接收BISes。取而代之，必须分发用于导出密钥的Broadcast Code参数。可能通过带外或者通过随后在更高层的profile中描述的过程来执行。

Retransmissions and Reliability

可以通过在BIS或CIS stream上连续的subevent中重传相同数据包来增强可靠性。在BIS用例中，重传是无条件的，而对于CIS，在Peripheral没有确认传输时才发生重传。

BIS用例中，因为不需要为Peripheral的响应(CIS中就需要)保留时隙，给定的广播时间就有两倍多的subevent可以用于传输，所有对于reliability-enhancing retransmissions，会有更多的机会。

重传，因为它们占用不同的subevent，所有传输在不同的信道上，并且所选信道必须至少离上次传输6MHz以上。这有助于缓和在特别通道上因为干扰而导致的数据包丢失。

LE Audio

LE Isochronous通信主要被设计用于audio 产品和系统。它提供了从一个source发送到多个sink的audio，可以被同时呈现，以便正确同步播放。

The Isochronous Adaptation Layer

Basics

Isochronous Adaptation Layer的主要目的就是设法解决会影响audio设备的connected和broadcast isochronous通信的潜在问题。ISOAL可以在其他使用isochronous通信中找到应用。

Nick Hunn的书Introducing Bluetooth LE Audio，5.2章节就很好地涵盖了此主题，推荐去阅读。

Audio Sampling

数字音频的工作方式是对模拟音频信号进行采样，并在保存或者发送(Bluetooth LE audio应用场景)它之前，对采样的音频使用编解码器进行压缩或者其他处理。在读取或接收数字音频数据时，处理过程是相反的，使用编解码器解码该数据，产生一连串的数字样本，用于(近似地)重现原始的模拟音频。图30展示涉及的步骤，采样、编码以及传输音频信号，以及反向过程，涉及接收编码数据、解码以及最终地呈现出来。

图30 音频处理步骤

音频编解码器的关键目的之一就是减小音频数据的大小，这样它就可以有效地在链路上传输，链路只有有限(宝贵的)带宽。采样涉及以固定的间隔测量和记录信号的幅值。样本按照某种频率进行记录，该频率叫做sample rate。图31中的竖线代表了以曲线表示的连续变化音频信号的样本。一连串的样本创建了原始模拟信号的一种approximate representation。越频繁的采样(更高的采样频率)，approximation越接近于原始信号，重新创建原始音频的反向过程，就会得到越好的结果和感知品质。

另一个采样维度是bit depth。样本信号的幅值需要一个整型的值来表示。一种方法是将可能的振幅范围分成256个离散的振幅带，用一个0~255之间的数字代表每一个振幅。这个方案中，单个样本只需要一个字节(8bit)来记录样本的幅值所在的振幅带，因此，bit depth就是8bit。将振幅的可能范围分成更多的离散带可以为表示样本值提供更细粒度的体系和潜在的更好质量。

图31代表连续模拟信号的离散样本

比如一个24bit depth，允许可能代表的幅值范围用整数表示就是0到16777215。然而，每个样本需要3个字节，以此通过这种增加bit depth的方式采样会产生3倍的数据。

数字采样会产生大量的数据。比如一首3分钟的歌曲，采样率44.1kHz(CD质量)、bit depth为24bit。我们计算一下，会发现用数字形式来近似表达整首歌的原始采样数据将近24Mbyte。我们不需要担心将这些数据存放在一个4TB的硬盘上，但是，当我们的想在任意的有限带宽的链路上传输这些数据时，问题就产生了。这时，编解码器出现了。

Codecs and Frames

像被Bluetooth LE audio使用的LC3编解码器，可以将原始采样数据压缩到原来大小(但请注意，实际结果在很大程度上取决于原始音频内容)的25%以下。

这是一笔可观的节省。

通常，编解码器通过识别和利用在一连串的连续样本中找到的模式工作。举一个非常简单的例子来说明这一原理，如果数据集包含一个具有100个样本的连续序列，每个样本值都是50，则假设bit depth是8bit，编解码器可能使用两个字节[100,50]来表示它，而不是原始序列的100字节，都是相同的50，[50,50,50…..50]。显然，编解码器工作，需要一系列样本进行分析和编码而不是以此处理单个样本(在单个样本中找不到任何模式)。由编解码器一次分析的样本集合叫做frame。frame具有固定的持续时间通常以ms为单位，并且包含由采样率决定的许多样本。比如，如果采样率是44.1KHz，则10ms frame包含了4410个样本。不同的audio产品可能使用不同的frame durations。常用10ms和7.5ms。当一个设备以一个frame duration产生音频(source)，而另一个设备用一个不同的frame duration消费它(sink)，则需要解决一个问题。这时候，ISOAL出现了。

Framed vs Unframed

当设备使用isochronous通信时，发送设备和接收设备所使用的frame duration不需要是相同的。这就会导致两种可能的状况:

第一个设备所使用的frame duration是另外一个所使用的frame duration的精确的倍数。
第一个设备所使用的frame duration不是另外一个所使用的frame duration的精确的倍数。

第一种情况下，较大frame duration和较小frame duration之间的关系很简单，并且两者之间的转换数据是一种简单的操作。在一个或多个链路层PDU payload内的发送数据叫做unframed，并且不包含用来支持两个需求之间的frame duration适配的附加的数据。

第二种情况下，链路层PDUs可以包含较大的payload的部分，和用来表示是否为frame的开始、中间段或者是frame尾部的短header字段。类似这种格式的数据叫做framed。

Connected Isochronous PDU和Broadcast Isochronous PDU(链路层中定义)都包含了一个叫做LLID的字段。LLID表示该链路层的PDU是否包含framed或是unframed数据。ISOAL根据从链路层中收到数据是否为framed，使用不同的处理数据方式。类似地，是否需要framing，影响到了ISOAL处理从上层SDU中收到的数据，并将其传递给链路层，按照link layer ISO PDU来传输。

Fragmentation and Recombination

如果数据是unframed，recombination就会从一个或多个链路层PDU的payload中的一个或多个fragment创建单个service data unit (SDU)。然后ISOAL将这个SDU送到上层。如32所示。

当上层SDU需要被分割成更小的payload用于链路层PDU传输时，并且不需要framing时，此过程就叫做fragmentation。如图33所示。

图32 unframed ISO PDU的Recombination

图33 Fragmentation 创建unframed ISO PDU

Unframed PDU 有一个header用来表示接下里的数据是SDU的起始、前一个SDU的延续，还是SDU的结尾。PDU只包含了unframedSDU的单个fragment。

Segmentation and Reassembly

如果数据是framed，reassembly就会从一个或多个链路层PDU的payload中的一个或多个segments创建单个service data unit (SDU)。然后ISOAL将这个SDU送到上层。如34所示。

图34 framed ISO PDU的Reassembly

当上层SDU需要被分割成更小的payload用于链路层PDU传输时，并且需要framing时，此过程就叫做segmentation。如图35所示。

图35 Segmentation创建framed ISO PDU

framed PDU 中的Segments，有一个header用来表示接下里的数据是SDU的起始、前一个SDU的延续，还是SDU的结尾以及timing offset 信息。PDU可能包含了framedSDU的多个fragment。

The Host Controller Interface

Basics

Host Controller Interface(HCI)定义了host可以用来发送命令给controller，controller可以与host通信的标准接口。此规范分为几个部分，第一部分仅仅在功能方面定义了接口，不考虑具体的实现机制，另外的部分定义了使用4个可能的物理传输怎样实现HCI。

HCI在Bluetooth LE和Bluetooth BR/EDR上都在使用。

The HCI Functional Specification

功能接口是依据commands和命令来定义的。它们本质上是可以在host和controller之间交换的信息。命令是从主机发到控制器，事件是从控制器发到主机。事件可能是对命令的响应，或者是自发的消息。参见图36。

图36 HCI命令和事件

HCI Transports

四个HCI传输类型:

UART
USB
Secuire Digital (SD)
Three-wire UART

UART Transport

HCI UART传输可以用于实现主机和控制器在同一块印制电路板上使用UART连接的HCI通信。定义了基于5个数据包类型的协议。它们是HCI command数据包、HCI ACL Data数据包、HCI Synchronous数据包，HCI Event数据包，以及HCI ISO Data数据包。

明确了RS232配置需求。总之，UART传输使用8个数据bit，无parity，1个停止位和RTS/CTS flow control位。

USB Transport

USB传输以两种方式使用USB。Bluetooth控制器可以在USB dongle中实现。或者，USB可以在产品内部用于连接主机和控制器实现。

USB标准定义了数据可以从中发送和接收的buffer叫做endpoints。HCI USB传输规范指明了需要存在的endpoint和它们要求和建议的特性。

Secure Digital

定义了和HCI SD传输一起使用的规范，并且属于Secure Digital Association (SDA)。Bluetooth core specification关于HCI SD传输的部分主要包括对SDA拥有的外部规范的参考以及通信架构的概述。

Three-wire UART

Three-wireUART HCI传输规范描述了用于在两个three-wire-connected的UART之间传输HCI命令和事件的架构和协议。它涉及可靠性、数据完整性、链路建立、电源管理和硬件配置。

HCI Examples

下面是一些展示HCI功能接口的示例。

Connectionless AoA/AoD

图37展示了host准备发送使用angle of arrival (AoA)或angle of departure (AoD)技术、支持测向的数据包，配置controller过程的HCI命令和事件的交换。

图示, 表格

描述已自动生成

图37 HCI 无连接AoA/AoD控制器配置

LE Path Loss Monitoring

LE path loss monitoring是LE power control特性的一部分。希望管理对端连接设备的传输功率，以将其保持在接收器的最佳功率范围内的设备可以使用该特性。

图38展示了host发送必须的HCI命令去配置并使能LE path loss monitoring。在monitoring被使能之后，controller发送含有pass loss数据的LE Path Loss Threshold事件到host。

表格

描述已自动生成

图38 LE Path Loss Monitoring

Active Scanning

由Peripheral支持的Active scanning使用legacy advertising，且需要比单个广播数据包传递更多的数据。详情参见13.3节Discovery。

图39 Active Scanning

The Logical Link Control and Adaptation Protocol

Basics

Logical Link Control and Adaptation Protocol (L2CAP)负责协议复用、流量控制已经分片和重组service data units (SDUs)。

L2CAP使用channel的概念区分在协议栈层之间传递的数据包序列。与特定的更高层协议相关的固定的channel不需要建立，可以立即使用。通过与协议相关的Protocol Service Multiplexer (PSM)值，通道也可能动态地创建。

图40展示了L2CAP的主要功能。

图40 L2CAP主要功能

L2CAP and Protocol Multiplexing

协议栈内，在L2CAP之上就是一些使用不同协议的层，比如attribute协议(ATT)和security manager协议(SMP)。L2CAP复用可以确保SDU可以向上传递到合适的层去做处理。

当L2CAP通道在处理ATT协议时，它可以使用预留个ATT的固定的通道，这种情况下，它就可以叫做unenhanced ATT bearer，又或者它可以使用一个或多个动态通道，每个就充当enhanced ATT bearer。unenhanced ATT bearer支持ATT传输，依次执行，一次一个。enhanced ATT bearer 支持并行ATT传输，在并行L2CAP通道内，顺序执行。详见第11章，Attribute Protocol。

L2CAP and Flow Control

流量控制时为了确保由协议栈的一层产生的数据包速率，不要超过同一个协议栈的一层或者远端设备处理这些数据包的速率。如果没有流量控制，就会有buffer溢出问题的风险。

Credit based流量控制是许多可能的流量控制方法之一。总而言之，它按照下面的方法运行:

发送设备知道接收设备在不丢失数据(例如，通过缓冲溢出)的情况下，可以处理的按PDU数量来算的容量。它通过在数据传输之前，配置或者两个设备之间进行交换获取到容量信息。
发送设备以接收者容量限度设置一个计数器。发送者每发送一个PDU，计数器就减小。当计数器减到0时，发送者知道接收者容量已经满了，以此，当接收者处理数据积压时，临时停止继续发送PDU。
当接收者从缓冲中读取并处理一个或多个PDU，它就给发送者发送相应的信用值，发送者用这个信用值增加它的计数器。计数器不为0时，发送者就可以继续发送更多的PDU了。

L2CAP定义了几种操作模式，主要涉及流量控制。

比如，在L2CAP unenhanced ATT bearer之上的ATT使用Basic L2CAP Mode，它不提供流量控制。这使得ATT不可靠，应用程序必须考虑发送的ATT PDU可能被接收设备丢失的情况。对于unacknowledged PDU，比如notifications，发送设备会知道它是否被远端设备接收到，幸亏有链路层acknowledgement，但是没有办法知道PDU是否被成功送到协议栈顶端的接收应用程序。

L2CAP enhanced ATT bearer之上的ATT使用Enhanced Credit Based Flow Control Mode，它提供流量控制。因此，EATT可以被认为是可靠的。

L2CAP Segmentation and Reassembly

L2CAP之上和之下的层都受到最大传输单元（MTU）大小的约束，该最大传输单元大小指定了由该层创建的类型的PDU允许的最大大小。比如，ATT_MTU参数定义了ATT PDU可能的最大值。

L2CAP本身以及协议栈中其上或下的层可能具有不同的MTU大小，因此，可能需要将一些PDU/SDU分割成更小的部分，相邻的层才可以处理，反过来，将一连串相关的、更小的部分重新组合成整个PDU/SDU。L2CAP针对上层应用做的这些过程成为segmentation和reassembly，而L2CAP及其下层相关的等效过程被称为fragmentation 和recombination。

The Attribute Protocol

Basics

两个设备使用attribute protocol (ATT)，一个作为client角色，另一个作为server角色。server暴露了一系列组合数据项，被称作attributes。Attributes由server按照索引列表组织起来，叫做attribute table。

每个attribute包含handle、Universally Unique Identifier (UUID)、value以及一系列权限。

Handle是唯一的索引值，ATT client可以使用该索引值引用attributetable中的特定条目。
UUID标识属性的类型。
Permissions字段是一套标志集合，用于表示刻度、可写或者两者都可，以及在满足的情况下才可以访问的另外安全条件。
Bluetooth SIG学习指导Understanding Security in Bluetooth LE有更多关于attribute 权限的信息。
Attribute value字段是一个包含attribute’s value的数组。从数据类型和语义两方面解释字节数组是协议栈更高层关注的问题。

Generic Attribute Profile (GATT)定义了attributes怎样代表了更高层被称为service、characteristic以及descriptors的结构。一般地，需要连续handle value范围内的一组attributes来表示更加复杂的类型，例如，由于这个原因，attributes协议支持使用由handle value范围标识的属性组。更多这方面的信息，参见12节。

ATT client使用ATT来发现ATT server中的attribute table的细节，包括了attributes的handle values或者感兴趣的attributes类型。当handle values已知，它们可以与某些 PDU 类型一起使用，以标识表中的特定属性，然后对其执行操作。比如，ATT_READ_BY_GROUP_TYPE_REQ PDU可以用于查找作为primary service的一部分的所有attribute的handle和UUID。较短的表述方式是，例如，ATT_READ_BY_GROUP_TYPE_REQ PDU可用于查找由attribute table定义的所有GATT primary services。

当使用发现操作的PDU(如ATT_READ_BY_GROUP_TYPE_REQ)时，会指定handle range，并指示要搜索的属性表中条目的子集(可能是整个表)，以及要查找的attribute的类型。图41展示了此过程，搜索了所有的primary service，响应显示了与发现的primary service 相关attribute的handle value范围。

图41 Group Type Request读取和Response

ATT 是连接Bluetooth LE 设备中的应用程序相互交互的主要机制之一，使用协议定义的 PDU 和更高级别规范(如Generic Attribute Profile (GATT))中定义的过程。

定义了两个ATT变体，basic ATT和新的Enhanced Attribute Protocol (EATT)。Bluetooth LE 或 Bluetooth BR/EDR都可使用ATT。本文中，仅仅考虑与Bluetooth LE一起使用的ATT。

ATT PDUs

Attribute协议定义了31种不同的PDU，每个都基于6个广泛方法之一。

Commands

ATT 命令PDU由client发给server，而没有来自server的响应。一个命令的例子，ATT_WRITE_CMD，如图42所示。

图42 ATT_WRITE_CMD

Requests and Responses

ATT request PDU由client发给server。期望在30s之内，server以相应类型的响应PDU来回答，或者使用错误的响应PDU(ATT_ERROR_RSP)来回答。超过30s就成了超时。

request/response PDU成对的例子就是ATT_WRITE_REQ和ATT_WRITE_RSP PDU，如图43所示。

图43 ATT_WRITE_ REQ

Notifications

Notifications是由server自发给client的PDU，类型为ATT_HANDLE_VALUE_NTF。没有响应PDU，参见图44。

图44 ATT_HANDLE_VALUE_NTF

Indications and Confirmations

ATT indication PDU由server发给client。期望在30s之内，server以相应类型的响应PDU来回答，或者使用错误的响应PDU(ATT_ERROR_RSP)来回答。超过30s就成了超时。

indication/confirmation PDU成对的例子就是ATT_HANDLE_VALUE_IND和ATT_HANDLE_VALUE_CFM PDU，如图45所示—Indications和Confirmations。

图45 Indications和Confirmations

PDU Format

所有的ATT PDU都有相同的结构，由一个表示PDU类型的opcode、一组参数以及可选的authentication signature。请注意，signature字段很少使用，当attribute协议在加密链路上运行时，signature字段是多余的，因为链路层的所有加密数据包都包含authentication数据。

Maximum Transmission Unit

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

Transactions

ATT定义了transaction的概念。来自client的Request PDU期望30s之内从server返回response PDU。来自server的Indications期望30s之内client使用confirmation来回答。每个request/response成对或者indication/ confirmation成对组成了transaction。如果一个transaction超时了，就会被认为已失败，并且没有更多类型的PDU会使用当前bearer来发送了。

TT使用顺序transaction模型。这意味着，如果已启动ATT transaction，则在当前transaction完成之前，同一bearer实例不会处理更多的ATT PDU。当从远程设备接收到预期的响应或confirmation PDU时，或者当transaction在等待30秒后超时，transaction被视为已完成。

Bearers

ATT由下面的L2CAP层以两种方式之一处理，每种方式都称为bearer。两个ATTbearer是Unenhanced ATT bearer和Enhanced ATD bearer。使用哪个bearer对ATT的使用方式以及在某些情况下协议的可靠性具有影响。Generic Attribute Profile如何使用ATT，并声明，例如:

Unenhanced ATT bearer

使用固定的L2CAP通道，因此，该bearer可能只有一个实例。
无论应用层有多少client正在使用ATT，transaction都是严格顺序的。这可能意味着由一个应用程序启动的transaction可能会延迟另一应用程序希望启动的transaction。
ATT_EXCHANGE_MTU_REQ和ATT_EXCHANGE_MTU_RSP PDU可以交换，以此影响在Unenhanced ATT bearer上使用的ATT MTU的选择。
任何client接收到的、因为诸如buffer溢出原因问题导致不能被处理的notification都要被丢弃。当在Unenhanced ATT bearer上使用的ATT_HANDLE_VALUE_NTF PDU都会被认为是不可靠的。
当使用Unenhanced ATT bearer时，对一些PDU类型的支持，如ATT_MULTIPLE_HANDLE_VALUE_NTF，ATT_READ_MULTIPLE_VARIABLE_REQ以及ATT_READ_MULTIPLE_VARIABLE_RSP是可选的。
L2CAP通道支持unencrypted 或encrypted的Unenhanced ATT bearer。

Enhanced ATT bearer

使用动态L2CAP通道，多通道，因此，允许有多个bearer实例。
因此，在协议栈中，并行transaction，每个transaction都由单独的Enhanced ATT bearer实例处理是可能的。这具有明显的好处，避免了一个应用程序的ATT使用被另一个应用程序阻止的可能性。
ATT MTU 设置为在 L2CAP 层自动使用的 MTU 值，并且Enhanced ATT bearer上的ATT_EXCHANGE_MTU_REQ以及ATT_EXCHANGE_MTU_RSP PDU是不被允许的
使用了叫做Enhanced Credit Based Flow Control Mode的L2CAP流量控制方法。这样的效果是，在Unenhanced ATT bearer上使用不可靠的 PDU 在使用Enhanced ATT bearer时可以被视为可靠。
在使用Enhanced ATT bearer时，对一些PDU，如ATT_MULTIPLE_HANDLE_VALUE_NTF、ATT_READ_MULTIPLE_VARIABLE_REQ以及ATT_READ_MULTIPLE_VARIABLE_RSP的支持时强制性的。
支持Enhanced ATT bearer的L2CAP通道必须是加密通道。

Discovering Support for EATT

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

如果server支持EATT，叫做Server Supported Features的特质必须包含在Generic Attribute Profile服务中。该特征值的第一字节的第一个bit设置成1意味着是支持EATT的。GATT/ATT client通过读取该特征，可以确定server是否支持EATT。

Client Supported Feature特征值由指示对某些功能的支持或不支持的位组成。bit 1表示client是否支持Enhanced ATT Bearer。bit 2表示是否支持ATT_MULTIPLE_HANDLE_VALUE_NTF PDU。客户端必须向此特征写入适当的值，以通知服务器它支持的功能。

图46 EATT feature support discovery

The Generic Attribute Profile

Basics

Generic Attribute Profile (GATT)定义了基于保存在attribute table(参见11章，Attribute Protocol)中的attributes的更高层数据类型。这些数据类型就叫做services、characteristics以及descriptors。也定义了通过Attribute Protocol (ATT)使用这些数据类型所涉及的一系列过程。应用程序通常使用映射到这些过程的平台API。

service是分组机制，提供了一个上下文，在该上下文中可以使用他们所包含并具有已定义类型的特征。通常，service对应于设备的主要特性和功能。

characteristic是独立声明数据项目，并且有数据类型，相关联的值以及一组属性，这些属性用于指示怎样根据一系列与相关的GATT 过程来使用这些数据。比如，可能定义了已连接的对端设备可以读取特定的characteristic的值，但是不可以去写。

characteristics属于service。同样的characteristic类型可以是不止一个service的成员，不同的上下文，这些service提供的使用该characteristic的规则可能不同。service规范会提供细节。

descriptors属于一些characteristics，并且可能包含metadata，比如对于该characteristic的文字描述或者提供某些控制该characteristic行为的方法。characteristics拥有属于它们的0个或多个descriptors。比如，GATT定义了一个叫做characteristic value notification的操作，此操作需要设备向已连接的设备，异步地，发送一个包含characteristic value的ATT PDU，并且不需要收到来自它的response。如果characteristic支持notifications，一般地，notifications会仅仅在characteristic value变化时被发送，或者有定时器控制，周期地被发送。但是，如果设置了descriptor中一个叫做Client Characteristic Configuration descriptor特别的flag之后，notifications只会在对端设备请求它们时，才会被发出，如果设备支持notifications，必定会有这个Client Characteristic Configuration descriptor。

图47展示了service、characteristics以及descriptors的架构。

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

GATT server中必须支持两个特殊的service。generic access service和generic attribute service。

图46 service、characteristics以及descriptors

Bluetooth SIG vs Custom

一些services、characteristics以及descriptors由Bluetooth SIG定义，并且有一个16bit的UUID值来表示它们的类型。每个定义类型的Bluetooth SIG可以在https://www.bluetooth.com/specifications/assigned-numbers中找到。实施者可以购买16bit位的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。除了从Bluetooth SIG购买UUID外，实施者不得使用此范围内的UUID。

GATT server可能只包含了Bluetooth SIG定义的services、characteristics以及descriptors (attributes)，或者包含了Bluetooth SIG
定义的以及客户定制的attributes。

Procedures

GATT的过程包括了service 发现、characteristic 发现、descriptor发现、reading和writing characteristic value、notifying 和 indicating characteristic value等等。GATT规范提供了它的过程和必须使用这些过程的下层ATT协议之间的清晰映射。

Examples

Bluetooth SIG defined attributes only

图48展示了一系列service和它们的characteristics的例子。每个characteristic都有一个相关的descriptor。每个attribute 都是定义在Bluetooth SIG中的。

图48 一系列service、characteristics以及descriptors的例子

展示的是实现标准proximity profile的设备应该可能拥有(immediate alert和TX power服务不是强制的)的service。请注意alert level characteristic怎样出现两次，一次在link loss server中，一次在immediate alert server中。每个的UUID都是相同的。这就是将该characteristic识别为alert level characteristic的原因。但这些characteristic分组所在的service提供了不同的上下文和规则，与alert level characteristic相关的behaviour在两个server之间是不同的。

改变了characteristic的service有一个与之关联的client characteristic configuration descriptor，因为该characteristic 支持notifications。任意支持notifications或者indications的characteristic必须要有一个client characteristic configuration descriptor，因为它的值(client可以写入)控制了在当前，notifications或者indications是否是使能的。

Mixture of Bluetooth SIG and Custom Attributes

图49展示了具有Bluetooth SIG定义的GATT attributes和包含一个custom characteristic客制化的service。客制化的service叫做proximity monitoring service，有一个值为0x3E099910-293F-11E4-93BD-AFD0FE6D1DFD的UUID。Characteristic叫做Client Proximity characteristic，它的UUID值是0x3E099911-293F-11E4-93BD-AFD0FE6D1DFD。注意，该服务和特征用在了教育开发者的资源项目中An Introduction to Bluetooth Low Energy Development。更多细节，参见16章。

图49 Bluetooth SIG与客制化attributes的混合

The Generic Access Profile

Basics

Bluetooth Core Specification的Generic Access Profile (GAP)章节定义了device discovery以及在两个设备之间建立连接的过程。通常，怎样进行数据的无线通信，怎样使用periodic advertising (参见7.7.3 PADVB- LE Periodic Advertising Broadcast)以及怎样建立isochronous通信(参见7.7.4 LE BIS and LE CIS - Isochronous Communication)也是GAP的主题。

除此之外，某些关键的用户接口标准以及某些Bluetooth LE安全方面也是core specification的此章节所涉及到的。

广播数据包的传输(advertising)和通过扫描接收，是GAP怎样工作的核心。有一些不同的广播和扫描数据包类型，由link layer定义的。需要注意的是，叫做AdvData的payload字段不一定在所有的PDU类型中都有。当它存在时，它包含的数据被编码为一系列一个或多个length/tag/value结构，叫做AD Types。AD Types在Core Specification Supplement (CSS)中定义，可以在bluetooth.com的specifications page 找到。

GAP与Bluetooth LE和Bluetooth BR/EDR都有关联。在本节的其他部分，仅涵盖适用于Bluetooth LE的GAP。此外，应该注意的是，虽然advertising和scanning等活动是GAP的核心关注点，但这些过程是由link layer执行的，所涉及的PDU类型也是如此。

Roles

GAP定义了四种设备角色。列在表7中，并做出了解释。

Role	描述
Broadcaster	以无连接的方式，发送一些格式的广播数据的设备。包括了legacy广播、extended广播以及periodic广播。Broadcaster也可以发送广播isochronous stream。Broadcaster有一个发送器，但是拥有接收器是可选的。Broadcaster不接受来自Central设备的连接(除非它扮演Peripheral角色)。
Observer	Observer接收广播数据包或者广播isochronous stream数据包。它没有与另外的设备相连，包含发送器并且可能包含接收器？。Observer可以以无连接的方式，接收广播数据。
Peripheral	Peripheral可以被Central设备连接。它包含发送器和接收器。
Central	Central设备能够初始化与Peripheral设备建立连接。它包含发送器和接收器。

表7 GAP角色

Central和Peripheral角色名字也用在链路层。这两个不同上下文中的术语并不表示相同的事物。

Discovery

Broadcaster或者Peripheral设备要么处于non-discoverable模式，要么处于GAP定义的两个discoverable模式之一。当以non-discoverable模式广播时，传输数据在空中是可见的(不是安全功能)，但是扫描设备执行General Discoverable程序或者Limited Discoverable程序会忽略掉这些数据包。

discoverable设备可能处于general discoverable模式或者处于limited discoverable模式。当处于general discoverable模式时，设备可以被无限期发现，而在limited discoverable模式时，设备最多可在三分钟内被发现。

Discovering设备可以通过检查AdvData字段中的叫做Flag的AD Type来识别advertising设备处于哪一种发现模式。Limited discoverable模式通常用于优先考虑用户最近与之交互的设备，比如按下按钮或者简单地拿起并移动设备。

当Central或Observer设备尝试去发现另外的设备时，它可能使用passive scanning或者active scanning。允许两者中的哪一个取决于尝试去发现的设备是在general discoverable模式还是在limited discoverable模式。

passive扫描涉及接收广播PDU，而不去发送任何scanning PDU。Active扫描涉及接收广播PDU，并且通过发送scanning PDU的，请求更多信息。link layer定义的各式各样的PDU类型总结在7.7.2 ADVB—LE Advertising Broadcast中。

Bluetooth Core Specification指出，一些设备仅仅使用legacy advertising，而另外的可能使用extended advertising，或者两者交替advertising。建议执行发现过程之一的设备交替扫描两种广播类型。还建议设备扫描所有的它支持的PHY。

图50 展示了GAP发现模式与其他相关变量的结合。

图50 GAP discovery和connection modes

Connection Modes

广播设备可以通过使用的PDU (legacy advertising)，或者AdvMode (extended advertising)字段的值来表示它是否可以被连接。

设备通过GAP定义的与连接相关的过程之一来请求与另一个设备连接。通常，需要发送CONNECT_IND PDU (legacy advertising)或者AUX_CONNEXT_REQ PDU (extended advertising)作为允许此操作的几种类型之一的、已收到的PDU的响应。链路层定义了广播和连接请求PDU，以及有关连接请求可能作为响应而发送的PDU类型的规则。

Directed vs Undirected

GAP使用的广播可以是undirected的，意味着PDU可以被任意接收到它们的Observer或Central设备所使用，directed的，意味着只有特定的设备可以处理此类PDU。Directed广播使用的PDU包含了具有预期接收设备的Bluetooth 地址的TargetA字段。Undirected广播中，TargetA字段是空的。

图50 展示了GAP discovery and connection模式的语境中的directed及undirected广播

注意，AD Type Flags出现在primary广播信道接收的legacy广播数据包。然而，当extended广播使用时，AdvData字段不出现在primary信道接收到的ADV_EXT_IND PDU中。当Flags与extended广播使用时，它出现在secondary信道上的auxiliary AUX_EXT_IND？ PDU。

Scannable vs Non-scannable

有些广播类型被称作scannable。收到此类PDU的设备，允许以适当类型的scan请求PDU来响应，一次请求更多广播数据。Advertising PDU在链路层中定义。参见7.7.2.2.3 Legacy Advertising and Associated PDU Types，以及7.7.2.3.5 Extended Advertising and Associated PDU Types，获取更多细节。

GAP and LE Security

GAP规范定义了许多安全术语、模式以及过程。一般而言，GAP安全过程使用协议栈另外的层级，如Security Manager Protocol (SMP)以及链路层，但是，使用这些层以实现某些结果的高级过程定义在Bluetooth Core Specification的第3卷C部分，详情请查阅。

Periodic Advertising

Periodic广播是在链路层中执行(参见7.7.3 PADVB-LE Periodic Advertising Broadcast)，但是GAP明确了Broadcaster进入periodic广播模式以及Observer与periodic广播序列同步的过程。除此之外，允许Observer从Broadcaster获取periodic广播同步参数并将其通过ACL连接发送给另外一个设备的Periodic AdvertisingS ynchronization Transfer (PAST) 过程也定义在了GAP。

Isochronous Broadcast

Isochronous通信使用广播isochronous streams和连接isochronous streams，由链路层执行(参见7.7.4 LE BIS and LE CIS-Isochronous Communication)，但是，GAP明确了Broadcaster和Observers必须遵循以参与这种通信形式的过程。

The Security Manager Protocol

Basics

security manager协议(SMP)，是协议栈security manager component的一部分。它支持与安全相关的一些过程，如pairing、bonding以及key distribution。

security manager component为安全功能提供了加密工具，其它层级可以使用安全功能，并且可以定义pairing算法。

第15章Security in Bluetooth LE 会有更多一般安全方面的信息。

Example

图51展示了两个设备配对过程使用到了SMP。要注意SMP Pairing Feature Exchange过程中的input/output capabilities和另外的flag的交换。这是重要的一个步骤，它决定了选择哪种配对算法，以及如何将认证等步骤合并到过程中。

图51 配对过程中使用SMP

Security in Bluetooth LE

安全是一个关键的话题，需要仔细考虑和理解。

Bluetooth LE提供了一系列安全的功能和特性，其中，大多数是可选的。你可以将它认为是一个toolbox，包含了用来解决特定的安全问题满足特定安全需求的工具。产品团队有责任在确定产品安全要求后，满足这些要求。适当的情况下，应通过使用选定的Bluetooth LE安全功能来实现这一点。鉴于此主题的重要性，Bluetooth SIG已创建了专业与此主题的教育资源，其内容将不在此重复。更多信息，参见第16节，Additional Resources。

Additional Resources

资源	描述	位置
Bluetooth Core规范	关键技术规范。定义了Bluetooth协议栈的所有层级、相关的协议以及过程。涵盖Bluetooth LE和 BR/EDR	https://www.bluetooth.com/ specifications/specs/
Profile and service 规范	服务规范定义了单个GATT服务，与它包含的characteristics和descriptors一起。服务规范中定义了托管服务的GATT服务器设备响应各种条件和声明数据值。 Profile规范定义了相关设备承担的角色，特别是定义了client设备的行为和已连接的server上的数据。	https://www.bluetooth.com/ specifications/specs/
LC3	定义了LE Audio使用的Low Complexity Communication Codec	https://www.bluetooth.com/ specifications/specs/
Study Guide—An Introduction to Bluetooth Low Energy Development	面向希望了解涉及智能手机和外围设备的面向连接的方案的软件开发的开发人员的教育资源。包括一系列带有解决方案的实践项目。	https://www.bluetooth. com/bluetooth-resources/ bluetooth-le-developer-starter-kit/
Study Guide – An Introduction to Bluetooth Mesh Software Development	面向希望了解Bluetooth网状网络以及微控制器中网状网络模型实现的开发人员的教育资源。包括一系列带有解决方案的实践项目。	https://www.bluetooth.com/ Bluetooth resources/bluetooth- mesh-developer-study-guide/
Study Guide - An Introduction to Bluetooth Mesh Proxy Function	面向希望了解如何为智能手机等设备创建 GUI 应用程序的开发人员的教育资源，这些应用程序允许与Bluetooth网状网络中的节点进行交互。包括一系列带有解决方案的实践项目。	https://www.bluetooth. com/bluetooth-resources/ bluetooth-mesh-proxy-kit/
Paper - Bluetooth Mesh Networking – An Introduction for Developers	面向任何有兴趣了解Bluetooth网状网络关键概念和功能的人的教育资源。	https://www.bluetooth.com/ bluetooth-resources/bluetooth- mesh-networking-an introduction-for-developers/
Paper - Bluetooth Mesh Models - A Technical Overview	一个教育资源，适用于任何有兴趣更好地了解Bluetooth网状网络产品中使用的标准型号的人。	https://www.bluetooth. com/bluetooth-resources/ bluetooth-mesh-models/
Study Guide-Understanding Bluetooth LE Security	一个教育资源，解释和说明Bluetooth LE(不包括Bluetooth网状网络)安全的各个方面。适合安全主题的初学者和具有先前经验的人。包括一系列带有解决方案的实践项目。	https://www.bluetooth. com/bluetooth-resources/ le-security-study-guide/
Paper - Bluetooth Security and Privacy Best Practices Guide	本指南旨在帮助实施者更好地理解为什么特定应用程序的某些可用安全和隐私选择比其他选择更好或更差，以及规范中存在哪些风险和陷阱。	https://www.bluetooth.com/ bluetooth-resources/bluetooth- security-and-privacy-best-practices-guide/
Study Guide - Bluetooth Technology for Linux Developers	面向希望了解如何开发使用 Linux Bluetooth协议栈(BlueZ) 的软件的 Linux 开发人员的教育资源。包括一系列带有解决方案的实践项目。	https://www.bluetooth. com/bluetooth-resources/ bluetooth-for-linux/
Study Guide - Designing and Developing Bluetooth Internet Gateways	一个教育资源，解释Bluetooth互联网网关，用于从互联网提供对Bluetooth LE和Bluetooth网状设备的访问。阐释可能的体系结构和实现方法。包括一系列带有解决方案的实践项目。	https://www.bluetooth. com/bluetooth-resources/ bluetooth-internet-gateways/
Study Guide – An Introduction to Web Bluetooth	为希望了解如何开发使用 JavaScript 网络Bluetooth API 的 Web 应用程序的开发人员提供的教育资源。包括一系列带有解决方案的实践项目。	https://www.bluetooth. com/bluetooth-resources/ web-bluetooth-tutorial/
Study Guide - An Introduction to Bluetooth Beacons	面向希望了解Bluetooth信标的开发人员的教育资源。包括一系列带有解决方案的实践项目。	https://www.bluetooth. com/bluetooth-resources/ beacon-smart-starter-kit/
Paper - Bluetooth Core Specification Version 5.0 Feature Enhancements	介绍Bluetooth核心规范 5.0 版中发布的新功能和其他更改。包括 LE 2M 物理层、LE 编码物理层和扩展广告。	https://www.bluetooth. com/bluetooth-resources/ bluetooth-5-go-faster-go-further/
Paper - Bluetooth Core Specification Version 5.1 Feature Overview	介绍Bluetooth核心规范 5.1 版中发布的新功能和其他更改。包括“AoA”和“AoD”定向。	https://www.bluetooth.com/ bluetooth-resources/bluetooth- core-specification-v5-1-feature-overview/
Paper - Bluetooth Core Specification Version 5.2 Feature Overview	介绍Bluetooth核心规范 5.2 版中发布的新功能和其他更改。包括Enhanced Attribute Protocol、LE Power Control和 LE Isochronous Channels。	https://www.bluetooth.com/ bluetooth-resources/bluetooth- core-specification-version-5-2-feature-overview/
Paper - Bluetooth Core Specification Version 5.3 Feature Overview	介绍Bluetooth核心规范 5.3 版中发布的新功能和其他更改。包括使用subrating和 LE Channel Classification.的LE Enhanced Connection Update。	https://www.bluetooth.com/ bluetooth-resources/bluetooth- core-specification-version-5-3-feature-enhancements/
Paper - Bluetooth mesh Models - A Technical Overview	提供了解标准Bluetooth网状网络模型集的指南。	https://www.bluetooth. com/bluetooth-resources/ bluetooth-mesh-models/
eBook - Introducing Bluetooth LE Audio	由尼克·休恩（Nick Hunn）撰写的一本书，清晰地介绍了Bluetooth LE音频的功能和技术细节。	https://www.bluetooth.com/ bluetooth-resources/le-audio-book/