Bluetooth 蓝牙介绍(六)：低功耗蓝牙信息交互_【bluetooth蓝牙开发】六、ble协议之传输层

前言

蓝牙协议栈跟蓝牙芯片都是使用统一的数据来交互的，由SIG规定（备注：部分芯片有HCI vendor命令），一般交互的有以下几种类型（注意：如果没有特别声明，所有的数据）

• Command：host to controller 下发命令
• Event：controller to host 上报事件
• ACL：基于L2CAP连接的交互数据。无连接的异步连接 （主要用于分组数据传输）
• SCO： 面向连接的同步连接 （主要用于话音传输）
• ISO：BLE Audio数据（Core 5.2 Vol 4 Part E, Section 5.4），等时广播 / 等时连接，可用于一对多 / 多对多低延时通讯。
  
  

THREE-WIRE UART TRANSPORT LAYER

本部分描述了三路 UART 传输层（主机和控制器之间）。 HCI command、event和data packet流经该层，但该层不对它们进行解码。有关UART的知识参考 BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4 Part A, UART Transport Layer。

数据包构建分两步完成。首先，它在每个 HCI 数据包的前面添加一个数据包标头，它描述了有效负载。其次，它使用 SLIP 协议对数据包进行帧处理。最后，它通过 UART 接口发送这个数据包。

SLIP 层将不可靠的八位字节流转换为不可靠的数据包流。SLIP 层在数据包周围放置开始和结束八位字节。然后它将数据包中所有出现的帧开始或结束八位字节更改为转义版本。

数据包头描述了数据包的内容，如果需要可靠地传输该数据包，则是一种唯一标识数据包的方式，允许错误数据包的重传。

通过三路 UART 传输层（Three-wire UART (H5) protocol support）发送的每个数据包都有一个数据包标头。它还在有效负载的末尾有一个可选的数据完整性检查。

传输层不支持数据包分段和重组。每个传输包最多包含一个更高层的包。

一个数据包由一个 4 个八位字节的数据包头、一个 0 到 4095 个八位字节的有效载荷和一个可选的 2 个八位字节的数据完整性检查组成，参见图 4.1。

包头由 3 位序列号、3 位确认号、数据完整性校验存在位、可靠包位、4 位包类型、12 位有效载荷长度和 8 位包头校验和组成 。

• SEQUENCE NUMBER：对于不可靠的数据包，此字段在发送时将设置为 0，在接收时将被忽略。
  
  每个新的可靠数据包将被分配一个序列号，该序列号等于前一个可靠数据包的序列号加上一个对八去模的数。数据包每次重传时都将使用相同的序列号。
• ACKNOWLEDGE NUMBER：确认号必须设置为该设备期望接收的下一个可靠数据包的序列号。见 <BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4, Part D> 第6.4 节。
• DATA INTEGRITY CHECK PRESENT：如果 16 位 CCITT-CRC 数据完整性校验附加到有效载荷的末尾，则该位应设置为 1。
• RELIABLE PACKET：如果该位设置为 1，则该数据包是可靠的。这意味着序列号字段是有效的，接收端必须确认其收到。如果此位设置为 0，则此数据包不可靠。
• PACKET TYPE：有五种 HCI 数据包可以通过三线 UART 传输层发送； HCI 数据包编码不提供区分四种 HCI 数据包类型的能力，因此，Packet Type 字段用于区分不同的数据包。
  

HCI Command packets, HCI ACL Data packets, HCI Event packets, 和 HCI
ISO Data packets 始终作为可靠包发送。除非启用 HCI 同步流控制（HCI Synchronous Flow Control），否则 HCI 同步数据包将作为不可靠数据包发送，在这种情况下，它们将作为可靠数据包发送。

除了四种 HCI 数据包类型之外，还定义了其他数据包类型。一种包类型是为纯确认（Acknowledgment）包定义的，另一种包类型是支持链路控制（link control）。

供应商可以使用一种数据包类型供他们自己使用。所有其他三线 UART 数据包类型保留供将来使用。

• PAYLOAD LENGTH：有效载荷长度是有效载荷数据中的八位字节数。 这不包括数据包头的长度，或可选数据完整性检查的长度。
• PACKET HEADER CHECKSUM：包头校验用于验证包头的内容不被破坏。这是通过将包头校验和设置为一个值来计算的，使得包头的四个八位字节（包括包头校验和）的 2 的补码 和 256 取模为 0xFF。
  
  

LINK ESTABLISHMENT

在可以发送除链路控制包之外的任何包之前，必须执行链路建立过程。这确保序列号被正确初始化，还确保两端使用相同的波特率，允许检测对等复位，并允许配置设备。

链路建立由具有三种状态的状态机定义：Uninitialized, Initialized and Active。

当传输第一次启动时，链接处于未初始化状态。

定义了四种消息：SYNC、SYNC RESPONSE、CONFIG 和 CONFIG RESPONSE。

所有四个链路建立消息都应在数据完整性存在标志设置为 0 的情况下发送。

UnInitialized STATE

在未初始化状态下，设备会定期发送 SYNC 消息。如果接收到 SYNC 消息，设备应以 SYNC RESPONSE 消息响应。如果收到 SYNC RESPONSE 消息，设备将进入初始化状态。

在未初始化状态下，只有 SYNC 和 SYNC RESPONSE 消息有效，所有其他接收到的消息都必须丢弃。如果收到无效数据包，设备应以 SYNC 消息响应。

设备不应在未初始化状态发送任何确认包。在未初始化状态下，控制器可能会等待，直到它收到一个 SYNC 消息，然后才发送它的第一个 SYNC 消息。这允许主机控制控制器何时开始发送数据。

Initialized STATE

在初始化状态中，设备周期性地发送CONFIG消息。如果接收到 SYNC 消息，设备应以 SYNC RESPONSE 消息响应。如果收到 CONFIG 消息，设备应以 CONFIG RESPONSE 消息响应。

如果收到 CONFIG RESPONSE 消息，设备将进入 Active状态。接收到的所有其他消息都将被忽略。

Active STATE

在active状态中，设备可以通过传输传输更高层的数据包。

• 如果收到 CONFIG 消息，设备应以 CONFIG RESPONSE 消息响应。
• 如果收到 CONFIG RESONSE 消息，设备应丢弃该消息。
• 如果在处于活动状态时收到 SYNC 消息，则假定对等设备已重置。

因此，本地设备应执行上层堆栈的完全重置，并在未初始化状态再次启动链路建立。进入Active状态后，发送的第一个数据包应将其 SEQ 和 ACK 编号设置为零

LOW POWER

在设备处于活动状态后，传输链路的任一侧可能希望进入低功率状态。由于可以从同步丢失中恢复，因此可以随时停止侦听传入的数据包。

为了在设备进入低功耗状态后使系统响应更快，采用了一种消息系统来允许任何一方通知另一方他们正在进入低功耗状态并将设备从该状态唤醒。这些消息作为链路控制数据包发送。设备支持Sleep message是可选的，Wakeup 和 Woken 消息是强制性的。

• WAKEUP MESSAGE：每当设备认为对方睡着时，唤醒消息应是发送的第一条消息。然后设备将重复发送 Wakeup 消息，直到收到 Woken 消息。
  
  每个唤醒消息的发送之间必须至少有一个字符间隔，以允许 UART 重新同步。Wakeup 消息是不可靠消息，Packet Type 为 15，Payload Length 为 2。有效载荷由八位字节模式 0x05 0xFA 组成。唤醒消息应在设备发送睡眠消息后使用。设备必须响应唤醒消息。
• WOKEN MESSAGE：每当接收到 Wakeup 消息时，即使接收器当前未睡着，也应发送 Woken 消息。收到唤醒消息后，设备可以确定其他设备不处于低功耗状态，并且可以发送和接收数据。
  
  Woken 消息是一个不可靠的消息，包类型为 15，有效载荷长度为 2。有效载荷由八位字节模式 0x06 0xF9 组成
• SLEEP MESSAGE：链路建立完成后，可以随时发送睡眠消息。它通知另一方此设备将进入低功耗状态，并且它也可能进入睡眠状态。如果设备 发送/收到 SLEEP MESSAGE，它应在发送任何数据之前使用 Wakeup / Woken message sequence。
  
  Sleep 消息是一个不可靠的消息，它的 Packet Type 为 15，Payload Length 为 2。有效载荷由八位字节模式 0x07 0x78 组成。此消息的发送是可选的。此消息的接收者无需进入睡眠状态，但协作设备可能能够通过此消息更有效地安排睡眠 。

HCI DATA FORMATS

对于大多数 HCI 命令，Controller 将在命令完成时生成 HCI_Command_Complete 事件。此事件包含已完成 HCI 命令的返回参数。

为了使Host 能够检测 HCI 传输层上的错误，Host command 的传输 和 Controller response（例如 HCI_Command_Complete 或 HCI_Command_Status event）的接收 之间需要超时。由于最大响应超时强烈依赖于所使用的 HCI 传输层，因此建议为此计时器使用默认值 1 秒。该时间量还取决于命令队列中未处理的命令数。

数据和参数格式

除非另有说明，否则所有值均采用二进制和十六进制小端格式。

• 此外，所有可以为负值的参数在指定值时应使用 2 的补码。
• 除非另有说明，HCI 命令包或 HCI 事件包中的参数顺序是参数在命令或事件中列出的顺序。
• 使用以下符号指定数组参数：ParameterA[i]。如果指定了一组以上的数组参数（例如ParameterA[i], ParameterB[i])，那么，除非另有说明，否则参数顺序如下ParameterA[0],ParameterB[0],ParameterA[1],ParameterB[1],ParameterA[2] , ParameterB[2], … ParameterA[n], ParameterB[n]。
• 除非另有说明，所有参数值均以 littleendian 格式发送和接收（即对于多八位字节参数，最右边（最低有效八位字节）首先传输）。
• 大多数未排列的命令和事件参数以及排列参数中的所有元素都具有固定大小（整数个八位字节）。如果参数或数组参数的元素具有可变长度，将在特定命令中注明；然后将在另一个参数中指定长度。为每个命令或事件指定包含在命令或事件中的每个未数组参数（或数组参数中的每个元素）的参数和大小。数组参数中的元素数量不固定。
• 如果命令或事件具有一个或多个数组参数，则为确定数组大小的参数指定的最大值可能会导致数组太大而无法放入 HCI 命令或事件数据包。发生这种情况时，该参数的有效最大值将小于指定的最大值，并且可能取决于其他参数的大小或值。
• 在指定 bit strings 的地方，右手位是低位，例如0 是 0b10 中的低位。
• 如果参数值被描述为“0xXX”或“N = 0xXX”（具有适当数量的“X”），则该描述适用于除给出单独描述的任何值之外的所有可能值。在描述指定范围的情况下，该范围之外的值（如果有）保留供将来使用。
• 实现不知道如何解释的参数值或操作码应被忽略，并且正在尝试的操作应以正确的信令完成。Host或Controller不应因接收到保留值而停止运行。
• 除非另有说明，例如在“强制范围”声明中或因为某个值与不受支持的可选功能相关，否则控制器应支持所有参数的所有有效值（保留供将来使用的值无效）。
  
  

ID 和 Handle

HCI 命令和事件中使用了两种类型的标识符。Host 分配的 ID 是在两个对等设备之间使用的标识符，并在 PDU 中通过空中发送。每种不同类型的 ID 都有一个单独的数字空间。

由 Host 在命令中分配 或 由Controller在事件中分配 的Handle是在 Host 和 Controller 之间使用但不通过空中发送的标识符。 一些Handle共享相同的数字空间，而另一些则具有单独的数字空间。三种类型的句柄用于标识主机和控制器之间的逻辑通道：

• Connection_Handles
• Logical Link Handles
• Physical Link Handles

HCI 特定信息的交换

Host - Controller 传输层提供 HCI 特定信息的透明交换。

这些传输机制为Host 提供了向 BR/EDR Controller 发送 HCI 命令、ACL 数据和同步数据以及向 LE 控制器或 AMP 控制器发送 HCI 命令和 ACL 数据的能力。

这些传输机制还为主机提供了从 BR/EDR 控制器接收 HCI 事件、ACL 数据和同步数据，以及从 LE 控制器或 AMP 控制器接收 HCI 事件和 ACL 数据的能力。

由于主机控制器传输层提供 HCI 特定信息的透明交换，因此 HCI 规范指定了主机和控制器之间的命令、事件和数据交换的格式。

下一节指定 HCI 数据包格式。

HCI Command packet

HCI 命令包 HCI 命令包用于从Host向controller发送命令（无需经过空口channel传输）。HCI 命令包的格式如图 5.1 所示，每个字段的定义解释如下。控制器应能够接受最多 255 字节数据的 HCI 命令包，不包括 HCI 命令包头。

HCI 命令包头是包的前 3 个八位字节。每个命令都分配了一个 2 字节的 Opcode，用于唯一标识不同类型的命令。 Opcode 参数分为两个字段，称为 OpCode Group Field (OGF) 和 OpCode命令字段（OCF）。OGF 占据操作码的高 6 位，而 OCF 占据剩余的 10 位。本部分未提及的任何操作码均保留供将来使用。

0x3F 的 OGF 保留用于供应商特定的调试命令。操作码的组织允许推断附加信息，而无需完全解码整个操作码。注意：由所有“1”组成的 OGF 已保留用于供应商特定的调试命令。

这些命令是供应商特定的，在制造过程中使用，用于更新固件和调试的可能方法。收到供应商特定的调试命令后，Controller应响应：

1. 一个 HCI_Command_Status 事件。如果状态指示成功（第 7.7.15 节），则该事件后面应紧跟一个事件代码字段为 0xFF 的 HCI 事件（第 5.4.4 节）。
2. 一个 HCI_Command_Complete 事件，指定相应的供应商特定调试命令操作码。

Host 可以假装发送 HCI_Vendor_Specific_Debug 命令测试 HCI command credit。

• For the Link Control commands, the OGF is defined as 0x01.
• For the Link Policy commands, the OGF is defined as 0x02. The following OCFs with this OGF were previously used: 0x0005, 0x0006
• For the HCI Control and Baseband commands, the OGF is defined as 0x03. The following OCF with this OGF was previously used: 0x000B.
• For Informational Parameters commands, the OGF is defined as 0x04.
• For the status parameters commands, the OGF is defined as 0x05.
• For the Testing commands, the OGF is defined as 0x06.

HCI ACL Data packets

HCI ACL 数据包用于在 Host 和 Controller 之间交换数据。

HCI ACL 数据包有两种类型：

• Automatically-Flushable
• Non-Automatically-Flushable

Automatically-Flushable HCI 数据包根据自动刷新计时器的设置进行刷新（请参阅读取自动刷新超时命令BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4, Part E 7.3.29）。NonAutomatically-Flushable HCI 数据包不受自动刷新超时控制，不应自动刷新。HCI ACL 数据包的格式如图5.2 所示。

Host 和 Controller 应能够接受最多 27 字节数据的 HCI ACL 数据包，不包括与 LE-U 逻辑链路相关联的 Connection_Handles 上的 HCI ACL 数据包头。 HCI ACL 数据包头是前 4 个八位字节包。

注意：具有与 LEU 逻辑链路关联的 Connection_Handle 的 HCI ACL 数据包将不受自动刷新计时器的影响，因为只允许使用不可刷新的数据包边界标志。AMP 逻辑链路上的所有数据包都受自动刷新计时器的影响。

HCI Synchronous Data packets

HCI 同步（SCO 和 eSCO）数据包（用于从协议栈跟蓝牙芯片双向交户音频数据） 用于在 Host 和 Controller 之间交换同步数据。

同步数据包的格式如图 5.3 所示，HCI SCO 数据包头是包的前 3 个八位字节。

HCI Event packet

Controller 使用 HCI Event 数据包在事件发生时通知 Host 。如果Controller 发送一个 HCI 事件数据包，其中包含一个Host 没有屏蔽并且不支持的事件代码或 LE 子事件代码，Host 应忽略该数据包。本部分未提及的任何事件代码或 LE 子事件代码均保留供将来使用。

Host 应能够接受最多 255 个八位字节数据的 HCI 事件数据包，不包括 HCI Event数据包头。HCI Event报文的格式如图5.4所示，各字段的定义解释如下。

HCI ISO Data packets

HCI ISO 数据包用于在Host 和 Controller 之间交换同步数据。HCI ISO 数据包包含 SDU 或 SDU 的一部分，并且包含的数据不能超过控制器支持的缓冲区大小。如果 SDU 的长度大于控制器的缓冲区大小，则Host可能需要对该 SDU 进行分段。通过 HCI 生成的 SDU 片段与由 ISOAL 生成的 SDU 片段无关。

ISO_Data_Load 字段应包含Header 和 isochronous data，并且可能包含 Time_Stamp 字段。 ISO_Data_Load 字段的格式如图 5.6 所示。

参考文献

• Bluetoorh Core V5.2
• 蓝牙HCI command/event/acl/sco格式介绍