蓝牙®高数据吞吐量技术概述
| 版本： | 1.0 |
| 出版日期： | 2026年11月3日 |
| 作者： | 阿尔弗雷多-佩雷斯 |
1. 导言
蓝牙®（Bluetooth®）是一项用途广泛、被广泛采用的无线技术，可在音频、可穿戴设备、人机交互设备、智能家居、工业、汽车以及许多其他市场领域支持广泛的应用和使用场景。其成功源于节能、互操作性、易用性等基本特性，以及其功能和性能的持续演进。 正是这些特质的综合作用，使蓝牙技术得以大规模推广，推动并支撑了强大的开发与产品生态系统的形成，并赢得了全球企业和消费者的信赖。
然而，无线应用领域也在不断演进。蓝牙连接长期以来蓬勃发展的系统正变得日益复杂，生成、处理和管理的数据量也大幅增加。例如，在音频市场，解决方案正朝着更高保真度和多流应用场景发展，这些场景需要更大的数据传输容量和更快的通信速度，以提供无缝的性能和体验。 对于蓝牙而言，这要求其支持超越现有能力的日益增长的吞吐量需求。为满足这一需求，蓝牙特别兴趣小组（SIG）正在对蓝牙低功耗（Bluetooth LE）推出一项重大的架构和性能增强方案，即蓝牙®高数据吞吐量（HDT）。
自 2016 年推出 LE 2M PHY 以来，蓝牙 LE 支持的最高 PHY 比特率一直为 2 Mbps。借助蓝牙® HDT，蓝牙 LE 的性能和功能得到了显著扩展，最高 PHY 比特率提高了近四倍，同时还提升了数据传输容量、能效和可靠性。 总体而言，蓝牙 HDT 缩短了数据传输时间，支持了要求更高的应用工作负载，并为未来的创新创造了发展空间，为蓝牙技术路线图奠定了基础，使其能够随着现代应用需求的不断变化而持续演进。
本文档提供了关于蓝牙高数据吞吐量（Bluetooth High Data Throughput）的高层级技术概述，旨在帮助读者对这一蓝牙技术的重要里程碑建立基本了解。
2.背景情况
原则上，提高通信系统吞吐量的主要好处很简单：更高的吞吐量可以缩短设备之间传输固定数据量所需的时间，或者反过来说，可以在给定时间间隔内交换更多的数据。然而，在更短的时间内完成传输还能带来其他宝贵的优势。例如，这意味着系统中的发射端和接收端处于活动状态的时间更短，从而可能降低能耗。 此外，这还有助于释放空时资源，这些资源可通过受控共存机制重新分配给额外的通信链路，或供其他共址系统使用。
实际上，提高通信系统的吞吐量需要调整三个基本设计变量：带宽（BW）、信噪比（SNR）和频谱效率。香农定理1 将带宽和信噪比如何影响信道容量进行了数学化表述，表明信道容量随带宽呈线性增长，随信噪比呈对数增长。然而，要接近香农定理预测的信道容量，关键在于实现高频谱效率。 频谱效率是衡量每赫兹可用带宽可传输多少比特每秒（bps/Hz）的指标。在实际系统中，频谱效率取决于物理层的设计选择，例如调制阶数、编码效率、符号率，以及其他影响带宽利用效率的实现因素。
蓝牙技术的架构设计遵循了以下原则：优先考虑简单性、可靠性、在全球范围内可用的免许可频段内高效运行，以及（就蓝牙低功耗而言）能效。正因如此，蓝牙低功耗无线电的物理层基于高斯频移键控（GFSK）——一种简单、稳健且复杂度较低的调制方案，且前向纠错能力有限或完全不具备。 GFSK 物理层的简单性过去一直且今后仍将很好地服务于蓝牙技术，但其频谱效率较低，因此，在显著提高吞吐量方面可选方案有限。
再次参考香农定理，提高GFSK物理层吞吐量的一种方法可能是增加其带宽，但考虑到2.4 GHz ISM频段的限制，更重要的是这将带来的架构和能效方面的影响，这种做法并不现实。 另一种方法是提高其信噪比（SNR），但这同样面临挑战。发射功率受法规限制，而改善接收机噪声性能的空间则十分有限。因此，更可行的方案是突破频谱效率的瓶颈，而这正是蓝牙® HDT所做的。
蓝牙HDT引入了一种新的物理层（PHY），其使用的信道带宽和间隔与蓝牙低功耗（Bluetooth LE）相同。 但更重要的是，该物理层集成了相干高阶调制方案和前向纠错（FEC）技术，从而实现了高频谱效率。蓝牙HDT还引入了新的数据包格式和链路层 更新，以支持自适应调制和链路自适应，在增强抗多径和抗衰落能力的同时，助力实现新物理层的频谱效率目标。此外，蓝牙HDT定义了新的HCI命令和事件以支持新的HDT功能，并引入了相关的安全增强措施。
以下各章将基于其基本构成模块，对蓝牙HDT进行详细概述。本文档将按以下顺序引导读者了解蓝牙HDT的主要组成部分：体系结构、物理层（PHY）、数据包、链路层 （LL）、加密、主机控制器接口（HCI），以及“其他”部分——该部分涵盖了对栈中ISOAL层和主机层的更新。
3. 蓝牙® HDT 架构
在深入探讨蓝牙 HDT 的技术细节之前，先对 HDT 为蓝牙技术带来的优势和价值进行一个高层次的概述会很有帮助：
- 它将支持的最高比特率提高到 7.5 Mbps
- 它不仅提高了吞吐量，还显著提升了无线性能
- 它扩展了可用于支持现有蓝牙应用程序和用例的容量与功能
- 它支持更多样、更丰富的新应用场景，例如高分辨率和无损音频
这些优势是通过蓝牙核心规范中引入的架构创新和改进实现的。本节概述了蓝牙 HDT 的关键架构原则。
3.1 概述
蓝牙 HDT 背后的核心架构目标是：在保持与蓝牙 LE 的向后兼容性的同时显著提高吞吐量；实现高效、可靠地支持更高比特率所需的性能（例如，更高的灵敏度、更强的抗干扰能力，以及在多径和衰落条件下的鲁棒性）；并确保与之前的蓝牙系统相比，实现这些目标所需的实施复杂度处于可控范围内。
要直观了解蓝牙 HDT 带来的创新和增强功能，一个简单的方法是将其与蓝牙 LE 协议栈的结构进行对应。为说明这一点，图 3.1展示了一个简化的蓝牙 LE 协议栈视图，其中为支持 HDT 而进行了更新的层用星号标出。
图 3.1 – HDT 的蓝牙低功耗（Bluetooth LE）协议栈更新
再向下一个层次，从中层视角来看，各堆栈层为实现或支持 HDT 而进行的主要创新和改进可总结如下：
物理层（PHY）
- 一种基于高阶相干调制方案和带穿孔的前向纠错的新型非GFSK物理层
- 支持五种不同的比特率，最高可达 7.5 Mbps
链路层 (LL)
- 一种新的数据包结构
- 三种新的数据包格式变体
- HDT 配置信息交换的新流程
- PHY更新和CIS创建信息交换的更新流程
- HDT 加密和更大的 MIC 长度
主机控制器接口 (HCI)
- 用于设置参数、读取有效载荷、启用测试等操作的新命令
- 将推出新功能，用于报告HDT速率、加密启用状态等
此外，还对蓝牙低功耗（Bluetooth LE）协议栈中的等时适配层（ISOAL）和主机层进行了小幅更新。主机层的更新主要用于支持对MIC长度要求的验证和强制执行，而ISOAL的更新则支持通过新的物理层（PHY）传输更大的数据有效载荷。
本文后续各节将详细介绍最终的、技术分辨率更高的底层视图，其中第4节讨论物理层，第5节讨论数据包，第6节讨论链路层 ，第7节讨论加密，第8节讨论HCI，第9节讨论其他内容（例如ISOAL和主机层）。
3.2 架构原则
蓝牙高数据吞吐量（HDT）是蓝牙低功耗（LE）的扩展，而非一项独立或并行的技术。它在保留蓝牙低功耗所采用的架构框架（例如，相同的物理信道、逻辑传输层、逻辑链路等）的同时，引入了新的功能。
HDT 与现有的基于 GFSK 的蓝牙低功耗 (Bluetooth LE) 设备向后兼容，工作在 2.4 GHz ISM 频段，并采用相同的信道划分方案。 更具体地说，连接始终通过 GFSK 物理层建立，之后设备可选择切换至 HDT 物理层。HDT 的设计使得设备可以在低功耗连接内动态地在 GFSK 物理层和 HDT 物理层之间切换，从而允许支持 HDT 的设备与传统蓝牙低功耗设备共存，并在需要时回退到传统蓝牙低功耗工作模式。必须注意的是，HDT 的初始版本不支持任何形式的广播。
HDT 并非通过增加带宽 (BW) 或信噪比 (SNR) 来提升吞吐量，而是通过提高频谱效率来实现更高的吞吐量。这是通过引入一种基于高阶相干调制方案、并结合前向纠错和穿孔技术的新物理层 (PHY) 来实现的。
HDT 引入了一种新的数据包结构，该结构能够高效支持高数据速率，并定义了多种数据包格式，有助于在不同的运行场景中平衡开销、鲁棒性和效率。其中一种数据包格式（PF1）允许单个 HDT 数据包承载多个有效载荷（这些有效载荷可能来自不同的应用程序或逻辑链路），并将有效载荷数据划分为多个块。这种灵活性使得数据聚合、高效利用无线电资源、优化重传以及本文后文将讨论的其他优势成为可能。
HDT 的设计旨在实现高数据速率下的可靠数据包解码、自适应调制以及基于每个数据包的动态速率自适应。该物理层通过始终采用最稳健的调制方法，并在数据包结构中将控制信息与有效载荷数据分开管理和处理，从而即使在信道条件恶劣的情况下，也能最大限度地提高数据包控制信息被解码的概率。
为了提高对干扰、多径和衰落的抗干扰能力，HDT 在数据包结构中集成了物理层感知机制。使用 HDT 物理层传输的数据包可被划分为多个物理层间隔，每个间隔由已知序列界定，这些序列有助于在接收过程中进行信道跟踪和相位校正。这种方法允许接收端在数据包传输过程中进行重新同步，从而在支持自适应调制和动态速率选择的同时，提高了高数据速率下的可靠性。
为清晰起见，将数据划分为数据块和物理层间隔（PHY Intervals）是相互独立的。两者的关键区别在于：数据块是一种逻辑有效载荷分段机制，而物理层间隔则是物理层（PHY）级别的传输分段机制。在PF1中，每个有效载荷（包括其加密后的MIC）均可划分为多个数据块，每个数据块均由其自身的CRC进行保护。 由此形成的有效载荷区随后可在物理层被划分为固定长度的符号流，称为物理层间隔（PHY Intervals），每个间隔后都跟随一个终止符号序列，并且除最后一个间隔外，还跟随一个物理层间隔训练序列（PITS）。因此，块边界和物理层间隔边界具有不同的用途，并不代表同一划分。 数据块支持有效载荷组织、错误检测和选择性重传，而物理层间隔则通过可管理的解码间隔和周期性的接收机重新训练，支持稳健的空中传输。
HDT 还引入了物理信道地址（PCA）机制，用于唯一标识物理链路。这一增强功能通过提供庞大的地址空间，同时保留 GFSK 物理层（PHY）上访问地址的作用，从而为高密度设备环境带来了益处。物理信道标识机制的分离确保了即使在射频拥塞的情况下，HDT 数据包也能被高效过滤，并正确地与活动连接相关联。一个物理信道可以拥有多个 PCA，每个 PCA 用于不同的物理层（PHY）。
最后，HDT 在不改变蓝牙低功耗（Bluetooth LE）安全模型的前提下，融入了安全考量。HDT 在蓝牙低功耗扩展（链路层 ）中引入了对更长消息完整性检查（MIC）长度的支持，从而增强了长有效载荷的数据认证能力。此外，它还支持加密密钥调度（EKS）功能，该功能为蓝牙低功耗中加密密钥的建立和管理引入了一个新框架。 EKS 可生成会话密钥以及保护加密连接所需的其他加密值，并支持在活动连接期间刷新加密密钥。对于 HDT 而言，EKS 有助于在 GFSK 与 HDT 物理层之间切换时协调加密密钥和 MIC 长度的变更，而无需断开连接或重新启动加密。
显然，引入新的物理层（PHY）以支持HDT，意味着实现HDT需要新的硬件，因此也需要新的无线电模块。虽然蓝牙HDT将与基于GFSK的蓝牙设备向后兼容，但仅支持GFSK的设备将无法支持新的、更高的吞吐量级别。
4. 蓝牙® HDT 物理层 (PHY)
蓝牙 HDT 物理层（PHY）定义了能够实现更高吞吐量的无线电层机制。它被规定为一种可选的蓝牙 LE 物理层，可与必选的 LE 1M 物理层以及基于 GFSK 调制的可选 LE 2M、LE 2M 2BT 和 LE 编码物理层共存。 HDT PHY 在 2.4 GHz ISM 频段内工作，并采用与基于 GFSK 的 PHY 相同的信道带宽和信道间隔。
本节将重点探讨 HDT PHY 的三个基本领域：调制与比特率、比特流处理，以及同步与鲁棒性。
4.1 调制与比特率
调制是指将信息映射到物理载波信号上以实现通信的过程。在蓝牙低功耗（Bluetooth LE）物理层（PHY）中，这种映射传统上采用高斯频移键控（GFSK）实现，其中信息通过射频载波信号频率的微小偏移来传递，每个传输的符号中编码一位数据。
蓝牙 HDT 物理层引入了三种相干调制方案，这些方案将数据表示为复数值符号，并在每个符号中编码多个比特：
- π/4 正交相移键控（π/4 QPSK）
- 8 相移键控（8PSK）
- 16 正交幅度调制（16QAM）
这些调制方案通过射频载波相位的偏移来传输信息；而在16QAM中，则是通过载波相位和幅度的同时偏移来传输信息。在通信过程中，发射的符号由两个信号分量构成，分别称为同相（I）和正交（Q）分量，根据设计，每对I/Q信号代表一个特定的符号值。 对于给定的调制方案，所有可能的I/Q信号对在复平面上映射为点，其集合称为星座图。图4.1展示了π/4 QPSK、8PSK和16QAM的星座图。
图 4.1 – HDT 调制方案的星座图
相干调制意味着该方案支持通信系统发送端与接收端之间的频率和/或相位锁定，这有利于同步，并能降低出错概率。而非相干方案则不存在这种锁定，虽然系统结构更简单，但在可比条件下，通常比相干调制更容易出错。HDT采用相干调制。
HDT PHY 将新的调制方案与卷积前向纠错（FEC）和穿孔技术相结合。FEC 基于 ½ 编码率的卷积编码实现，而穿孔技术则用于实现更高的编码率。 总体而言，HDT 支持五种不同的比特率，所有比特率均以 2 Msym/s 的固定符号率运行。从架构上讲，不同的比特率被视为单一 PHY 的工作模式。表 4.1总结了每种比特率的相关特性。
表 4.1 – HDT 速率
| HDT速率 | PHY 比特率 | 调制方案 | 每符号位数 | 控制器实现 |
|---|---|---|---|---|
| HDT2 | 2 Mbps | π/4 QPSK | 2 | 强制性 |
| HDT3 | 3 Mbps | π/4 QPSK | 2 | 强制性 |
| HDT4 | 4 Mbps | 8PSK | 3 | 强制性 |
| HDT6 | 6 Mbps | 16QAM | 4 | 可选 |
| HDT7.5 | 7.5 Mbps | 16QAM | 4 | 可选 |
HDT4及以下速率为必选，HDT4以上的速率为可选。如果支持HDT6，则HDT7.5为可选；如果支持HDT7.5，则HDT6也是必选的。对于每种速率，如果支持接收（Rx），则发送（Tx）为可选；如果支持Tx，则Rx为必选。
有关完整细节（包括符号坐标表、实现要求等），请参阅《蓝牙核心规范 7.0》的相关章节。
4.2 比特流处理
将数字数据转换为符号，以便通过无线通信链路进行收发，需要通过一种结构完善的处理模型（即比特流处理管道）来管理此类数据的流转。
蓝牙 HDT 的物理层（PHY）规范定义了一个用于处理 HDT 流量的确定性比特流处理流水线，如图 4.2 所示的框图所示。这是基于 GFSK 的低功耗（LE）物理层中流水线的扩展，增加了间隔间距和穿孔机制。无论选择何种物理层速率，所有处理阶段始终按相同的顺序进行。
在发送端，原始数据位依次经过加密（若已启用）、循环冗余校验（CRC）生成、数据白化、间隔调整、前向纠错（FEC）编码以及穿孔处理。 生成的位序列随后被转换为调制后的I/Q信号，这些信号代表将通过无线电传输的符号。需要注意的是，间隔划分仅在使用HDT数据包格式1（PF1）时适用（用于划分有效载荷比特流并支持多个物理层间隔）。完整的数据包结构和格式定义详见第5节。
在接收端，接收到的符号会经过相应的逆处理阶段，以提取所发送的数据位（穿孔处理除外）。
图 4.2 – HDT 比特流处理流水线
管道中的所有阶段在 HDT 比特流处理中都是通用的，但物理层（PHY）对控制信息和有效载荷数据采用了不同的处理规则。控制信息之所以被单独处理，是因为新的 HDT 数据包结构定义了一个与承载有效载荷的部分相分离的“控制头”。这种数据包结构上的分离是一种架构设计决策，旨在支持关键的物理层性能目标，具体原因将在下文说明。
接收端必须成功解码控制头，才能从数据包中提取后续的高吞吐量有效载荷。 为了最大限度地提高控制信息被解码的概率——即使在信道条件较差的情况下也是如此——控制信息始终采用 π/4 QPSK 进行调制，这是 HDT 中现有的最稳健的调制方案。为此，控制数据的比特流处理会形成其自身的符号流，省略白化处理，并采用 ½ 的编码率进行前向纠错（FEC），且不进行穿孔。这有助于在更高的数据速率下提高数据包解析的可靠性。
通过预先处理控制信息（并与有效载荷分开处理），还可实现逐包的动态数据速率自适应。更具体地说，数据包的控制头携带了与后续有效载荷部分相关的详细信息，包括数据包格式、选定的数据速率、物理层间隔配置等。 当控制信息被提前接收并解码后，接收端即可配置为正确的解调和解码设置以处理有效载荷；更重要的是，还能根据需要针对每个数据包动态调整这些设置。此外，当传输的有效载荷数据被拆分为多个物理层时隙时，这种机制还能使接收端做好准备，以支持数据包中途的接收端重新同步，从而在衰落或时变信道中提高链路鲁棒性。
作为参考，表 4.2概括性地总结了比特流处理流水线中各个阶段的作用以及需要了解的相关事实。
表 4.2 – HDT 比特流流水线阶段汇总
| 比特流阶段 | 摘要 |
|---|---|
| 加密 | • 通过在进一步处理前应用加密变换来确保数据机密性 • 在加密启用时应用于有效载荷（例如，HDT数据包中的PDU头和有效载荷区） • 遵循第7节中详细描述的HDT加密框架 • 在处理管道的早期阶段进行，以在保持与后续错误检测和纠错阶段兼容的同时，最大限度地提高安全覆盖范围 |
| 儿童权利委员会 | • 按有效载荷块计算（如已加密，则在加密后计算） • 提供对随机错误和突发错误的检测 |
| 美白 | • 将位模式随机化，并打断长串相同的位序列，确保数据流中具有足够的状态转换，从而实现可靠的时钟恢复 • 仅应用于有效载荷（例如，HDT数据包中的PDU头和有效载荷区）；从控制头之后的第一个PDU头位开始，到数据包中有效载荷区的最后一个数据位结束 |
| 间隔距离 | • HDT 数据包格式 1 专有功能 • 支持将有效载荷区划分为固定长度的传输间隔 • 支持周期性插入物理层间隔训练序列（PITS），以刷新信道估计 |
| FEC编码 | • 适用于所有传输的数据（例如，HDT数据包中的控制头、PDU头和有效载荷区） • 采用以½编码率为基准的非系统性、非递归卷积编码（约束长度K=6） • 既能纠正随机错误，也能纠正短突发错误 |
| 穿刺 | • 从FEC编码的比特流中选择性地移除特定比特 • 不同的穿孔模式与单一的、基数为1/2的卷积编码器相结合，可产生多种数据速率，这些速率可根据信道状况自适应地调整 • HDT的穿孔模式可最大化每个目标数据速率的自由距离，该指标（参数 ）用于衡量码率在噪声下的鲁棒性 • PF1对有效载荷区进行穿孔，但不穿孔PDU头；PF0则对两者均进行穿孔 |
为使内容更完整，表4.3总结了各HDT数据速率下与穿孔相关的参数。需要注意的是，HDT3和HDT6虽然采用相同的穿孔模式和编码率，但它们使用的调制方式不同。
表 4.3——HDT 穿刺参数汇总
| HDT速率 | 穿孔图案（1=保留，0=省略） | 穿刺效率 (Ep) | 有效编码率 |
|---|---|---|---|
| HDT2 | [1 1] | 1.0 (2/2)简体中文（大陆） | 1/2 |
| HDT3 | [1 1 0 1 0 1] | 0.667 (4/6) | 3/4 |
| HDT4 | [1 1 0 1] | 0.75 (3/4)简体中文（大陆） | 2/3 |
| HDT6 | [1 1 0 1 0 1] | 0.667 (4/6) | 3/4 |
| HDT7.5 | [1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 1 0 1 0 0 1 0 1 0 1 1 0 0 1] | 0.933 (28/30) | 15/16 |
4.3 同步与鲁棒性
与GFSK相比，HDT所采用的高阶相干调制方案本质上对相位或频率噪声、漂移以及信道变化更为敏感。正因如此，HDT物理层引入了多种机制，旨在支持高数据速率下的精确同步和鲁棒解码，从而实现预期的频谱效率提升，并在存在信道退化、衰落或多径失真的严苛无线环境中提供可靠的性能表现。
表 4.4概述了这些机制各自的作用以及需要了解的相关事实，其中包括训练序列（短序列和长序列）、保护间隔、终止符号、PHY 间隔以及 PHY 间隔训练序列（PITS）。
表 4.4——HDT 训练与同步机制汇总
| 机制 | 摘要 |
|---|---|
| 短训练序列（STS） | • 支持快速初始数据包检测、粗略时序对齐和自动增益控制（AGC）稳定 • 出现在前导码中，即每个 HDT 数据包的开头，并连续重复多次 • 建立进入数据包的可靠入口点 |
| 长训练序列（LTS） | • 支持精细时序对准、频率偏移估计/校正以及初始信道估计 • 也出现在HDT数据包的前导码中，位于STS之后，并连续重复多次 • 为接收机的相干解调做好准备 |
| 保护间隔（GI） | • 用于吸收因训练序列、符号流以及调制或编码边界之间的切换而产生的瞬态效应的时间缓冲区 • 在前导码中（STS与LTS之间）明确出现，并在整个数据包中通过终止符号隐式存在 • 允许接收机滤波器和定时环在进行精细的LTS同步之前稳定下来，并确保符号流之间的平稳过渡 |
| 终止符号 | • 在符号流之间建立明确的边界，并吸收符号流转换时的瞬态效应 • 出现在数据包中每个独立处理的符号流的末尾（例如，控制头之后、PDU头区之后、数据包格式1中的每个物理层间隔之后等） • 允许FEC解码器在下一段/流开始前清空状态并重置 • 对于数据包格式1而言尤为重要，有助于限制独立处理的符号流之间的误差传播 |
| PHY 间隔 | • 允许将长有效载荷拆分为更小、更易于管理的解码单元 • 仅出现在数据包格式 1（PF1）HDT 数据包的有效载荷区中 • 在长 PF1 有效载荷的各间隔之间启用周期性信道跟踪和重新训练 |
| PHY间歇训练序列（PITS） | • 启用数据包中途重新训练，以刷新相位和信道估计，从而实现对划分为多个物理层间隔的有效载荷的鲁棒接收 • 仅出现在数据包格式 1（PF1）HDT 数据包的“有效载荷区”中 |
HDT PHY 中的同步和鲁棒性要素共同构成了一个分层框架，以实现可靠、高吞吐量的运行。首先，通过基于前导码的鲁棒训练（采用 STS 和 LTS）实现初始捕获。随后，借助保护间隔和终止符号，建立并强制执行清晰的过渡和明确的解码边界。 最后，通过物理层间隔及其相关的训练序列，实现了数据包中间的重新同步，从而在处理更长的数据包和更高的数据速率时，能够适应不断变化的信道条件。这种结构化的方法确保了系统对衰落、相位漂移和多径效应的鲁棒性，使 HDT 能够在保持鲁棒性和高效性的同时，实现显著的吞吐量提升。
5. 蓝牙® HDT 数据包
蓝牙® HDT 定义了一种新的数据包结构，该结构将上一节介绍的物理层（PHY）功能与第 6 节中将要介绍的链路层 智能和流程相结合，从而切实可靠地提供更高的吞吐量和更稳定的性能。
本节介绍了 HDT 数据包的结构和数据包格式，并从宏观层面概述了其各个区域、部分和/或字段。
5.1 HDT数据包结构概述
如图5.1所示，HDT数据包结构由四个区域组成：前导码、控制头、PDU头区域和有效载荷区域。前导码和控制头是必备的，所有HDT数据包格式中都必须包含这两个区域。PDU头和有效载荷区域是否存在则取决于所选的数据包格式。
图 5.1 – HDT 数据包结构
HDT数据包结构的深度使得PDU头和有效载荷区域携带了四层详细信息。为了使通信更加清晰，与数据包最高层相关的字段被称为“区域”，与下一层相关的字段被称为“部分”，而底层两层的字段则简称为“字段”。 例如，人们会说 HDT 数据包结构的 PDU 报头区包含一个 TX 部分，其中指定了 LL 描述符字段，并包含每个有效载荷的 LLID 字段（该字段包含链路层 ID）。采用这种命名方法的优势将在本节后文中显而易见。
从整体来看，HDT数据包结构中各区域的作用和组成可概括如下。
序言
- 使接收端能够识别传入数据包的起始位置，与发送端进行同步，校正时序、频率或相位偏移，并执行信道估计以减轻无线信道引入的振幅和相位失真
- 由九次短训练序列（STS）重复组成，随后是一个保护间隔（GI），接着是两次长训练序列（LTS）重复
控制头
- 允许接收方将传入的数据包与正确的物理链路关联起来，可靠地解码关键控制信息（通过专用的报头错误检查），并在进行任何有效载荷解调或处理之前完成这些操作
- 由七个字段组成，用于传递控制信息，包括HDT数据包地址（HPA-A）、数据包格式、速率选择等。
PDU 头区
- 携带协议级元数据，供接收方解释和管理随后在“有效载荷区”中出现的有效载荷数据，包括数据包类型（例如传输类型、链路 ID 等）、有效载荷长度等。
- 由五个部分组成：初始部分、RX、TX、扩展头和头错误校正（HEC-P）
有效载荷区
- 包含传输的有效载荷块（若经过加密，则包含其消息完整性检查）以及CRC值，并按所使用的数据包格式进行组织
- 资料包各部分涵盖的详细内容
5.2 HDT数据包格式
为了在不同的通信场景中实现高效性和灵活性，HDT定义了三种数据包格式：短数据包、数据包格式0（PF0）和数据包格式1（PF1）。
简短格式
短数据包格式是一种开销极小的结构，最适合于无需传输数据的情况。它能减少空中传输时间（例如，时长始终精确为69微秒），并有助于设备之间的同步以及确认信息的交换。从结构上看，短格式仅由前导码和控制头组成，如图5.2所示。
图 5.2 – HDT 数据包（简短格式）
数据包格式 0 (PF0)
数据包格式 0 是一种复杂度较低的结构，最适合以单个数据块的形式传输未分段的有效载荷。从结构上看，PF0 由前导码、控制头、PDU 头区和有效载荷区组成（当有效载荷为空时，有效载荷区可能成为可选部分）。
如果经过加密，有效载荷区中的单个数据块将包含一个 MIC。有效载荷区还包含一个用于错误检测的 CRC，该 CRC 是根据整个 PDU 报头、有效载荷数据块和 MIC 的和计算得出的。图 5.3展示了 PF0 的结构。
图 5.3 – HDT 数据包格式 0 (PF0)
数据包格式 1 (PF1)
数据包格式 1（PF1）是一种功能最强大、最稳健的结构，最适合高效、可靠地传输大量数据。从结构上看，PF1 由前导码、控制头、PDU 头区和有效载荷区组成。
PF1 允许在有效载荷区（例如，等待传输的接下来四个有效载荷）中聚合最多四个不同的有效载荷，如果启用了加密，则每个有效载荷都有其 MIC。每个有效载荷均可划分为多个块（1-16），并为每个块计算 CRC。除最后一个块外，所有块的大小均相同，但每个有效载荷的块大小可以不同。图 5.4展示了 PF1 的结构。下标 M、N 和 P 分别表示有效载荷 0、1 和 2 的块数。
图 5.4 – HDT 数据包格式 1 (PF1)
“块”是HDT数据包有效载荷区中一种新的有效载荷传输和验证单元。HDT不再将有效载荷视为一个整体，而是将其作为一系列块来处理，每个块都由其自身的CRC进行保护，从而允许接收方独立验证各个块。 该概念的核心优势在于，在传输较大有效载荷/数据包时，能够实现选择性确认和重传，从而提高吞吐量。数据包的各部分在成功接收后可分别确认；当干扰导致有效载荷部分损坏时，HDT 物理层只需重传缺失或损坏的块，而成功接收的块则无需重传。
块粒度支持多路复用和持续吞吐量，与 PF1 将最多四个有效载荷聚合到一个数据包中的能力相辅相成。给定有效载荷的块大小在 PDU 报头区的 TX 部分中指定。
通常情况下，HDT 通过有效载荷编号和滑动有效载荷窗口来管理有效载荷的传输、确认和重传。在 ACL 或 CIS 连接的每个方向上，有效载荷窗口包含 1 到 4 个符合传输或重传条件的有效载荷，从 CurrentPayloadNumber 开始。随着窗口开头的有效载荷被确认，CurrentPayloadNumber 会递增，从而推动窗口向前移动。 ExpectedPayloadNumber 标识预期从对等设备接收的下一个有效载荷。SN 和 NESN 分别携带 CurrentPayloadNumber 和 ExpectedPayloadNumber 的最低三位，从而使设备能够跟踪有效载荷窗口的状态。 该有效载荷编号模型同时适用于 PF0 和 PF1。PF0 只能传输或重传窗口中的第一个有效载荷，而 PF1 可以传输或重传窗口内有效载荷中的选定块。
总而言之，表5.1对这三种数据包格式进行了比较。
表 5.1 – HDT 数据包格式汇总
| 简短 | PF0 | PF1 | |
|---|---|---|---|
| 最大载荷 | 不适用 | 494 字节 | 8175 字节 |
| 适用于 | 同步、确认 | 更高的吞吐量 | 最高的吞吐量、效率和/或可靠性 |
| 主要优势 | 当没有待传输的有效载荷数据时，以及仅需对连续的完整有效载荷进行确认时，可减少空中传输时间 | • 实现更简单 • 开销更低 • 带 MIC 的单一有效载荷块 | • 一个数据包中最多可包含四个有效载荷 • 将有效载荷划分为数据块 • 选择性（数据块）确认 • 有效载荷数据块可分布于多个数据包中 • PHY 间隔，使用 PITS 进行相位跟踪 |
现在，让我们简要而详细地回顾一下数据包结构中的各个区域。
5.3 前言
图 5.5说明了前导码的结构和时序。有关训练序列和保护间隔的更多技术细节，请参阅《蓝牙核心规范》第 6 卷 A 部分第 7.4 节。
图 5.5 – HDT 数据包前导码
5.4 控制头
图5.6展示了控制头（Control Header）的格式和字段。
图 5.6 – HDT 数据包控制头
- HPA-A（HDT 数据包地址——部分）：完整的 40 位 HPA 中的第 39 至 24 位。提供一个部分地址，使接收方能够过滤传入的数据包并识别候选物理链路。
- NESN（下一个预期序列号）：包含 ExpectedPayloadNumber 的最低三位，并提供从对等设备接收到的有效载荷的累积确认信息。随着已确认的有效载荷在有效载荷窗口中向前推进，NESN 反映了预期从对等设备接收到的下一个有效载荷。
- PFI（数据包格式指示符）： 表示数据包所采用的格式。该字段为动态字段，可能因数据包而异。
- 0：简短或格式 0；1：格式 1
- 空格可以随时插入
- 可随时在PF0和PF1之间切换
- 在某些情况下，可以从 PF1 切换到 PF0
- RI（速率指示器）： 指定 PDU 头和有效载荷区域的数据速率。该字段是动态的，可针对每个数据包进行调整，从而能够根据信道状况快速适应 PHY 速率。
- 0b000：短格式（无数据区）
- 0b001-0b101：速率范围为 2 Mbps 至 7.5 Mbps。
- RFU（保留供将来使用）
- PDU 控制： 内容取决于数据包格式
- 简述：包含用于即时链路控制的 MD/CIE（更多数据/近等时事件）字段、3 个 RFU 位以及 SNR（信噪比）字段
- 格式 0：一个 9b 值，用于指定组合后的 PDU 头和有效载荷区域的总长度，不包括 CRC
- 格式 1：包含 6b 的 PDU 头区长度（不包括 HEC-P 部分）、2b 的 PHY INT（表示每个 PHY 间隔中的有效载荷符号数 [00：128；01：256；10：384；11：512]）以及一个 RFU 位
- HEC-C（报头错误检查——控制）：基于所有前置控制报头字段计算得出的24位循环冗余校验（CRC），其初始值采用完整的HPA，这使得接收方能够根据相应的HPA验证控制报头，并将数据包正确地与相应的物理链路关联起来。
5.5 PDU 头区
图5.7展示了PDU报头区的格式及其各部分。
图 5.7 – HDT 数据包 PDU 报头区各部分
起始部分
初始部分是一个 8b 字段，作为整个 PDU 头区的控制映射和入口点。它定义了可选部分的存在，并承载传输层特有的控制信息。初始部分的解释取决于传输类型，具体总结如表 5.2 所示。
表 5.2 – 运输类别的“初始部分”字段
| 比特 | ACL | 独联体 | 统计研究所 |
|---|---|---|---|
| 0 | XHP（扩展头存在） | XHP（扩展头存在） | XHP（扩展头存在） |
| 1 | RxPP（处方部分存在） | RxPP（处方部分存在） | 已修正 0（无接收部分） |
| 2 | MD（更多数据）：保持连接事件处于打开状态，以便继续传输 | CIE（接近等时事件）：表示子事件已提前完成 | CSTF（控制子事件传输标志）：表示后续数据包中将包含一个 BIG 控制 PDU；在数据 PDU 中设置 |
| 3-5 | SN（序列号）：CurrentPayloadNumber的最低 3 位，用于标识发送方在有效载荷窗口中的当前位置 | SN（与数据PDU的ACL相同） | CSSN（控制子事件序列号） |
| 6-7 (PF0) | LLID（逻辑链路标识符） | LLID（逻辑链路标识符） | LLID（逻辑链路标识符） |
| 6-7 (PF1) | TxPP（Tx成分存在）+ RFU | TxPP（Tx成分存在）+ RFU | TxPP（Tx成分存在）+ RFU |
处方部分
当需要使用选择性确认来指示已收到对等设备发送的数据时，ACL 或 CIS 数据包中会包含 Rx 部分。其格式和字段如图 5.8 所示。最多可针对四个有效载荷提供细粒度反馈。
图 5.8 – PDU 头区、接收部分的格式和字段
- RxPayloadMap：指示本数据包中确认了接下来四个预期有效载荷（P+0 至 P+3）中的哪一个
- RxAck P+k（每个有效载荷 2b）： 指定每个有效载荷 k 的确认粒度
- 00：未确认。既未收到有效载荷，也未收到任何特定数据块，且均未通过验证
- 01：已完全确认。整个有效载荷已正确接收（此有效载荷后不跟随 RxBitmap）
- 10/11：部分确认。对有效载荷中的特定逻辑块（而非全部）进行确认。该有效载荷后跟一个包含 1 或 2 个字节的 RxBitmap。
- RxBitmap（8位或16位）： 一个位掩码，其中“1”表示已成功接收并验证了相应的逻辑块（由有效载荷的分段定义）。其大小由有效载荷中的块数（Nb+1）决定。
- 所有不需要的位均被设为1，因此只有0xFF和0xFFFF表示已完全接收并验证通过
- For 8b bitmask, the 8 most significant bits are set to 1; an 8b mask can only be used if Nb<8 or if all blocks after number 8 have already been acknowledged
Tx 部分
格式 1 数据包中包含 Tx 部分，用于描述传输的内容，使接收方能够识别特定有效载荷并据此重建数据块。其格式和字段如图 5.9 所示。最多可为四个有效载荷提供细粒度的详细信息。
图 5.9 – PDU 头区、发送部分的格式及字段
- TxPayloadMap：指示传输窗口中接下来的四个有效载荷（P+0 至 P+3）中，哪些的有效载荷块包含在此数据包中
- DscType P+k（每个有效载荷 2b）： 描述了以下 LL 描述符在有效载荷 k 下的格式
- 00：缺失（此有效载荷中没有数据块）
- 01：2字节描述符
- 10：5-八元组描述符
- 11：6-八元组描述符
- LL 描述符（2、5 或 6 个八位字节）： 包含特定有效载荷的元数据，该有效载荷的各块均已存在
- 有效载荷长度（13b）：整个有效载荷的总长度（如有，包括MIC）
- LLID（2b）、RFU（1b）：逻辑链路标识符和保留位
- Nb (4b)：块数 – 1；0 表示 1 个块，15 表示 16 个块。用于定义有效载荷被划分为多少个块。
- 区块大小 (9b)： 有效载荷中除最后一个区块以外的所有区块的大小（范围为 32 至 511 个字节）。最后一个区块的大小是可变的，可以在 32 到 Blocksize+32 个字节之间任意取值。
- 如果 Nb=0，则单个数据块的大小可以在 0 到 510 个字节之间
- TxBlockMap（8位或16位）： 一个位掩码，用于指示哪些特定块（由 Nb 和 BlockSize 定义）包含在此数据包中。1 表示该块存在。
- 不需要的位被设为0
扩展标题
扩展报头是一种紧凑的、基于标志的结构，可在不产生固定开销的情况下支持多种可选功能。其存在由初始部分中的 XHP（扩展报头存在）位指示。除标志字节 0 之外，所有字段均为可选。其格式和字段如图 5.10 所示。
图 5.10 – PDU 头区、扩展头部分的格式和字段
- 标志位编码：通过 7×O+B 方案指定功能，其中 O 是基于零的标志字节索引，B 是位位置（1-7，其中位 0 保留供将来使用）。将标志位设置为 1 表示存在相应功能，且其数据字节包含在“功能数据”区域中。
- 特征数据顺序：特征数据字节在所有标志字节之后，按照其特征 ID 的严格数字顺序进行拼接。
扩展头支持一组针对HDT至关重要的精选功能，每项功能都有其特定用途和严格的实现规则。这些功能是针对逻辑传输类型（ACL、CIS、BIS）量身定制的，并在表5.3中进行了总结。
表 5.3 – 扩展头功能
| 特辑编号 | ACL | 尺寸 | 独联体 | 尺寸 | 统计研究所 | 尺寸 |
|---|---|---|---|---|---|---|
| 1 | 扩展头功能的数据长度 | 10月1日 | 扩展头功能的数据长度 | 10月1日 | 扩展头功能的数据长度 | 10月1日 |
| 2 | 链接质量 | 10月2日 | 链接质量 | 10月2日 | — | — |
| 3 | — | — | NPI | 10月0日 | — | — |
| 4 | 流量控制 | 10月0日 | — | — | — | — |
| 5 | NPI | 10月0日 | — | — | — | — |
特征数据长度
- 提供扩展头中所有后续特征数据字节的总长度
- 在所有包含扩展头（Extended Header）的格式 0 数据包中，该字段均为必填项。这一要求至关重要，因为格式 0 数据包中缺少用于 PDU 头区（PDU Header Zone）的显式长度字段。接收方依赖该值来准确定位有效载荷区（Payload Zone）的起始位置。
- 允许在 PF1 中包含该字段，但无需像 PF0 那样对数据包进行解码（通常省略该字段以节省空中传输时间）
- 一个单字节字段，其中包含一个无符号整数，表示后续特征数据字节的总数
链接质量
- 通过向发送方提供关于最近接收的数据包质量的反馈，实现自适应数据速率（ADR）控制
- 仅当两台设备均支持“链路质量反馈”功能时，才可使用此功能
- 一个2 oct字段，结构如下：
- RSSI（第0至7位）：接收信号强度指示
- SNR（第8-12位）：信噪比
- 首选速率（第13-15位）：一个3b码，表示接收方针对后续传输推荐的物理层数据速率（HDT2-HDT7.5）。值为0表示无具体推荐。
流量控制
- 两个状态值：STOP 和 GO
- 为ACL连接提供即时、按数据包的流量控制
- 接收方在收到包含此特性的数据包后，其链路层 必须将对应方向的本地流控制状态设置为STOP
- STOP 状态的含义： 处于STOP状态时，发射器仅允许发送：
- 来自有效载荷的块，其中至少有一个块已被确认（即重传）
- 控制 PDU（通过 LLID = 0b11 标识）
- 恢复至GO状态：当接收到后续不包含“Stop”特征的有效数据包时，流量控制状态将恢复至GO状态；这意味着，若要保持在STOP状态，则无法发送短格式数据包
空PDU指示器（NPI）
- 明确区分了“空PDU”（一种无数据意图的协议占位符）与“空PDU”（一种有效的数据PDU，其有效载荷长度为零）。
- 此功能仅适用于有效载荷区为空（长度 = 0）的格式 0 数据包
- 语义：
- NPI = 1：该 PDU 是一个空 PDU。它用作占位符（例如，用于计时或确认），且未与有效的 PayloadNumber 相关联。它不会推进数据序列。
- NPI = 0 或特征缺失：该 PDU 与一个有效的 PayloadNumber 相关联。其有效载荷中可能包含数据字节，也可能是空 PDU。
HEC-P
HEC-P（报头错误检查——PDU报头）是一个24位CRC，覆盖整个PDU报头区（不包括其自身）。它仅存在于PF1中（在PF0中省略），并由HPA初始化。
5.6 有效载荷区
有效载荷区的结构由所选的数据包格式决定，该格式定义了数据的组织、传输和保护方式。表 5.4比较并总结了数据包格式 0 与格式 1 在有效载荷区方面的主要差异。
表 5.4——PF0 与 PF1 有效载荷区的比较
| PF0 | PF1 | |
|---|---|---|
| 有效载荷数据 | 包含在单个连续的块中并以此方式传输 | 由最多四个有效载荷聚合而成，经过分段处理，并以多个数据块的序列形式传输 |
| 每个数据包的最大有效载荷 | 1 | 1 至 4（通过 TxPayloadMap 识别） |
| 载重能力（尺寸） | 0-494 字节 + 如有则包含麦克风 | 0-8175 个字节 + 如有则包含 MIC |
| CRC保护 | 单个 32b CRC，覆盖合并后的 PDU 头区和有效载荷区 | 每个数据块包含32b CRC；每个数据块后紧跟其对应的CRC。 |
| 关键考虑因素 | 简单；与常见的PDU型号类似 | 由于数据包长度增加，结合选择性分块确认和重传机制，吞吐量得以提高 |
| PHY 间隔支持 | 不 | 是 |
在 PF1 中，必须在 PHY 层将数据划分为间隔，并采用终结符和 PITS 以提高通信过程中的鲁棒性（除非有效载荷区长度短于一个间隔）。
在数据链路层（链路层 ），有效载荷被分割为数据块，以实现选择性确认和重传。数据块由数据链路层（链路层 ）通过数据块映射/位图进行跟踪和引用。在物理层（PHY），有效载荷区通过比特流处理管道中的间隔划分阶段，进一步被分割为固定长度的符号流，称为物理层间隔（PHY Intervals）。
物理层间隔由固定数量的载荷符号组成，其后紧跟一个终止符号序列和一个物理层间隔训练序列（PITS），但最后一个间隔之后除外。PITS 提供了一个已知的训练模式，使接收机能够在数据包传输过程中刷新定时和载波频率/相位参考，从而管理和减轻信道退化对 PF1 传输的较长聚合载荷的影响，以实现吞吐量的最大化。
PHY 间隔大小的配置由控制头中的 PHY INT 字段完成，如表 5.5 所示。
表 5.5 – 每个 PHY 间隔中的符号数
| PHY INT | 每个区间的符号数 |
|---|---|
| 0b00 | 128 |
| 0b01 | 256 |
| 0b10 | 384 |
| 0b11 | 512 |
该物理层时隙的比特流还包含必要的FEC终止位和零填充（如有需要）。调制后，每个物理层时隙的实际符号数会随数据速率略有变化，具体详见表5.6。
另请注意，不同的PHY速率对应的每符号位数也不同。因此，在PHY INT 0b00中，HDT2时的数据为128位（16个字节），HDT3时的数据为192位（24个字节），HDT4时的数据为256位（32个字节）， 在 HDT6 时为 384 位（48 个字节），在 HDT7.5 时为 480 位（60 个字节）。
表 5.6 – 不同数据速率下的 PHY 间隔符号数
| PHY INT | HDT2 | HDT3 | HDT4 | HDT6 | HDT7.5 |
|---|---|---|---|---|---|
| 0b00 | 133 | 132 | 131 | 130 | 130 |
| 0b01 | 261 | 260 | 259 | 258 | 258 |
| 0b10 | 389 | 388 | 387 | 386 | 386 |
| 0b11 | 517 | 516 | 515 | 514 | 514 |
为了便于直观理解，图5.11重复展示了PF1的结构，说明了有效载荷区（Payload Zone）被进一步划分为物理层间隔（PHY Intervals）的情况。
图 5.11 – 将 PF1 有效载荷区划分为块和 PHY 间隔
从物理层（PHY）的角度来看，图5.12以符号为单位，对这三种HDT数据包格式提供了另一种视图，同样是为了便于可视化。
图 5.12 – HDT 数据包格式的物理层视图
请注意，终止符号标记了 HDT 数据包内符号流的结束，其中每组终止符号由两个全零位符号组成，这些符号根据前一个符号流的调制方案进行调制。对于 PF0，终止符号插入在控制头之后以及组合后的 PDU 头和有效载荷之后。 对于 PF1，终止符号出现在控制头之后、PDU 头之后以及每个物理层间隔之后。
6. 蓝牙® HDT链路层 (LL)
蓝牙 HDT 引入了新的或更新的功能、流程和控制 PDU，以扩展蓝牙低功耗（Bluetooth LE）链路层 的功能，从而支持新的物理层（PHY）和数据包格式，并实现 HDT 旨在提升的吞吐量、性能、可靠性和安全性。
从宏观层面来看，特性定义了设备可能支持的功能，而流程则定义了设备为使用或管理这些功能所需执行的协调操作。控制PDU是设备之间交换的链路层 消息，用于传递执行流程所需的信息、参数和/或状态变化。由此可见，特性描述了可用的功能，流程定义了设备如何协调这些功能的使用，而控制PDU则提供了用于实现这种协调的消息。
本节概述了由蓝牙HDT带来的链路层 功能扩展，总结了链路层 中用于启用HDT的新功能、版本升级功能和更新功能，以及相关操作流程和控制PDU。
6.1 HDT中链路层 新功能的概述
HDT的启动与管理
蓝牙® HDT 通过基于连接的操作来启动和管理，这些操作通过数据物理信道和 ACL 传输层进行。然而，一旦设备之间建立了支持 HDT 的链路，该链路即可用于支持 ACL 连接或连接式等时流传输。
在等时广播的情况下，设备必须使用基于GFSK的广播来查找周期性广播。然后，无需建立ACL连接，即可发送或接收包含一个或多个BIS的BIG。HDT PHY目前不支持任何形式的广播。
总体而言，HDT操作必须始终通过已定义的链路层 程序显式启动。此外，它还要求在链路两个方向上（广播除外）对称地使用PHY，这意味着发送和接收活动必须都使用HDT PHY，或者都使用GFSK PHY（视具体情况而定）。使用HDT PHY时，数据速率可以按数据包逐个独立变化，无需在两个方向上使用相同的速率。
新的 HDT 配置交换程序允许设备之间进行通信并协商所支持的 HDT 功能（例如，最大数据速率、数据包格式、有效载荷大小等）。 随后，通过使用版本升级后的 LL_PHY_REQ [v2]、LL_PHY_RSP [v2] 和 LL_PHY_UPDATE_IND [v2] 控制 PDU 来执行 PHY 更新流程，即可将通信切换至 HDT PHY，或管理向 HDT 的过渡或从 HDT 的退出。 当设备之间的 HDT 功能不兼容、不被支持，或者运行条件要求时，通信可以保持在 GFSK PHY 上或返回 GFSK PHY，所有 PHY 状态变化都会通过 HCI 事件报告给主机，以便进行监控和控制。
HDT 数据长度管理与调度
HDT引入了数据长度管理功能，使链路层 能够针对通过HDT和GFSK物理层建立的每条连接，分别设置传输长度和定时参数。此外，这些参数更新后的值域限制不仅支持更大的数据包有效载荷，同时还能对数据包的最大传输时长进行限制。 控制器可将大型有效载荷分割为多个数据块，或在必要时调整所选数据速率，以确保数据包传输时间在限定范围内。这保证了蓝牙低功耗（Bluetooth LE）连接事件以及多条链路和/或等时流的并行运行所需的时序和调度要求均能得到满足。
通过“数据长度更新”程序，设备可以通报用于 LL 数据 PDU 的最大发送/接收长度及定时参数。使用版本升级后的 LL_LENGTH_REQ [v2] 和 LL_LENGTH_RSP [v2] 控制 PDU 执行该程序时，可以指定这些参数所适用的 PHY。
HDT 链路质量
HDT 为蓝牙低功耗（Bluetooth LE）提供了可选的链路质量反馈（LQF）功能，允许通过专用的链路层 流程交换有关信道状况的实时信息。启用该功能后，链路质量指标将被包含在传输的数据包中，并在控制器之间持续传输。这些信息可用于根据不断变化的无线电状况动态调整链路运行策略，例如调整传输参数、选择不同的 HDT 数据速率，或在条件允许时切换回 GFSK 物理层。
设备可以使用新的 HDT 链路质量启用程序，并配合新的 LL_HDT_LQF_REPORTING_IND 控制 PDU，来指示何时应开始或停止在数据包中包含链路质量信息。
HDT 和等时信道
HDT 扩展了蓝牙低功耗（Bluetooth LE）的等时传输能力，支持通过新的 HDT PHY 传输连接式或广播式等时数据流。
设备可以协商HDT特有的运行参数（例如，HDT物理层、数据速率、有效载荷窗口大小、 等）进行协商，并利用升级版的 LL_CIS_REQ [v2] 和 LL_CIS_IND [v2] 控制 PDU，通过“连接等时流创建”流程，建立能够基于 HDT 物理层可靠传输大容量有效载荷及数据包的、具有时间限制的等时流。 值得注意的是，高吞吐量、连接式等时通信对于实现基于蓝牙低功耗（Bluetooth LE）的高质量音频解决方案和应用至关重要。
在广播方面，链路层空中接口协议的“等时广播”状态已进行更新，包括为HDT数据长度管理提供更宽泛的BIG值参数 范围、修订后的BIGInfo报头字段，以及对基于块的确认的支持。这使得同步接收机能够利用HDT来传输高吞吐量的广播流，同时遵循针对周期性广告和等时广播所定义的现有时序和同步要求。
HDT 安全与加密
HDT 增强了蓝牙低功耗（Bluetooth LE）的安全性，引入了对更大消息完整性检查（MIC）长度的支持，以及用于生成和刷新加密密钥的新功能——加密密钥调度（EKS）。蓝牙低功耗安全协议（链路层 ）负责协调设备之间的参数交换，并在保持通信加密的同时管理向 HDT 运行模式的过渡。
借助新的“基于密钥调度开始加密”流程，设备可以通过 LL_ENC_ECDH_REQ 和 LL_ENC_ECDH_RSP 控制 PDU 交换加密相关参数，并为连接选择 HDT 支持的新 MIC 长度之一（128b 或 64b）。 一旦设备计算出用于链路加密的长期密钥和会话密钥，便会通过 LL_START_ENC_REQ 和 LL_START_ENC_RSP PDU 启动加密。请注意，EKS 也可与 GFSK 物理层配合使用，在此情况下，唯一适用的 MIC 大小为 32b。
此外，对于支持 EKS 功能的设备，PHY 更新和加密密钥刷新流程允许通过版本升级后的 LL_PHY_REQ [v2]、LL_PHY_RSP [v2] 和 LL_PHY_UPDATE_IND [v2] 控制 PDU，在无需断开连接或暂停加密的情况下，同时实现 PHY 变更和加密密钥刷新。 为明确起见，MIC 大小发生变化时总会触发密钥刷新，但密钥刷新并不一定会导致 MIC 大小发生变化。
本文件的第 7 节对HDT 加密进行了更详细的说明。
HDT 可靠性与流量控制
HDT 启用了链路层 机制，用于对有效载荷进行基于块的评估，以检测和管理传输错误。蓝牙低功耗（Bluetooth LE）中现有的序列号和确认机制仍用于有效载荷的累积确认以及维护数据包顺序，但 HDT 通过块的选择性确认对这些机制进行了补充。 低层（LL）利用 HDT 数据包中的 SN、NESN、RxPayloadMap、RxBitmap、Nb 和 BlockSize 字段来检查某个数据块是否已收到确认，并据此确定是否需要重传。通过仅重传大型有效载荷中受影响的部分，从而最大限度地减少了重传开销。
HDT 还通过一种即时流量释放机制增强了链路层 的流量控制，该机制允许接收设备在需要额外缓冲或处理时间时，暂时暂停新有效载荷的传输。接收方可利用扩展数据包头中携带的信息，向对等设备发出信号，要求其停止传输新数据，同时允许重传活动继续进行。一旦接收方准备好接收更多流量，即可恢复正常的数据传输，而无需重新配置连接或进行其他高层干预。
6.2 HDT的链路层 功能
蓝牙低功耗（Bluetooth LE）链路层 采用《蓝牙核心规范》[第6卷] B部分第4.6节中定义的FeatureSet 位掩码，用于标识控制器支持的功能。对于HDT，FeatureSet 引入了一个位，用于标识对基本HDT功能的支持，同时还引入了其他位，用于标识对可选HDT功能的支持，包括更高的HDT速率、数据包格式1、链路质量反馈以及通过HDT物理层（PHY）进行的等时操作。
以下列出了为表示对 HDT 功能的支持而引入的与 HDT 相关的FeatureSet 位：
- 77 – 高数据吞吐量
- 78 – 享受 HDT6 费率
- 79 – 发送 HDT6 速率
- 80 – 享受HDT7.5费率
- 81 – 发送 HDT7.5 速率
- 82 – HDT 数据包格式 1
- 83 – 链接质量反馈
- 84 – LE HDT PHY 上的等时广播器
- 85 – LE HDT 物理层上的同步接收器
对于每个FeatureSet 位，该规范定义了控制器必须满足的要求，以表明其支持相应的功能，包括（如适用）相关的物理层（PHY）功能、数据包格式、流程和控制PDU。
接下来将描述与“高数据吞吐量”（High Data Throughput）FeatureSet 位相关的强制性要求。对于所有其余用于标识对可选HDT功能支持的FeatureSet 位，其完整定义及相关支持要求请参见《蓝牙核心规范》[第6卷] B部分第4.6节。
高吞吐量数据传输
支持高数据吞吐量（HDT）功能的控制器还必须支持带分流器的LE加密、LE数据包长度扩展、加密密钥调度以及信道选择算法#2等功能，同时还需支持以下HDT功能：
- LE HDT PHY（参见[第6卷]A部分第3.6节和第4.1.2节）
- HDT符号流处理（[第6卷] A部分，第7节），不包括：
- PHY 间隔（[第 6 卷] A 部分，第 7.2 节）
- 16QAM 符号映射（[第 6 卷] A 部分，第 7.3.3 节）
- PITS（[第 6 卷] A 部分，第 7.4.5 节）
- 发射机 RMS 和 EVM 电平（[第 6 卷] A 部分，附录 C）
- LE HDT PHY 的数据包格式（[第 6 卷] B 部分，第 2.7 节），不包括：
- 数据包格式 1
- 有效载荷块结构（[第6卷] B部分，第2.7.4节）
- 链路质量（[第6卷] B部分，第2.7.2.4.1节）
- 32b CRC 生成（[第 6 卷] B 部分，第 3.1.2 节）
- LE HDT 的比特流处理（[第 6 卷] B 部分，第 3.4 节），不包括：
- 区间间距（[第6卷] B部分，第3.4.2节）
- HDT配置交换程序（[第6卷] B部分，第5.1.34节），不包括：
- 涉及等时广播器、同步接收器以及LE HDT PHY上的广播等时流、组和PDU的应用
- LL_LENGTH_REQ [v2] 和 LL_LENGTH_RSP [v2] PDU
- LL_HDT_CONFIG_REQ 和 LL_HDT_CONFIG_RSP PDU
此外，支持“高数据吞吐量”功能和“连接等时流（中央或外围）”功能的控制器还必须支持：
- LL_CIS_REQ [v2] 和 LL_CIS_IND [v2]
更多详情请参见（[第6卷] B部分，第4.6.54节）。
6.3 HDT的链路层 流程
6.3.1 新程序
为支持HDT功能，在链路层 控制协议中针对ACL链路引入了以下流程：
- HDT 配置交换流程
- HDT链路质量启用流程
下文概述了这些功能及其启动和完成过程中涉及的PDU。请注意，只有在ACL链路进入“连接”状态后，才能执行这些操作。
HDT 配置交换流程
更改与 LE HDT PHY 上某连接相关的配置值。交换的值不会影响 LE HDT PHY 上现有的任何 ACL 或 CIS。 这些值对随后创建的 CIS 以及在从 GFSK PHY 切换至 LE HDT PHY 时对 ACL 均生效。该流程通过发送 LL_HDT_CONFIG_REQ PDU 启动，并在接收到 LL_HDT_CONFIG_RSP PDU 时完成。每个发送的 PDU 仅与发送设备的配置相关，因此双方启动的流程之间发生冲突也不会造成影响。
HDT链路质量启用流程
要求远程控制器在指定传输层上发送的每个数据包中开始或停止发送链路质量反馈。该过程通过发送 LL_HDT_LQF_REPORTING_IND PDU 启动，并在收到 LL_HDT_LQF_REPORTING_IND PDU 的确认后完成。通过相同的流程可禁用链路质量反馈。
6.3.2 更新后的程序
为了支持 HDT 功能，已对以下 ACL 控制流程进行了修改：
- 加密程序
- 加密：从“Diversifiers”过程开始（第一部分）
- 加密：从密钥调度过程开始（第一部分）
- 以分流器开始的加密与以密钥调度开始的加密（第2部分）
- 加密暂停程序
- 数据长度更新过程
- PHY 更新和加密刷新流程
- 连接式等时流创建流程
- 帧空间更新过程
下文总结了每个更新后流程的功能，以及启动和完成这些流程所需的PDU。再次提醒，这些流程只能在ACL链路进入连接状态后才能执行。
加密程序
启用数据PDU的加密和认证，以保护有效载荷的机密性和完整性。 如果中央设备（Central）和外围设备（Peripheral）均支持加密密钥调度（EKS）功能，则中央设备将发起“使用密钥调度开始加密”流程；否则，将发起“使用分组器开始加密”流程。连接加密后，如果中央设备和外围设备均支持 EKS，则外围设备（链路层 ）可通过“PHY 更新和加密刷新”流程更改加密密钥；否则，可通过“加密暂停”流程进行更改。
“以分流器开始加密”和“以密钥调度表开始加密”这两种加密过程都包含两个部分。两者的第一部分各不相同，而第二部分则完全相同。
加密：从“Diversifiers”过程开始（第1部分）
要启用加密，中央设备和外设分别生成各自部分的初始化向量（IV）和会话密钥分组器（SKD），并通过 LL_ENC_REQ 和 LL_ENC_RSP PDU 进行交换。随后，每个 LL 将 IV 和 SKD 的各部分进行组合。外设主机将其要使用的长期密钥（LTK）通知给其 LL。 通过使用 LL_START_ENC_REQ 和 LL_START_ENC_RSP PDU 进行三向握手，启动加密。
加密：从密钥调度过程开始（第一部分）
要启用加密，主设备与外围设备会各自生成公钥（PubKey）和随机数（Rand）的对应部分，并通过 LL_ENC_ECDH_REQ 和 LL_ENC_ECDH_RSP PDU 进行交换。 如果在 GFSK 物理层上，连接将使用 32 位 MIC；如果在 HDT 物理层上，连接将使用 128 位 MIC，除非通过标志位设置为 64 位 MIC。
以分流器开始的加密与以密钥调度开始的加密流程（第2部分）
确定用于加密的长期密钥（LTK）的类型（例如，若采用机会加密，则为全零）及其来源（例如，由主机提供给LL）。 在中央节点的情况下，主机始终向链路层 提供LTK。在外围节点的情况下，主机可能提供也可能不提供；如果提供，LL将使用该LTK计算会话密钥。 会话密钥的计算基于[第3卷]H部分第2.2.1节（关于使用分流器的加密开始）以及[第6卷]E部分第4.2.1节（关于使用密钥调度表的加密开始）。
加密暂停程序
封装了两个“加密开始”过程。因此，相同的更新同样适用。
数据长度更新过程
用于向对等设备传输当前 LL 数据 PDU 的最大接收（Max Rx）和最大发送（Tx）有效载荷长度及时间的最新值（connMaxRxOctets、connMaxRxTime、connMaxTxOctets 和 connMaxTxTime）。 规范中的措辞更新明确指出：如果控制器支持该连接的多个参数集，则该过程可选择要更新的参数集。该过程由主设备或外围设备发送 LL_LENGTH_REQ PDU 来启动。该请求将通过 LL_LENGTH_RSP PDU 进行响应。响应将更新请求 PDU 中指定的参数集。
PHY 更新和加密刷新流程
用于更改ACL连接的发送（Tx）或接收（Rx）物理层（PHY）（或两者），或者在设备支持EKS功能时刷新加密密钥和初始向量（IV），或同时执行这两项操作。 此操作不会影响与CIS相关的PHY或密钥/初始向量（IV）。请求通过LL_PHY_REQ PDU发起，并以LL_PHY_RSP PDU作为响应。中央节点（Central）始终会在最后一步发送LL_PHY_UPDATE_IND PDU。
HDT 引入了规则条款，明确了在请求或响应 PHY 更新之前如何处理传输中或排队中的数据、如何管理加密密钥刷新、无效行为等。 此外，HDT 引入了 PDU 的 [v2] 版本，其中包含一个“刷新”字段，用于（在 LL_PHY_REQ/RSP 情况下）要求或（在 LL_PHY_UPDATE_IND 情况下）指示加密密钥刷新请求，以及一个 MIC_Length 字段，用于指示 HDT PHY 上首选的 MIC 长度。 请注意，只有当双方均要求时，才会选择 64b 的 MIC 长度；单个设备不能降低其对等方所要求的安全级别。
连接式等时流创建流程
用于在中央设备与外围设备之间建立CIS。该请求仅由中央设备使用LL_CIS_REQ PDU发起。若请求被接受，外围设备将使用LL_CIS_RSP PDU进行响应；若被拒绝，则使用LL_REJECT_EXT_IND PDU并附上相应的理由代码进行响应。 收到响应后，中央设备通过发送 LL_CIS_IND PDU 来建立 CIS，或通过发送 LL_REJECT_EXT_IND PDU 来取消 CIS。HDT 引入了相关规则，明确了在 GFSK 或 HDT 物理层上建立 CIS 的要求，以及 PDU 版本、对称物理层和 EKS 功能的使用要求。
6.4 适用于 HDT 的链路层 控制型 PDU
6.4.1 新的控制PDU
以下是新引入的控制PDU（用于数据物理信道），用于传输与新定义的空中HDT支持程序相关的请求、响应或指示：
- (0x40) LL_ENC_ECDH_REQ
- (0x41) LL_ENC_ECDH_RSP
- (0x42) LL_HDT_CONFIG_REQ
- (0x43) LL_HDT_CONFIG_RSP
- (0x44) LL_HDT_LQF_REPORTING_IND.
下面提供了其 CtrData 字段的格式，以及该字段下每个字段的一行描述。
LL_ENC_ECDH_REQ
- Flags_C：Central 的加密标志 [bit0：0=128 位 MIC，1=64 位 MIC；bit1：机会性加密]
- Rand_C：由中央提供的随机数
- KeyType_C：中央机构使用的公钥类型 [0=使用 P-256 椭圆曲线派生]
- PubKey_C：Central 的 ECDH 公钥 [Pubkey_C31-0 = X 坐标，Pubkey_C63-32 = Y 坐标]
LL_ENC_ECDH_RSP
- Flags_P：外设的加密标志 [bit0：0=128位MIC，1=64位MIC]
- Rand_P：由外设提供的随机数
- KeyType_P：外设使用的公钥类型 [0=使用 P-256 椭圆曲线派生]
- PubKey_P：外设的 ECDH 公钥 [Pubkey_C31-0 = X 坐标，Pubkey_C63-32 = Y 坐标]
LL_HDT_CONFIG_REQ 和 LL_HDT_CONFIG_RSP
- ACL_RX_Payload_Window_Size：在ACL连接的接收方向上，该值应设置为比PayloadWindowSize小1；默认值 = 0
- Max_CIS_TX_Payload_Window_Size：设置为关联 CIS 在 TX 方向上使用的最大有效载荷窗口大小的减一；默认值 = 0
- Max_CIS_RX_Payload_Window_Size：设置为关联的 CIS 在接收方向上使用的最大有效载荷窗口大小的减一；默认值 = 0
- ACL_RX_Rates：控制器在ACL连接上允许从远程控制器接收的速率 [bit0: HDT2；bit1: HDT3；bit2: HDT4；bit3: HDT6；bit4: HDT7.5]
- Max_ACL_RX_Octets_Per_Packet：ACL 连接中单个数据包可接收的最大数据字节数。不包括 MIC、终止序列、PITS 等。
LL_HDT_LQF_REPORTING_IND（简体中文（大陆））
- 传输：指示对于 [bit0：ACL；bit1：CIS]，LQF 报告功能是否已启用或禁用
6.4.2 已更新的控制 PDU
以下是经过更新的控制PDU（用于数据物理信道），其中对字段进行了修改或添加，以传递与更新后的链路层 程序相关的请求、响应或指示，该程序用于通过无线方式支持HDT：
- (0x14) LL_LENGTH_REQ
- (0x15) LL_LENGTH_RSP
- (0x16) LL_PHY_REQ
- (0x17) LL_PHY_RSP
- (0x18) LL_PHY_UPDATE_IND
- (0x1F) LL_CIS_REQ
- (0x21) LL_CIS_IND
- (0x23) LL_POWER_CONTROL_REQ。
下文提供了其 CtrData 字段的格式，以及该字段下每个字段（无论是修改后的还是新增的）的一行描述。注意：由于为支持 HDT 而进行的修改，这些 LL 控制 PDU 现在可能具有多种格式，分别用 [v1] 或 [v2] 表示。CtrData 字段内的每个字段在其所包含的所有格式中均具有相同的含义。
LL_LENGTH_REQ 和 LL_LENGTH_RSP
- PHY_S：指示该 PDU 适用的 PHY 参数集 [0=GFSK；1=HDT]；在 LL_LENGTH_RSP 中，该字段被忽略
LL_PHY_REQ 和 LL_PHY_RSP
- TX_PHYS：发送方倾向于使用以下传输层物理层（PHY）配置：[bit0: LE_1M；bit1: LE_2M；bit2: LE Coded；bit4: HDT]
- RX_PHYS：发送方倾向于使用的接收端物理层 [bit0: LE_1M；bit1: LE_2M；bit2: LE Coded；bit4: HDT]
- 刷新：刷新密钥 [1=必填]；若未包含，则值设为 0；若连接未加密，或任一设备不支持 EKS 功能，则该值将被忽略
- MIC_Length：[1=请求为HDT生成64位MIC，0或未指定=为HDT生成128位MIC]；若连接未加密、密钥未刷新或切换至GFSK物理层，则忽略此参数
LL_PHY_UPDATE_IND
- PHY_C_TO_P：中央发送的数据包的物理层 [bit0: LE_1M；bit1: LE_2M；bit2: LE Coded；bit4: HDT]
- PHY_P_TO_C：用于外设发送的数据包的物理层 [bit0: LE_1M；bit1: LE_2M；bit2: LE Coded；bit4: HDT]
- 即时：未来某个特定的连接事件，由连接事件计数器的值所引用
- 地址：ACL 连接建立后将使用的 PHY 的物理信道地址
- 刷新：1=将刷新加密密钥；0 或未指定=不会刷新加密密钥，或者连接未加密
- MIC_Length：[1=刷新及HDT的64位MIC，0或未包含=HDT的128位MIC]；若连接未加密、密钥未刷新或切换至GFSK物理层，则忽略此参数
LL_CIS_REQ
- Max_Payload_C_To_P：中央单元可在CIS PDU中传输的最大链路层 有效载荷大小（以字节为单位）
- Max_Payload_P_To_C：外设在 CIS PDU 中可传输的最大链路层 有效载荷大小（以字节为单位）
- Rates_C_To_P：从中央允许的速率 [bit0: HDT2；bit1: HDT3；bit2: HDT4；bit3: HDT6；bit4: HDT7.5]
- Rates_P_To_C：外围设备允许的速率 [bit0: HDT2；bit1: HDT3；bit2: HDT4；bit3: HDT6；bit4: HDT7.5]
- Payload_Window_Size_C_To_P：中央节点可在该窗口内跟踪、传输和重传的有效载荷数量（范围为 1 到 4）
- Payload_Window_Size_P_To_C：外设可在该窗口内跟踪、传输和重传的有效载荷数量（范围为 1 到 4）
- MIC_Length：如果 CIS 位于 HDT PHY 上且经过加密，则 1 表示 64 位 MIC，0 表示 128 位 MIC；否则忽略该参数
- SE_Length：需要为子事件预留的时间（单位：微秒）
LL_CIS_IND
- 如果 CIS 位于 GFSK 物理层：AA=CIS 的访问地址，或者如果 PDU 中包含 PCA-H，则为 0
- 如果 HDT PHY 的 CIS 为 AA=HPA31-0，则必须存在 PCA-H 且将其设置为 HPA39-32
LL_POWER_CONTROL_REQ
- PHY：正在请求的 PHY [位 0：1M；位 1：2M；位 2：编码 S=8；位 3：编码 S=2；位 4：HDT]
7. 蓝牙® HDT 加密
HDT 增强了蓝牙低功耗（Bluetooth LE）的加密和身份验证框架，以实现更强的数据保护，保持与现有安全模型的兼容性，并使蓝牙技术能够跟上行业和监管方面的安全发展趋势。
本节概述了由蓝牙® HDT 推动的加密相关增强功能，并总结了为实现这些功能而引入的新功能、新流程和新参数。
7.1 HDT 加密增强功能概述
HDT 通过支持更大的消息完整性检查（MIC）长度以及蓝牙核心 7.0 中引入的新加密密钥调度（EKS）功能，增强了蓝牙低功耗（Bluetooth LE）的加密能力。不过，整体的加密和认证过程仍依赖于现有的加密算法，其中 ECDH 用于建立共享密钥，AES-CMAC 用于密钥派生，AES-CCM 用于数据加密和完整性保护。
支持更大的MIC尺寸
在基于GFSK的蓝牙物理层中，附加在加密数据包后的MIC长度固定为32位（4个八位字节）。采用HDT后，较长的数据包有效载荷需要更长的MIC，以降低数据损坏或篡改未被检测到的概率。因此，HDT引入了对以下MIC长度的支持：
- 64b（8个字节）
- 128b（16字节）
MIC 大小是在由链路层 管理的加密建立阶段确定的。如果任一方倾向于使用 128b，则选择 128b。新的 MIC 大小仅适用于通过 HDT PHY 传输的数据包（基于 GFSK 的 PHY 仍继续使用 32b MIC）。根据 NIST 的建议，所选的 MIC 大小在连接两端对称地强制执行，并与当前使用的会话密钥绑定。
对于采用数据包格式 1（PF1）的 HDT 数据包，加密后的有效载荷和 MIC 会在传输前（加密后）被分割成多个数据块。因此，每个数据块可在接收时立即解密，但 MIC 验证只能在所有数据块均成功接收并重组后进行。
支持加密密钥调度（EKS）
要使用 HDT 进行操作，设备必须通过 GFSK 物理层建立连接，发现所支持的 HDT 功能，选择/交换配置参数，然后通过物理层更新和加密刷新程序切换到 HDT 物理层。从加密的角度来看，这涉及将 MIC 大小从 32b 更改为 64b 或 128b，进而需要更改加密密钥。
加密密钥调度（EKS）功能支持生成、管理和刷新加密密钥，以便在无需断开连接或重启加密流程的情况下，适应 PHY（及 MIC 大小）的变化。通过使用基于 ECDH 导出的共享密钥和基于 AES-CMAC 的密钥导出函数，EKS 能够支持：
- 机会主义加密
- 完美前向保密（PFS）
- 通过同步密钥和MIC更新实现无缝的PHY切换
- ACL 和 CIS 传输的按流键分离
借助“机会加密”（Opportunistic Encryption），设备无需预先共享“生命周期密钥”（LTK）即可建立加密连接，即使设备尚未配对，也能进行加密通信。这提供的机密性和完整性与设备使用“低功耗安全连接”（LE Secure Connections）并采用“即用即通”（Just Works）方法进行配对时相当，但不包含身份验证或“中间人”（MITM）攻击防护。
在 PFS 机制下，即使设备的 LTK、私钥或当前会话密钥遭到泄露，也不会导致先前会话密钥暴露。因此，之前的加密会话仍保持安全。加密刷新后会话密钥的泄露，不会泄露加密刷新前先前会话密钥的任何信息。仅凭一个会话密钥，无法推导出任何其他会话密钥或流量密钥。已知某个流量密钥时，可以推导出后续的流量密钥，但无法推导出之前的流量密钥。
此前虽然可以实现按流分离密钥，但需要完全重复“使用分流器进行加密”的过程。EKS PFS 显著简化了这一过程。目前，由于 CIS 会话密钥无法刷新，因此 CIS 会话的存活时间是有限的。
对于支持 HDT 的设备，必须支持 EKS。当连接中的两台设备均支持 EKS 时，必须使用 EKS。如果不支持 EKS，则“使用分流器加密”仍保持有效。
新函数、新过程和新参数
作为 EKS 功能的一部分，引入了新的加密函数、新的加密标签值以及新的会话密钥派生过程。此外，还在 AES-CCM 算法所使用的计数器模式块中添加了新的字段和值，以支持按新大小计算 MIC。
7.2 密钥派生更新
密码学工具箱
EKS 的密钥派生层次结构包括
- 派生密钥：从设备间 ECDH 共享密钥派生出的基础密钥，作为 EKS 密钥层次结构的一部分
- 一个流量密钥：从派生密钥中获取的密钥，用于生成会话密钥和初始向量（IV）
- 会话密钥和初始化向量（IV）：由AES-CCM算法用于生成消息完整性检查码（MIC），以及用于数据包的加密和认证
为支持 EKS 而引入的新加密函数基于 AES-CMAC 函数（参见《蓝牙核心规范》[第 3 卷] H 部分第 2.2.5 节）。这些函数结合 LTK 和 ECDH 共享密钥，支持完整的密钥派生层次结构。图 7.1 展示了通过新函数实现的基于 CMAC 的密钥派生层次结构。
图 7.1 – 基于 CMAC 的 EKS 密钥派生层次结构
表7. 1和表7.2总结了新的加密函数和标签。带标签的输入可确保密钥之间的加密隔离。
表 7.1 – 加密工具箱函数
| 功能 | 费用项目 |
|---|---|
| k1 | 利用 AES-CMAC，从现有密钥和特定于上下文的信息中派生出一个新的 128 位密钥。用作其他派生操作的基础组件。 |
| k2 | 根据 ECDH 共享密钥推导出初始的“派生密钥”。这是连接的密钥层次结构的根节点。 |
| k3 | 刷新一个流量密钥，以支持在无需重新配对的情况下更新会话密钥 |
| kv1 | 从流量密钥中派生出 128 位会话密钥。用于 AES-CCM 加密 |
| kv2 | 根据通信密钥推导出 64 位初始化向量 (IV)。用于 AES-CCM 中的随机数生成 |
| kv12 | 这不是一个函数，而是一种表示法，用于说明 kv1 和 kv2 总是共同用于从流量密钥中推导出会话密钥和初始向量（IV）。 |
| ee1 | 根据基础密钥（例如 LTK 或 ECDH 输出）和上下文标记，或根据先前派生的密钥，派生出派生密钥 |
| ee2 | 根据基础密钥和上下文推导出流量密钥 |
| ee12 | 这不是一个函数，而是一种表示法，用于表明 ee1 和 ee2 总是共同用于推导“派生密钥”和“通信密钥” |
表 7.2 – 加密标签值
| 标识符 | 值 | 推导 | 使用 |
|---|---|---|---|
| taghs | 0x6465_72697665_64206873 | “衍生hs” | k2 |
| tagda | 0x646572_69766564_2041434C | “派生ACL” | 最初的衍生秘密 |
| tagdc | 0x646572_69766564_20434953 | “衍生CIS” | 后续衍生的秘密 |
| tagta | 0x747261_66666963_2041434C | “流量访问控制列表（ACL）” | ACL 流量秘密 |
| tagtc | 0x747261_66666963_20434953 | “交通CIS” | 独联体交通秘闻 |
| tagtr | 0x747261_66666963_20757064 | “交通更新” | k3 |
| tagsk | 0x6B6579 | “key” | kv1 |
| tagiv | 0x6976 | “iv” | kv2 |
密码学算法
启动 ACL 加密
在使用 EKS 对 ACL 连接启动加密时，设备必须首先交换公钥，并使用“基于密钥调度开始加密”流程生成 ECDH 共享密钥。然后，设备必须验证收到的公钥，并使用ee12函数计算该 ACL 的派生密钥和流量密钥的初始值。最后，设备必须使用kv12函数计算初始会话密钥和初始向量。
如果设备未配对，则使用值为零的 LTK，从而启用机会加密。机会加密允许设备在保持加密状态的同时，从 GFSK 物理层切换到 HDT 物理层，即使没有 LTK 可用也是如此。
独联体交通内幕
每次创建新的连接等时流（CIS）时，设备都会使用ee12函数并结合 CIS 专属标识符（CIG_ID、CIS_ID），生成一个新的派生密钥值以及该 CIS 的初始流量密钥。这实现了按流分离密钥，从而增强了多流场景下的安全性。随后，设备必须使用kv12函数为该 CIS 计算初始会话密钥和初始向量（IV）。
目前，每个 CIS 在其整个生命周期内（2^39 个数据包）仅有一个流量密钥，因为其会话密钥无法刷新。
ACL 会话密钥刷新
HDT 支持在连接期间刷新会话密钥，且无需主机干预。设备通过k3函数更新流量密钥，随后通过kv12函数推导出新的会话密钥和初始向量（IV）。刷新过程会保留数据包计数器和有效载荷编号，从而确保数据包排序得以延续，不会中断数据传输。这意味着会话密钥必须在自上次刷新以来接收的 2^39 个数据包内完成刷新。
与PHY过渡的集成
在蓝牙低功耗（Bluetooth LE）中，加密会话期间切换物理层（PHY）通常需要暂停并重新启动加密。HDT 通过将 EKS 与 PHY 切换集成在一起，消除了这一要求：
- 从配备 32b MIC 的 GFSK 物理层切换到配备 64b 或 128b MIC 的 HDT 物理层，或反之，链路层 将使用 EKS 执行协调式密钥刷新
- GFSK 物理层的关键更新也可以与切换到另一个 GFSK 物理层同步进行
- 当物理层（PHY）切换需要更改MIC大小时，新的会话密钥和MIC大小将与物理层切换同时生效
- 在两个 GFSK 物理层之间切换时不会发生密钥/MIC 变更，且在保持 HDT 物理层运行期间也不一定需要进行此类变更。
- 这种协调机制可在不暴露未受保护的数据且无需主机重新认证的情况下，保持持续加密状态
该集成简化了物理层（PHY）切换，并通过确保MIC大小的变更始终伴随着密钥变更（符合NIST的要求），从而增强了安全性。
需要注意的一点是：如果在 HDT PHY 上发送 LL_PHY_REQ/RSP 和 LL_PHY_UPDATE_IND，则在该过程的一部分时间内，必须暂停 ACL 用户数据（但不包括控制平面数据）。
7.3 加密更新
CCM算法
在加密和认证过程中，CCM 算法要求将有效载荷和附加参数格式化为 CCM 随机数、计数器模式数据块和加密数据块。CCM 随机数确保每个数据包的唯一性，计数器模式数据块用于计算 MIC，而加密数据块则提供用于加密有效载荷和 MIC 的密钥流。
对 EKS 和可变 MIC 长度的支持，对计数器模式数据块的格式和字段进行了更新，这些更新旨在解决基于 GFSK PHY 和 HDT PHY 的操作之间的差异，并考虑由链路层 程序确定的 MIC 大小（32b、64b 或 128b）。
8. 蓝牙® HDT 主机控制器接口 (HCI)
蓝牙® HDT 引入了新的命令和事件，并对现有命令和事件进行了更新，以扩展主机控制器接口（HCI）的功能，并支持更高的吞吐量、更优的性能和可靠性，以及更强的安全性。
本节概述了用于启用 HDT 功能的新增、版本升级和更新的 HCI 命令及事件。此外，本节还包含消息序列图，用于说明关键 HCI 命令和事件在支持 HDT 时与蓝牙低功耗链路层 之间的典型交互。
8.1 新增或更新的 HCI 命令和事件概述
表8.1、8.2 和8.3分别概述了用于支持 HDT 的新增、版本升级和更新的 HCI 命令及事件。 为清晰起见，版本升级的命令和事件为 HDT 支持引入了新的命令或返回参数，而更新的命令和事件仅在已有的命令或返回参数中添加了用于启用和支持 HDT 的新值。有关更多详细信息（包括每个命令或事件的支持要求），请参阅《蓝牙核心规范》[第 4 卷] E 部分第 3 节。
表 8.1 – 用于支持 HDT 的新 HCI 命令和事件
| 命令 / 事件 | 费用项目 |
|---|---|
| LE 读取加密密钥表调试模式命令 | 用于在使用基于 EKS 的加密时读取调试模式 |
| LE Set HDT 默认参数命令 | 由主机用于设置本地控制器的默认 HDT 参数 |
| LE 设置 HDT 参数测试命令 | 由主机用于设置该连接的 HDT 测试参数 |
| LE 测试报告：HDT 链路质量事件 | 报告接收到的 HDT PHY 测试数据包的链路质量信息 |
| LE 写入加密密钥调度表调试模式命令 | 由主机在基于 EKS 的加密过程中用于设置调试模式 |
表 8.2 – 为支持 HDT 而升级的 HCI 命令和事件
| 命令 / 事件 | 费用项目 |
|---|---|
| 加密变更事件 [v3] | 表示已为指定的 Connection_Handle 完成了加密方式的更改 |
| “加密密钥刷新完成”事件 [v2] | 当加密被暂停后又恢复时，该字段会向主机指示在给定的 Connection_Handle 上已刷新加密密钥 |
| LE CIS 已建立的活动 [v3] | 表示控制器已建立 CIS |
| LE Create BIG 命令 [v2] | 创建一个或多个属于 BIG 的 BIS |
| LE Create BIG 完整活动 [v2] | 表示控制器已完成创建主机请求的 BIS 的尝试 |
| LE Create BIG 测试命令 [v2] | 用于为测试目的创建一个或多个BIG的BIS |
| LE 数据长度变更事件 [v2] | 用于指示由链路层 |
| LE 启用加密命令 [v2] | 用于启用链路层加密 |
| LE 读取最大数据长度命令 [v2] | 允许主机读取控制器支持的 MaxTxOctets、MaxTxTime、MaxRxOctets 和 MaxRxTime 参数 |
| LE 读取建议的默认数据长度命令 [v2] | 允许主机读取 HDT PHY 或建议给控制器的 GFSK PHY 上新连接的初始 MaxTxOctets 和 MaxTxTime 值 |
| LE 接收器测试命令 [v4] | 运行 LE 接收器测试 |
| LE 设置 CIG 参数命令 [v2] | 由中央主机用于为控制器中与某个CIG关联的一个或多个CIS设置参数 |
| LE 设置 CIG 参数测试命令 [v2] | 仅用于测试目的。由中央主机用于在控制器中为与某个CIG关联的一个或多个CIS设置参数。 |
| LE 设置数据长度命令 [v2] | 用于向控制器建议最大数据包大小 |
| LE 测试结束命令 [v2] | 结束当前的接收器或发射器测试 |
| LE 发射器测试命令 [v5] | 运行 LE 发射器测试 |
| LE 写入建议默认数据长度命令 [v2] | 允许主机为 HDT 物理层或 GFSK 物理层上的新连接建议初始的 MaxTxOctets 和 MaxTxTime 值 |
| 刷新加密密钥命令 [v2] | 由主机调用，通过暂停并恢复加密操作，促使控制器刷新加密密钥 |
表 8.3 – 支持 HDT 的更新版 HCI 命令和事件
| 命令 / 事件 | 费用项目 |
|---|---|
| LE BIG Sync 已确立的活动 | 表示控制器已完成与所请求的BIS的同步尝试 |
| LE BIGInfo 广告报告活动 | 表示控制器已收到一个包含 BIGInfo 字段的广告 PDU |
| LE CS “设置过程参数”命令 | 由主机用于设置参数，以便由本地控制器对一个或多个 CS 程序进行调度 |
| LE 增强型读取发射功率电平命令 | 用于读取ACL连接上本地控制器的当前和最大发射功率级别 |
| LE 帧空间更新完成事件 | 用于通知主机帧空间值的变更 |
| “LE PHY 更新完成”活动 | 用于向主机报告每个方向的当前物理层（PHY） |
| LE 读取 PHY 命令 | 用于读取每个方向上的当前 PHY 值 |
| LE 读取远程发射功率级命令 | 用于读取远程控制器在ACL连接中使用的发射功率电平 |
| LE 设置默认 PHY 命令 | 用于为本地设备的新连接配置首选的物理层（PHY） |
| LE 设置事件掩码命令 | 用于控制 HCI 为主机生成哪些事件 |
| LE 设置 PHY 命令 | 用于请求更改 Connection_Handle 的 PHY |
| LE 发射功率报告事件 | 用于报告ACL连接上的发射功率电平 |
| “设置事件掩码”第 2 页命令 | 用于控制 HCI 为主机生成哪些事件 |
8.2 新的 HCI 命令和事件
LE 读取加密密钥表调试模式命令
在使用基于加密密钥计划的加密时，该命令将恢复调试模式。该命令对后续的所有连接生效，且不会影响任何现有连接。
LE Set HDT 默认参数命令
允许中央主机或外围主机为其HDT PHY指定默认参数，该参数将应用于所有后续连接。此设置不会影响现有连接。
- Preferred_MIC_Length – 指示在 LE HDT PHY 上所有加密连接中应使用的首选 MIC 长度
- Preferred_Packet_Format – 指示在 LE HDT PHY 上用于数据传输的首选 HDT 数据包格式
- Preferred_ACL_Rates – 指示在 LE HDT PHY 上通过 ACL 连接应使用的优先速率
LE 设置 HDT 参数测试命令
仅用于测试目的。当使用 HDT PHY 时，中央主机或外围主机可借此为 Connection_Handle 指定的 ACL 或 CIS 连接设置测试参数。主机可通过 HCI_LE_Read_Maximum_Data_Length 读取本地控制器支持的 HDT 有效载荷和数据包功能。
- MIC_Length – 指示用于对由该句柄指定的 ACL 连接进行加密时所使用的 MIC 长度
- Packet_Format – 指定所有带有 PDU 报头区的传输数据包应采用的格式
- Blocks_Per_Payload – 指示在使用 PF1 时，该连接上每个有效载荷应包含的区块数
- TX_Rate – 指示在ACL连接上传输时应使用的HDT速率（对于CIS将被忽略）
LE 测试报告：HDT 链路质量事件
当本地控制器收到来自LE HDT PHY测试数据包的链路质量结果并需进行报告时生成。
- 子活动代码 – 该活动的子活动代码
- Channel_Index – 接收测试数据包的射频信道
- Report_Status – 指定控制器是否还有待发送的报告
- Report_Count – 指定每帧报告的 RSSI[i] 和 SNR[i]参数 值的数量
- RSSI[i] – 按接收顺序排列的、与单个测试数据包相关的RSSI值
- SNR[i] – 按接收顺序与单个测试数据包相关的信噪比值
LE 写入加密密钥调度表调试模式命令
用于配置控制器，使其在基于加密密钥调度（EKS）的加密中使用预定义的 ECDH 密钥对，以便调试设备能够监控加密连接。该命令对所有后续连接生效，且不会影响任何现有连接。
8.3 版本升级后的 HCI 命令和事件
加密变更事件 [v3]
![HCI_Encryption_Change [v3] 事件参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_Encryption_Change_v3_white.png)
用于指示加密模式更改已完成。[v3] 引入了新的事件参数，用于指示连接的 MIC 长度（如果使用基于 EKS 的加密），以及在“使用密钥调度表 LL 开始加密”流程中是否使用了调试密钥对。
“加密密钥刷新完成”事件 [v2]
![HCI_Encryption_Key_Refresh_Complete [v2] 事件参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_Encryption_Key_Refresh_Complete_v2_white.png)
用于向主机指示在给定的 Connection_Handle 上已刷新加密密钥。[v2] 引入了事件参数 MIC_Length、Key_Schedule_Enabled 和 Key_Schedule_Debug_Flag，其用途与 Encryption Change [v3] 事件相同。如果该事件由 LE PHY 更新过程生成，则会在 HCI_LE_PHY_Update_Complete 事件之后立即发送该事件。
LE CIS 已建立的活动 [v3]
![HCI_LE_CIS_Established [v3] 事件参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_CIS_Established_v3_white.png)
通知主机 CIS 已成功建立或建立失败（例如，被拒绝或在建立前丢失）。[v3] 引入了以下事件参数，为 PHY 事件参数添加了新值以指定 HDT 的使用，并将 Max_Payload 事件参数的上限提高到 8175 字节。
- Rates_C_To_P – 表示在中心到外围方向上使用了特定的 LE 编码或 HDT 数据速率
- Rates_P_To_C – 表示在从外围设备到中央设备的方向上使用了特定的 LE 编码或 HDT 数据速率
- Config_ID – CIG 配置标识符
- TL_Group_ID – 与 Config_ID 关联的传输延迟组标识符
- Encryption_Enabled – 指示 CIS 上是否启用了加密以及加密类型（例如，EKS、机会性加密）
- MIC_Length – 指示用于加密的MIC的长度
LE Create BIG 命令 [v2]
![HCI_LE_Create_BIG [v2] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Create_BIG_v2_white.png)
用于使用一个或多个 BIS 创建一个 BIG。BIG 中的所有 BIS 在所有参数上的值均相同。[v2] 引入了以下命令参数，以及一个新的 PHY 位号参数 ，用于指示使用 HDT PHY 传输数据包。
- Coded_Rates – 指定在 LE 编码物理层上应优先使用的速率
- HDT_Rates – 指示在 HDT PHY 上应优先使用的速率
- HDT_MIC_Length – 指示用于通过 HDT 进行加密的 MIC 长度
- HDT_Packet_Format – 指示当 BIS 处于 HDT PHY 模式时，数据传输的首选 HDT 数据包格式
LE Create BIG 完整活动 [v2]
![HCI_LE_Create_BIG_Complete [v2] 事件参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Create_BIG_Complete_v2_white.png)
表示 HCI_LE_Create_BIG 或 HCI_LE_Create_BIG_Test 命令已完成；若操作成功，则表示链路层 已进入等时广播状态。[v2] 引入了以下事件参数，为 PHY 事件参数 添加了新值以指定 HDT 的使用情况，并将 Max_Payload 大小的上限提高到 8175 个字节。
- 费率——指用于“LE Coded”或“HDT PHY”的编码或费率
- Encryption_Enabled – 指示 BIG 上是否启用了加密
- MIC_Length – 指示用于加密的MIC的长度
LE Create BIG 测试命令 [v2]
![HCI_LE_Create_BIG_Test [v2] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Create_BIG_Test_v2_white.png)
仅用于测试目的。用于创建包含一个或多个 BIS 的 BIG。BIG 中的所有 BIS 在所有参数上的值均相同。[v2] 引入了以下命令参数，为 PHY参数 添加了一个新的位号，用于指示使用 HDT PHY 传输数据包，并将 Max_Payload 大小的上限提高到 8175 个字节。
- Coded_Rates – 指定在 LE Coded PHY 上应使用的优先速率
- HDT_Rates – 指示在 HDT PHY 上应优先使用的速率
- HDT_MIC_Length – 指示用于通过 HDT 进行加密的 MIC 长度
- HDT_Packet_Format – 指示当 BIS 位于 HDT PHY 上时，数据传输的首选数据包格式
- HDT_Blocks_Per_Payload – 指示在与 PF1 的连接中，每个有效载荷应使用的区块数
LE 数据长度变更事件 [v2]
![HCI_LE_Data_Length_Change [v2] 事件参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Data_Length_Change_v2_white.png)
当链路层 数据PDU的最大有效载荷长度或包含LL数据PDU的数据包在任一方向上的最大传输时间发生变化时，向主机发出通知。[v2]引入了PHYS事件参数 ，用于指示该事件参数所适用的PHY。此外，还将Max_TX_Octets和Max_RX_Octets大小的上限提高至8175字节。
LE 启用加密命令 [v2]
![HCI_LE_Enable_Encryption [v2] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Enable_Encryption_v2_white.png)
用于验证与远程设备关联的给定加密密钥，并在验证通过后对连接进行加密。[v2] 引入了 HDT_MIC_Length 和 Encryption_Type 命令参数，用于指定加密时首选的 MIC 长度，以及 HDT PHY 上 ACL 连接所采用的 EKS 或机会加密类型。
LE 读取最大数据长度命令 [v2]
![HCI_LE_Read_Maximum_Data_Length [v2] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Read_Maximum_Data_Length_v2_white.png)
允许主机读取控制器在传输和接收LL数据PDU时所支持的最大有效载荷大小和数据包持续时间。[v2]引入了PHY命令参数 ，用于指定正在读取其参数的PHY，并引入了以下用于HDT功能支持的返回参数。此外，还将Supported_Max_TX/RX_Octets值范围的上限提高至8175个字节。
- Supported_Max_TX_Payload_Window_Size – 控制器支持的最大传输有效载荷窗口大小
- Supported_Max_RX_Payload_Window_Size – 控制器支持的最大接收有效载荷窗口大小
- Supported_Max_RX_Octets_Per_Packet – 单个数据包中可接收的有效载荷字节数上限
LE 读取建议的默认数据长度命令 [v2]
![HCI_LE_Read_Suggested_Default_Data_Length [v2] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Read_Suggested_Default_Data_Length_v2_white.png)
允许主机读取为控制器设置的LL数据PDU传输参数的建议默认值（Suggested_Max_TX_Octets、Suggested_Max_TX_Time）。 [v2] 引入了参数 PHYS 命令，用于指定正在读取其传输参数的物理层（PHY）（GFSK 或 HDT），并将返回的 Suggested_Max_TX_Octets 值范围的上限提高到 8175 个字节。
LE 接收器测试命令 [v4]
![HCI_LE_Receiver_Test [v4] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Receiver_Test_v4_white.png)
用于启动一项测试，在此测试中，被测单元（IUT）以固定间隔接收测试参考数据包。[v4] 引入了 HDT_SNR_Test 命令参数 ，用于指定是否对 HDT PHY 执行信噪比（SNR）测量。此外，还为 PHY 添加了一个新值，用于指示是否使用 HDT PHY。
LE 设置 CIG 参数命令 [v2]
![HCI_LE_Set_CIG_Parameters [v2] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Set_CIG_Parameters_v2_white_b.png)
由中央主机用于在控制器中创建 CIG，并设置与该 CIG 关联的一个或多个 CIS 的参数。[v2] 引入了以下命令参数以支持 HDT PHY，同时为 PHY_C_To_P[i] 和 PHY_P_To_C[i] 添加了新的位号，用于指示 HDT PHY 的使用情况。
- Coded_Rates_C_To_P[i] – 表示从中心节点到外围节点时，相对于LE编码物理层应优先采用的速率
- Coded_Rates_P_To_C[i] – 表示从外设到中央节点时，相对于LE编码物理层应优先采用的速率
- HDT_Rates_C_To_P[i] – 指示从中心到外围设备通过 HDT PHY 应优先使用的速率
- HDT_Rates_P_To_C[i] – 指示从外设到中央节点时，通过 HDT PHY 应优先使用的速率
- HDT_MIC_Length[i] – 表示用于加密的MIC长度
- HDT_Packet_Format[i] – 指示控制器应优先使用的 HDT 数据包格式
LE 设置 CIG 参数测试命令 [v2]
![HCI_LE_Set_CIG_Parameters_Test [v2] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Set_CIG_Parameters_Test_v2_white.png)
仅用于测试目的。由中央主机用于创建 CIG，并在控制器中设置与该 CIG 关联的一个或多个 CIS 的参数。 [v2] 引入了以下用于支持 HDT PHY 的命令参数，将“Max Payload”命令参数的上限提高至 8175 字节，并为 PHY_C_To_P[i] 和 PHY_P_To_C[i] 定义了新的位号，以指示 HDT PHY 的使用情况。
- Coded_Rates_C_To_P[i] – 指定从中心节点到外围节点通过 LE 编码物理层应采用的优先速率
- Coded_Rates_P_To_C[i] – 指定从外设到中央节点通过 LE 编码物理层应采用的优先速率
- HDT_Rates_C_To_P[i] – 指示从中心到外围设备通过 HDT PHY 应优先使用的速率
- HDT_Rates_P_To_C[i] – 指示从外设到中央节点时，通过 HDT PHY 应优先使用的速率
- HDT_MIC_Length[i] – 表示用于通过 HDT 进行加密的 MIC 长度
- HDT_Packet_Format[i] – 指示控制器应优先使用的 HDT 数据包格式
- HDT_Payload_Window_Size_C_To_P[i] – 表示从中心节点到外围节点所使用的有效载荷窗口大小
- HDT_Payload_Window_Size_P_To_C[i] – 表示外设到中央节点所使用的有效载荷窗口大小
LE 设置数据长度命令 [v2]
![HCI_LE_Set_Data_Length [v2] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Set_Data_Length_v2_white.png)
允许主机为给定连接上的LL数据PDU建议最大传输有效载荷大小和时间。[v2]引入了参数 PHYS命令，用于指定该参数适用的物理层（GFSK或HDT），并将TX_Octets值的上限提高至8175字节。
LE 测试结束命令 [v2]
![HCI_LE_Test_End [v2] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Test_End_v2_white.png)
用于中止任何正在进行的测试。[v2] 引入了返回值参数 Num_Blocks，用于指示 HDT PHY 上接收到的数据块数量。
LE 发射器测试命令 [v5]
![HCI_LE_Transmitter_Test [v5] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Transmitter_Test_v5_white.png)
用于启动一项测试，在此测试中，被测单元（IUT）以固定间隔生成测试参考数据包。[v5] 引入了以下用于 HDT 传输测试的命令参数，并为 PHY 添加了一个新值，用于指示 HDT PHY 的使用情况。
- HDT_Rate_Indicator – 指定 HDT PHY 速率
- HDT_Packet_Format_Indicator – 指定 HDT 数据包格式
- HDT_Payload_Length – 指定数据包格式 0 下的有效载荷长度（在 PF1 中被忽略）
- HDT_PHY_Interval – 指定每个 PHY 间隔中的有效载荷符号数
- HDT_Num_Blocks[i] – 指定有效载荷中的块数（Nb）（对于 PF0，Nb=0）
- HDT_Block_Size[i] – 指定有效载荷中每个数据块的长度（不包括最后一个）
- HDT_Final_Block_Size[i] – 指定要传输的最后一个数据块的长度
LE 写入建议默认数据长度命令 [v2]
![HCI_LE_Write_Suggested_Default_Data_Length [v2] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Write_Suggested_Default_Data_Length_v2_white.png)
允许主机为控制器指定/写入LL数据PDU传输参数的建议默认值（Suggested_Max_TX_Octets、Suggested_Max_TX_Time）。 [v2] 引入了参数 PHYS 命令，用于指定正在为其指定传输参数的物理层（GFSK 或 HDT），并将 Suggested_Max_TX_Octets 值范围的上限提高至 8175 个字节。
刷新加密密钥命令 [v2]
![HCI_Refresh_Encryption_Key [v2] 命令参数](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_Refresh_Encryption_Key_v2_white.png)
由主机调用，用于促使控制器通过“加密刷新”过程，刷新由 Connection_Handle 标识的 ACL 连接上的加密密钥。当该连接使用 HDT PHY 时，需指定 MIC 长度。
8.4 更新的 HCI 命令和事件
LE BIG Sync 已确立的活动
Max_Payload 事件中参数 的值范围上限已增加至 8175 字节。
LE BIGInfo 广告报告活动
Max_Payload 事件中参数 的值范围上限已增加至 8175 字节。此外，定义了新的 PHY 事件参数 ，用于指示 HDT PHY 上传输了 BIG。
LE CS “设置过程参数”命令
定义了新的 PHY 命令参数 值，用于指示 HDT PHY 的使用情况。
LE 增强型读取发射功率电平命令
定义了用于指定 HDT PHY 关联的 PHY 命令和返回参数的新值。
LE 帧空间更新完成事件
定义了 PHYS 事件参数 的新位号，用于指示 HDT PHY 的使用情况。
“LE PHY 更新完成”活动
定义了 TX_PHY 和 RX_PHY 事件参数的新值，用于指示使用 HDT PHY 进行发送和接收。
LE 读取 PHY 命令
TX_PHY 和 RX_PHY 返回参数的全新值，用于指示 HDT PHY 的使用情况。
LE 读取远程发射功率级命令
为 PHY 命令 `参数 ` 定义了新值，用于指定 HDT PHY 关联。
LE 设置默认 PHY 命令
定义了 TX_PHY 和 RX_PHY 命令参数的新取值，用于指示 HDT PHY 的使用情况。
LE 设置事件掩码命令
为该掩码新增了四个事件：LE CIS Established [v3]、LE Create BIG Complete [v2]、LE Data Length Change [v2] 以及 LE Test Report HDT Link Quality。
LE 设置 PHY 命令
为 TX_PHY、RX_PHY 和 PHY_Options 命令参数定义了新的位号，用于指示 HDT PHY 的使用情况和偏好设置。
LE 发射功率报告事件
定义了新的 PHY 事件参数 值，用于指示 HDT PHY 的使用情况。
“设置事件掩码”第 2 页命令
在掩码中新增了三个事件：加密更改 [v3]、加密密钥刷新完成 [v2] 以及加密密钥调试报告。
8.5 消息序列图
下文中的图表展示了与蓝牙低功耗（Bluetooth LE）链路层 相关的人机交互（HCI）命令和事件在HDT支持下的典型交互方式。
从 GFSK 物理层切换到 HDT 物理层
未加密的ACL连接
图 8.1 – 在未加密的 ACL 连接上切换至 HDT PHY
加密的ACL连接
图 8.2 – 在加密的 ACL 连接上切换至 HDT PHY
从 HDT PHY 切换到 GFSK PHY
未加密的ACL连接
图 8.3 – 在未加密的 ACL 连接上从 HDT PHY 切换到 GFSK PHY
加密的ACL连接
图 8.4 – 在加密的 ACL 连接上从 HDT PHY 切换到 GFSK PHY
数据长度更新
图 8.5 – 数据长度更新
[v2] 或更高版本中，HCI_LE_Set_Data_Length 命令、HCI_LE_Data_Length_Change 事件、LL_LENGTH_REQ PDU 以及 LL_LENGTH_RSP PDU 用于更改 HDT PHY 的参数。
通过 HDT 配置 CIG
图 8.6 – 基于 HDT PHY 的 CIG 和 CIS 配置
使用密钥调度开始加密
图 8.7 – 使用密钥调度开始加密
启动基于密钥调度机制的随机加密
图 8.8 – 启动机会性加密
使用密钥调度重新启动加密
图 8.9 – 使用密钥调度重启加密
使用密钥调度刷新加密
图 8.10 – 使用密钥调度刷新加密
9. 其他
Bluetooth® HDT 对蓝牙低功耗（Bluetooth LE）协议栈的主机层和 ISOAL 层进行了更新。主机层的更新主要支持对 MIC 长度要求的验证和强制执行，而 ISOAL 层的更新则支持通过新的 HDT PHY 传输更大的数据有效载荷。
9.1. 逻辑链路控制与适配协议（L2CAP）
HDT 将 MIC 长度作为创建采用基于信用的流控制（CBFC）的 L2CAP 数据信道时的额外安全标准。
CBFC 是一种机制，通过该机制，利用接收方授予的信用额度来调节设备间的数据传输，并管理面向连接的 L2CAP 信道。CBFC 有两种模式：LE 模式和增强型模式。从宏观层面来看，LE 模式的 CBFC 每建立一个连接就建立一个 L2CAP 信道，而增强型模式的 CBFC 则可以同时建立多个信道。这两种模式均通过 L2CAP 流程启用，该流程涉及交换基于信用的连接请求及相应的响应。
HDT 扩展了在建立基于信用的 L2CAP 信道时执行的安全验证，使设备除了进行传统的身份验证、授权和加密密钥长度检查外，还能检查并强制执行 MIC 长度要求。它为响应数据包的“Result”数据字段引入了新值，用于指示连接请求因协商的 MIC 长度不足而被拒绝。
9.2. 通用访问配置文件（GAP）
HDT 对 LE 安全模式 1 的规范以及服务授权流程进行了微调，从而改进了蓝牙 LE 设备通过通用访问配置文件 (GAP) 访问服务时评估和满足安全要求的方式。
在 GAP 中，安全模式定义了蓝牙低功耗（Bluetooth LE）连接必须满足的要求，以便设备能够安全地访问服务和属性。LE 安全模式 1 通过四种安全级别来管理 LE ACL 连接的安全性，这些级别采用了身份验证和加密的不同组合。
HDT 扩展了 LE 安全模式 1，要求在 HDT PHY 上运行的加密连接必须使用强度相当于 128b 的长期密钥（LTK）。如果相关的 LTK 无法达到要求的 128b 强度，则设备不得将连接切换至 HDT PHY，也不得建立使用 HDT PHY 的 CIS。
HDT 还更新了用于响应和发起服务请求的 GAP 流程。当某项服务所需的安全级别超出当前连接所能满足的范围时，GAP 现可对服务请求进行评估；若协商得到的 MIC 长度不符合该服务的要求，则会以“MIC 长度过短”的错误代码拒绝该请求。
当设备发起服务请求时，若MIC长度不足，GAP可触发PHY更新和加密刷新流程，以在重试该请求前获取所需的MIC长度。如果无法建立所需的MIC长度，则该请求将被拒绝。
更多详情请参阅《核心规范》第3卷C部分。
9.3. 属性协议（ATT）
HDT 将 MIC 长度作为访问由属性协议（ATT）管理的属性的额外安全标准。
ATT 是蓝牙低功耗 (Bluetooth LE) 设备所使用的协议，用于让客户端发现、读取、写入以及以其他方式访问服务器公开的属性。
HDT 引入了一个新的错误代码“MIC 长度过短”，用于指示属性访问请求因协商得到的 MIC 长度无法满足所请求属性的安全要求而被拒绝。该错误代码已纳入 ATT 属性权限中，并在访问受保护属性的所有 ATT 程序中均受支持，包括属性发现、读取和写入操作。
《核心规范》第3卷F部分中列出了已更新以支持新错误代码的ATT PDU，现将其列于下文以供参考。
- ATT_ERROR_RSP
- ATT_FIND_INFORMATION_REQ
- ATT_FIND_BY_TYPE_VALUE_REQ
- ATT_READ_BY_TYPE_REQ
- ATT_READ_REQ
- ATT_READ_BLOB_REQ
- ATT_READ_MULTIPLE_REQ
- ATT_READ_BY_GROUP_TYPE_REQ
- ATT_READ_MULTIPLE_VARIABLE_REQ
- ATT_WRITE_REQ
- ATT_PREPARE_WRITE_REQ
9.4. 通用属性配置文件（GATT）
HDT 对《GATT 配置文件》中定义的用于读写特征值和描述符的程序进行了微调，以便识别和传播 ATT 级别的 MIC 长度安全检查以及新的“MIC 长度过短”错误情况。
更新后的《关贸总协定》程序载于《核心规范》第3卷G部分，现列于下文以供参考。
- 读取特征值
- 读取长特征值
- 读取多个特征值
- 读取多个可变长度的特征值
- 写出特征值
- 写出长特征值
- 特征值 可靠写入
- 读取特征描述符
- 读取长特征描述符
- 写入特征描述符
- 编写长特征描述符
9.5. 等时适应层（ISOAL）
HDT 推出了对等时自适应层（ISOAL）的更新，这些更新对于支持由 HDT PHY 实现的大容量数据负载传输至关重要。
ISOAL 负责对通过等时传输（如 LE Audio 的 CIS 和 BIS 流中所用）交换的服务数据单元（SDU）进行分段和重组。
为了支持更大的 SDU 分段，HDT 通过将“长度”字段从 8 位扩展到 12 位，更新了 ISOAL 帧化 PDU 分段头部的格式。该“长度”字段表示帧化 PDU 中所承载的 SDU 分段的大小（以八位字节为单位）。为了保持与现有头部格式的兼容性，该 12 位值在分段头部中被划分为独立的“长度高”和“长度低”字段。
这些更改增加了 ISOAL 可表示的最大 SDU 分段大小，从而在保持与现有 ISOAL 分段和重组架构兼容的同时，能够高效传输更大的有效载荷。更多详细信息请参阅《蓝牙核心规范》第 6 卷 G 部分。
尽管这些更改是在 ISOAL 内部实现的，但其影响可能会波及到蓝牙协议栈的更高层。 通过支持更大的SDU分段，ISOAL使控制器能够传输更大的等时有效载荷，这些有效载荷最终可通过更大的ISO数据包传递给主机。虽然分段和重组对大多数主机和应用软件而言仍是透明的，但HDT提供的更大有效载荷容量有助于支持要求更高的等时数据流，而无需更改底层的ISOAL分段和重组架构。
10. 结论
蓝牙®高数据吞吐量技术显著提升了蓝牙低功耗（Bluetooth LE）的功能和性能，为新一代无线体验奠定了基础，并为整个蓝牙生态系统带来了新的创新机遇。
全新的蓝牙 HDT PHY 拓展了蓝牙低功耗（Bluetooth LE）的性能边界，通过更高的频谱效率、自适应数据速率以及旨在确保在不断变化的信道条件下维持可靠通信的机制，将支持的最高比特率提升至 7.5 Mbps。
新的蓝牙 HDT 数据包结构通过灵活的格式设计，与更高容量的 PHY 相辅相成，旨在平衡效率、鲁棒性和开销。将控制头与有效载荷分离，既能更稳健地处理关键数据包信息，又能支持有效载荷传输的动态数据速率。更大的有效载荷、有效载荷聚合、基于块的传输以及选择性重传，进一步使 HDT 能够高效传输更大数据量，同时将传输错误的影响降至最低。
HDT链路层 增强功能提供了配置和管理 HDT 运行、协调 GFSK 与 HDT 物理层之间的切换、响应不断变化的链路状况、支持等时通信，以及管理蓝牙 HDT 引入的增强型安全功能所需的智能。
HDT 通过延长 MIC 长度并支持加密密钥调度（EKS）功能来增强蓝牙低功耗（Bluetooth LE）的安全性，从而为更大的有效载荷提供更强的保护，并在设备在 GFSK 和 HDT 工作模式之间切换时实现协调的密钥更新。EKS 还引入了机会加密、完美前向保密以及更灵活的加密密钥管理等功能。
HCI 层和主机层的更新将 HDT 控制器功能集成到了更广泛的蓝牙低功耗（Bluetooth LE）协议栈中，为主机提供了设置 HDT 首选项和参数、监控 HDT 运行状况，以及支持新物理层（PHY）带来的更大有效载荷和增强的安全要求所需的接口。
对于已成熟的蓝牙应用和用例，蓝牙 HDT 提供了开发人员可在新一代产品中利用的功能，从而实现更快的数据传输、更大的容量、更高的效率以及更稳定的无线性能。与此同时，HDT 拓展了蓝牙低功耗（Bluetooth LE）的应用边界，为更复杂的体验（如高分辨率和无损音频）以及数据需求日益严苛的新兴应用，提供了所需的额外性能和容量。
总体而言，蓝牙技术一直在不断演进，以满足新的应用需求，同时保持了促使其广泛应用的互操作性、效率和灵活性。蓝牙®高数据吞吐量技术标志着这一演进过程中的重要一步，它为蓝牙低功耗（Bluetooth LE）提供了所需的额外性能和容量，使其能够与依赖它的应用和用户体验同步发展。
有关完整的实现要求和技术细节，请参阅《蓝牙核心规范 7.0》。
1.C. E. 香农，《通信的数学理论》，《贝尔系统技术期刊》，第 27 卷，第 379–423 页和第 623–656 页，1948 年 7 月和 10 月。
