Bluetooth® Core 7.0 功能概述

版本：	1.0
出版日期：	2026年11月3日
作者：	卢功宇

1. 导言

Bluetooth® Core 7.0 引入了一系列增强功能，扩展了 Bluetooth® LE 在数据吞吐量、等时传输、安全性以及实现支持方面的能力。这些增强功能旨在满足不断变化的需求，包括更高的吞吐量、更灵活的传输行为、新的安全模型，以及在开发和互操作性测试中提供更好的可视性。这些功能在现有 Bluetooth 架构的基础上进一步发展，同时引入了新功能，使 Bluetooth 设备能够适应日益严苛的应用和运行环境。

本文对蓝牙® Core 7.0 中引入的关键特性进行了技术概述。文中探讨了蓝牙®高数据吞吐量（HDT）、蓝牙®低功耗等时参数 更新（IPU）、蓝牙®加密密钥调度（EKS）、蓝牙®临时应用密钥（TAK）以及蓝牙®加密产品调试（EPD）。 针对每一项功能，本文阐述了其设计初衷、架构理念和主要协议机制，为理解这些变更如何扩展和演进蓝牙技术奠定了基础。

注：本文是一份营销文档，绝不旨在以任何方式取代或凌驾于《蓝牙®核心规范》之上。每项功能增强都在专门的章节中进行说明，并以相关背景信息开篇。此举旨在帮助可能对蓝牙®低功耗（LE）某些方面不熟悉的读者。不过，这些背景章节并非面面俱到。若读者遇到不熟悉的术语或概念，建议下载并阅读《蓝牙®低功耗（LE）入门指南》。

2.一目了然

2.1 蓝牙®高数据吞吐量

蓝牙®高数据吞吐量（HDT）引入了一种新的蓝牙低功耗（LE）物理层，将蓝牙的最大比特率提升至7.5 Mbps，同时提高了无线传输效率和鲁棒性。通过结合高阶调制、卷积前向纠错、同步增强、自适应速率选择以及增强的数据包架构，HDT使蓝牙设备能够更高效、更可靠地传输更大容量的数据。 该功能为未来更高数据速率的蓝牙应用（包括高分辨率和无损音频流传输）提供了可扩展的基础，同时保持了与现有蓝牙低功耗（LE）架构的向后兼容性。

2.2 蓝牙®低功耗（Bluetooth® LE）等时参数 更新

蓝牙® LE 等时参数 更新（IPU）引入了一种标准化机制，允许在流建立后更新活动连接等时流（CIS）的参数。 当带宽、延迟、传输或调度要求发生变化时，IPU 使设备能够在保持现有连接的同时，在不同的流配置之间进行切换，而无需删除并重新创建连接等时组 (CIG)。该功能提高了蓝牙低功耗音频及其他等时应用的灵活性，减少了服务中断，并使蓝牙® 设备能够根据不断变化的应用需求动态调整传输特性。

2.3 蓝牙®加密密钥表

蓝牙®加密密钥调度（EKS）为建立和管理蓝牙®低功耗（LE）连接所使用的加密密钥引入了一个新框架。EKS 并非直接从长期密钥（LTK）派生加密材料，而是将基于 ECDH 的密钥建立与基于 CMAC 的密钥派生层次结构相结合，以生成特定于会话的加密材料。 该架构使设备能够刷新加密密钥、为不同的传输类型维护独立的安全上下文，并支持增强的消息完整性码（MIC）保护。EKS 既是蓝牙®高数据吞吐量（HDT）的安全基础，同时也作为一项独立的蓝牙功能而存在，可支持其他蓝牙用例。

2.4 蓝牙® 临时应用密钥

蓝牙®瞬时应用密钥（TAK）通过无需依赖配对或绑定即可实现加密，为保障蓝牙®低功耗（LE）连接的安全性提供了一种新方法。在此模型中，身份验证和密钥建立由更高层的应用程序处理，该应用程序会建立一个具有128位安全强度的共享密钥，并将其提供给蓝牙主机。随后，TAK被用于建立链路层 加密，从而允许设备在无需建立长期信任关系的情况下创建安全连接。 主机在启动加密开始程序后会丢弃该 TAK，而高层应用程序则自行决定如何管理其持有的密钥副本。

2.5 蓝牙®加密产品调试

蓝牙®加密产品调试（EPD）引入了一种标准化机制，允许蓝牙®主机接收加密连接所使用的活动加密凭证。通过让授权的调试工具能够查看由控制器生成和维护的凭证，EPD有助于在蓝牙加密从传统的基于长期密钥的运行模式向更高级别演进的过程中，保持协议分析和互操作性调试的能力。

3. 蓝牙®高数据吞吐量（HDT）

蓝牙®高数据吞吐量（HDT）引入了一种新的蓝牙®低功耗（LE）物理层，将蓝牙最大比特率提升至7.5 Mbps，同时提高了无线传输效率和鲁棒性。通过结合高阶调制、卷积前向纠错、同步增强、自适应速率选择以及增强的数据包架构，HDT使蓝牙设备能够更高效、更可靠地传输更大容量的数据。 该功能为未来更高数据速率的蓝牙应用（包括高分辨率和无损音频流传输）提供了可扩展的基础，同时保持了与现有蓝牙® LE 架构的兼容性。

3.1 背景

3.1.1 蓝牙®低功耗（Bluetooth® LE）吞吐量的演变

蓝牙低功耗（Bluetooth LE）通过引入旨在满足不同性能目标的新物理层不断演进。继最初的 LE 1M PHY 之后，蓝牙技术又推出了 LE 2M 以提高吞吐量，并推出了 LE Coded 以在恶劣的无线电环境中提升传输距离和抗干扰能力。这些增强功能在保持互操作性和能效的同时，拓展了蓝牙®低功耗在广泛应用场景中的适用性。

然而，尽管蓝牙低功耗（Bluetooth LE）技术一直在不断发展，但其支持的最高比特率仍被限制在2 Mbps。随着蓝牙设备交换的数据量日益增大，且需要支持要求更高的应用，对更高吞吐量的需求也在持续增长。

3.1.2 现有蓝牙®低功耗（Bluetooth® LE）物理层（PHY）的局限性

将吞吐量提升至 2 Mbps 以上面临着更根本的挑战。蓝牙低功耗（Bluetooth LE）在覆盖全球的 2.4 GHz ISM 频段内运行，在此频段内，必须仔细权衡频谱可用性、监管要求、实现复杂性和能效等因素。

现有的蓝牙低功耗（Bluetooth LE）物理层基于高斯频移键控（GFSK）调制方案，该方案凭借其简单性、鲁棒性以及较低的实现复杂度，为蓝牙技术的成功做出了重大贡献。然而，正是这些特性限制了通过传统方法提高吞吐量的空间。

3.2 技术概述

3.2.1 HDT 架构

蓝牙®高数据吞吐量（HDT）通过引入一种新的蓝牙® LE 物理层来解决这些限制，该物理层经过优化，可实现显著更高的频谱效率，同时仍完全集成于蓝牙® LE 架构之中。HDT 并非引入一种独立的无线技术，而是基于现有的蓝牙® LE 框架，并通过新增功能对其进行扩展，旨在支持大幅更高的吞吐量。

在物理层，HDT 引入了新的调制和编码技术，可在现有的蓝牙信道结构内实现显著更高的数据速率。为了支持这些功能，HDT 还对数据包格式、链路层 流程、安全机制以及主机控制器接口 (HCI) 功能进行了增强。这些增强措施共同使蓝牙设备能够更高效地传输更多数据，同时保持蓝牙技术应有的互操作性和可靠性。

图3.2.1展示了蓝牙低功耗（Bluetooth LE）协议栈，并重点标出了为支持HDT而进行增强的主要协议层。尽管HDT引入了大量新功能，但它仍完全集成在蓝牙低功耗架构之中，并继续在与现有蓝牙低功耗设备相同的2.4 GHz ISM频段内运行。

下文将更详细地探讨这些架构增强功能，首先介绍HDT PHY，随后依次探讨数据包架构、链路层 增强功能以及安全框架，这些功能共同实现了高吞吐量的蓝牙通信。

3.2.2 HDT 物理层

HDT PHY 是蓝牙®高数据吞吐量的基础，其支持的比特率远高于现有的蓝牙® LE PHY。这是通过对调制、编码和同步机制的改进实现的，这些改进共同提高了频谱效率，同时确保了可靠的无线通信。

3.2.2.1 调制、编码和HDT速率

传统的蓝牙®低功耗（Bluetooth® LE）物理层（PHY）基于高斯频移键控（GFSK），其中每个符号代表一个比特的信息。虽然这种方法具有出色的鲁棒性且实现简单，但它限制了在给定信道带宽内可传输的信息量。HDT通过引入高阶相干调制方案和前向纠错（FEC）来解决这一限制，从而显著提高了频谱效率。

HDT PHY 在所有工作模式下均采用通用的卷积前向纠错（FEC）框架。通过调制效率与编码效率的组合，可实现不同的 HDT 速率。在 FEC 编码之后，可采用打孔技术有选择地移除编码位，从而提高有效码率，并在吞吐量与鲁棒性之间实现不同的权衡。

LE HDT PHY 以2 Msym/s的固定符号率工作（符号周期 = 0.5 μs）。有效比特率取决于以下三个因素：

• 符号率
• 每符号位数
• 有效编码率

从概念上讲，有效比特率可表示为：

有效比特率 = 符号率 × 每符号比特数 × 有效编码率

调制方案决定了每个传输符号所表示的比特数，而有效码率则反映了在应用前向纠错（FEC）编码和穿孔处理后，传输比特中携带用户数据的比例。 高阶调制方案通过每符号传输更多比特来提高频谱效率，而更高的编码率则可降低编码开销并提高有效数据的比例。这些机制共同使HDT能够在保持统一物理层架构的同时支持多种工作速率，如表3.2.2.1所示。

HDT速率	有效比特率	调制方案	每符号位数	有效编码率	可用性
HDT2	2 Mb/s	π/4 QPSK	2	1/2	强制性
HDT3	3 Mb/s	π/4 QPSK	2	3/4	强制性
HDT4	4 Mb/s	8PSK	3	2/3	强制性
HDT6	6 Mb/s	16QAM	4	3/4	可选
HDT7.5	7.5 Mb/s	16QAM	4	15/16	可选*

*要支持 HDT7.5，必须先支持 HDT6。

例如，HDT2 结合了 2 Msym/s 的符号率、π/4 QPSK 调制（每符号 2 位）和 1/2 的有效码率，从而实现了 2 Mb/s 的有效比特率。 同样，HDT7.5 将 16QAM 调制（每符号 4 位）与 15/16 的有效编码率相结合，从而实现 7.5 Mb/s 的有效比特率。这种调制效率与编码效率的灵活组合，使 HDT 设备能够根据工作要求和信道条件，在吞吐量与鲁棒性之间取得平衡。

强制性的 HDT2、HDT3 和 HDT4 速率为支持 HDT 的设备确立了通用的互操作性基准。更高速率的模式通过采用 16QAM 调制和降低编码开销，进一步提高了吞吐量，使蓝牙技术能够支持高达 7.5 Mb/s 的比特率。

3.2.2.2 同步与鲁棒性

与传统的基于GFSK的通信相比，高阶调制方案通常需要更精确的同步和信道估计。为了在更高的比特率下保持可靠运行，HDT引入了若干物理层机制，这些机制在整个接收过程中支持数据包捕获、信道估计、接收机跟踪以及周期性重新同步。表3.2.2.2总结了HDT引入的关键同步和鲁棒性机制。

机制	摘要
短训练序列（STS）	• 支持快速初始数据包检测、粗略时序对齐以及自动增益控制（AGC）稳定 • 出现在前导码中，即每个HDT数据包的开头，并连续重复多次 • 建立进入该数据包的可靠入口点
长训练序列（LTS）	• 支持精细时序对准、频率偏移估计/校正以及初始信道估计 • 也出现在HDT数据包的前导码中，位于STS之后，并连续重复数次 • 为接收机的相干解调做好准备
保护间隔（GI）	• 用于吸收因训练序列、符号流以及调制或编码边界之间的切换而产生的瞬态效应的时间缓冲区 • 在前导码中（STS与LTS之间）显式出现，并在整个数据包中通过终止符号隐式存在 • 允许接收机滤波器和定时环路在进行精细的LTS同步之前稳定下来，并确保符号流之间的平滑过渡
终止符号	• 在符号流之间建立明确的边界，并吸收符号流转换时的瞬态效应 • 出现在数据包中每个独立处理的符号流的末尾（例如，控制头之后、PDU头区域之后、数据包格式1中的每个PHY间隔之后等） • 允许前向纠错（FEC）解码器在下一段/流开始前清空状态并重置 • 对于数据包格式 1 而言尤为重要，有助于限制错误传播、实现部分数据包恢复，并在错误仅局限于单个物理层间隔时降低重传成本
PHY 间隔	• 允许将长有效载荷拆分为更小、更易于管理的解码单元 • 仅出现在数据包格式 1（PF1）HDT 数据包的有效载荷区中 • 启用自适应调制和动态速率选择
PHY间歇训练序列（PITS）	• 启用数据包中途重新训练，以刷新相位和信道估计，从而实现对被划分为多个物理层间隔的有效载荷的鲁棒接收 • 仅出现在数据包格式 1（PF1）HDT 数据包的“有效载荷区”中 • 对于以高比特率传输的长有效载荷而言尤为重要，因为在数据包传输期间信道状况可能会发生变化；连续信道跟踪可提高对衰落、相位漂移和多径效应的鲁棒性

这些机制共同构成了一个分层同步框架。STS 和 LTS 支持初始数据包捕获和信道估计，而 PHY 间隔和 PITS 则在较长的高吞吐量传输期间实现周期性信道跟踪和同步刷新。终止符号支持可靠的数据包完成和接收机状态转换。

这些机制的整合使 HDT 能够在不断变化的无线电环境下保持可靠的通信，同时支持比以往的蓝牙® LE 物理层（PHY）高得多的吞吐量。

3.2.3 HDT数据包

HDT PHY 为实现显著更高的数据吞吐量奠定了基础。但在这些比特率下要实现可靠且高效的运行，还需要对蓝牙数据包架构进行相应的改进。 蓝牙®高数据吞吐量（HDT）引入了一种新的数据包框架，旨在支持自适应比特率、大容量有效载荷传输、选择性重传，并在多变的无线电环境下提高鲁棒性。与传统的蓝牙® LE 数据包不同，HDT 数据包引入了额外的结构层，这些层允许控制信息、协议元数据和有效载荷数据独立处理，同时支持先进的吞吐量和可靠性功能。

3.2.3.1 HDT数据包结构

如图3.2.3.1所示，HDT数据包结构由四个主要区域组成：前导码、控制头、可选的PDU头区域以及可选的有效载荷区域。前导码和控制头在所有HDT数据包格式中都存在，而PDU头区域和有效载荷区域是否存在则取决于所使用的数据包格式。

从宏观层面来看，每个区域都有其独特的功能：

序言

提供可靠接收HDT所需的数据包检测、同步、时序捕获、频率偏移校正和信道估计功能。这些功能在第3.2.2节中有更详细的描述。

控制头

包含识别数据包并确定后续数据包内容应如何处理所需的关键信息。将这些信息与高速有效载荷数据分离，可在有效载荷解调开始之前实现可靠的数据包解析。

PDU 头区

携带用于解释和管理有效载荷数据的协议级元数据。该元数据支持有效载荷聚合、确认处理、选择性重传、链路质量反馈、流量控制以及未来协议的可扩展性等功能。

有效载荷区

承载组织在一个或多个块中的用户数据。数据包格式 0 仅包含一个块。在数据包格式 1 中，有效载荷可被划分为逻辑块，以支持高效的错误恢复和选择性重传。

3.2.3.2 HDT数据包格式

为了支持广泛的蓝牙应用和流量模式，HDT 定义了三种数据包格式。每种格式都针对吞吐量、鲁棒性和协议开销之间的不同平衡进行了优化。

简短格式

短格式是一种简化的数据包结构，用于不传输有效载荷数据的情况。它主要用于确认、同步和控制信令，以最大限度地减少空中时间消耗和协议开销。短格式数据包的结构如图3.2.3.2a所示。

数据包格式 0 (PF0)

数据包格式 0 经过优化，可传输单个有效载荷块，且开销极小。它非常适合无需有效载荷分段和高级重传机制的小型及中等规模数据传输。数据包格式 0 的结构如图 3.2.3.2b 所示。

数据包格式 1 (PF1)

数据包格式 1（PF1）是功能最强大的 HDT 数据包格式，旨在实现最大吞吐量和大型有效载荷传输。除了支持规模大幅更大的数据传输外，PF1 还引入了有效载荷聚合、基于块的传输、选择性重传、增强的报头保护以及物理层（PHY）级鲁棒性机制。数据包格式 1 的结构如图 3.2.3.2c 所示。

表 3.2.3.2 对这三种数据包格式进行了比较和总结。

	简短	PF0	PF1
最大载荷	不适用	494 字节	8175 字节
适用于		更高的吞吐量	最高的吞吐量、效率和/或可靠性
关键 优势	• 若无待传输的有效载荷数据，且仅需对连续的完整有效载荷进行确认时，可减少空中传输时间	• 实现更简单 • 开销更低 • 带 MIC 的单一有效载荷块	• 每个数据包最多可包含四个有效载荷 • 将有效载荷划分为多个块 • 选择性（块）确认 • 有效载荷块可分布于多个数据包中 • PHY 间隔，使用 PITS 进行相位跟踪

3.2.3.3 有效载荷聚合与可靠性

数据包格式 1（PF1）引入的一项关键创新在于，它能够在保持稳健的无线性能的同时，高效传输大量数据。为实现这一目标，PF1 引入了有效载荷聚合、基于块的传输、选择性重传以及增强的错误保护机制。这些功能共同使 HDT 能够显著提高吞吐量，同时将数据包丢失和无线电条件变化的影响降至最低。 图 3.2.3.3 展示了 HDT 数据包中支持这些功能的 PDU 组成部分。

虽然数据包格式 0 只承载一个有效载荷块，但数据包格式 1 可以在单次数据包传输中聚合多达四个独立的有效载荷。这一功能通过允许同时传输多个有效载荷，从而降低了协议开销并提高了信道利用率。

为了进一步提高效率，PF1 引入了基于块的有效载荷模型。该模型不再将整个有效载荷视为单一传输单元，而是将每个有效载荷划分为 1 到 16 个逻辑块。这些块可以独立地进行描述、传输和跟踪，从而能够更高效地管理大型有效载荷。

基于块的传输支持选择性重传。通过额外的数据包元数据，发送方和接收方能够确定哪些有效载荷块已成功接收，哪些需要重传。当发生传输错误时，只需重传受影响的块，而正确接收的块则可保留。与重传整个有效载荷相比，这种方法显著降低了重传开销。

PF1 还通过额外的保护机制提高了可靠性。每个传输的块都包含独立的完整性检查，从而无需验证整个有效载荷即可对单个块进行验证。此外，数据包格式 1 还通过 PDU 头区报头错误检查（HEC-P）为协议元数据提供了专门的保护，有助于确保对有效载荷管理信息的可靠解析。

该数据包架构还通过可选的协议元数据支持高级链路管理功能。可以交换链路质量信息（包括信号强度、信噪比（SNR）以及推荐的优先传输速率等指标），从而更清晰地了解当前信道状况。此外，该架构还支持流量控制信令，使设备在缓冲或处理资源受限时能够动态管理有效载荷的传输行为。

最后，PF1的设计旨在与第3.2.2节中描述的PHY层机制（如PHY间隔和PHY间隔训练序列（PITS））协同工作。这些机制可在长时间传输期间实现接收机的周期性重新同步，并有助于在衰落、相位漂移及其他时变信道条件下保持稳健的通信。

通过结合有效载荷聚合、逻辑块、选择性重传、增强的元数据保护以及物理层（PHY）级鲁棒性机制，数据包格式 1 为高效、可靠的高吞吐量蓝牙通信奠定了基础。

3.2.4 蓝牙® HDT链路层

虽然 HDT PHY 和数据包架构为实现大幅更高的吞吐量奠定了基础，但在这些比特率下要实现可靠运行，还需要对蓝牙® LE链路层 进行相应的增强。HDT 并未引入独立的协议架构，而是通过在现有的蓝牙® LE链路层 中添加新的流程、功能和控制机制，使高吞吐量通信能够在既定的蓝牙® LE 框架内运行。

这些增强功能共同支持HDT能力协商、物理层管理、有效载荷传输、速率自适应、安全性、可靠性以及等时通信。链路层 提供了一个运行框架，能够将HDT物理层的吞吐量潜力转化为效率、鲁棒性和应用性能方面的实际提升。

表 3.2.4 总结了为支持 HDT 而引入的链路层 主要功能领域。

能力	费用项目
HDT的启动和PHY管理	启用 HDT 激活、功能协商以及 GFSK 与 HDT 工作模式之间的切换
HDT 数据长度管理与调度	在满足蓝牙®低功耗（Bluetooth® LE）时序和调度要求的同时，支持更大的有效载荷
HDT链路质量	提供动态链路质量报告和自适应功能
HDT 和等时信道	扩展了CIS和BIS对HDT操作的传输支持
HDT 安全与加密	整合了 EKS、更长的 MIC 以及协调一致的密钥管理
HDT的可靠性和流量控制	启用块级可靠性机制和增强型流量控制

以下各节概述了这些程序所支持的链路层 主要功能。

3.2.4.1 蓝牙® HDT 建立连接与物理层管理

蓝牙® HDT 通过在蓝牙® LE 连接上运行的链路层 流程进行初始化和管理。一旦设备之间建立了 HDT 功能，HDT 操作即可用于 ACL 连接、连接等时流 (CIS) 和广播等时流 (BIS)。HDT PHY 不用于广播，且必须始终通过专用的链路层 流程进行激活。

该过程始于HDT 配置交换程序，该程序使用新的LL_HDT_CONFIG_REQ和LL_HDT_CONFIG_RSP控制 PDU。通过该程序，设备之间交换与 HDT 相关的功能和运行参数，包括支持的 HDT 速率、有效载荷窗口功能、与安全相关的参数，以及建立 HDT 操作所需的其他信息。

设备并非协商单一的运行速率，而是建立一个支持的高数据传输速率（HDT）范围。在运行过程中，控制器可根据当前信道状况、实施策略和应用需求，在协商范围内动态选择任何速率。这种自适应速率模型可在无需额外连接重新配置的情况下，实现吞吐量与鲁棒性之间的平衡。

一旦交换了功能信息，设备即可通过“物理层更新和加密刷新”流程在 GFSK 物理层与 HDT 物理层之间切换，该流程扩展了现有的LL_PHY_REQ、LL_PHY_RSP 和LL_PHY_UPDATE_IND控制 PDU。这使得支持 HDT 的设备能够在保持蓝牙® LE 连接处于活动状态的同时，动态进入、修改或退出 HDT 工作模式。

从 GFSK 物理层切换到 HDT 操作时，还需要建立 HDT 专用的物理信道寻址信息。在此过程中，设备之间会交换物理信道地址 (PCA)信息，该信息可唯一标识物理信道上的 HDT 流量。PCA 支持数据包过滤、同步以及 HDT 传输的接收，同时仍与现有的蓝牙® LE 连接架构保持协调。

在正常运行期间，连接的两个方向均使用 GFSK PHY 或 HDT PHY。不过，每个方向的 HDT 速率均可独立选择，从而使吞吐量能够根据不断变化的信道状况和应用需求进行动态调整。如果无法使用 HDT 模式或不再需要该模式，通信仍可继续使用传统的蓝牙低功耗（Bluetooth LE）PHY。

3.2.4.2 蓝牙® HDT 数据长度管理与调度

蓝牙 HDT 引入了增强的数据长度管理功能，可在保持蓝牙连接和等时数据流所需时序特性的同时，支持比传统蓝牙® LE 操作中使用的有效载荷大得多的数据。

为了实现这一点，链路层 为 HDT 和 GFSK 工作模式分别维护了独立的传输长度和定时参数。这使得每个 PHY 系列都能根据各自的有效载荷和空中时间限制进行工作，同时支持在 HDT 与传统蓝牙低功耗模式之间进行无缝切换。

HDT 还引入了有效载荷窗口管理功能，允许在单次 HDT 传输中聚合多个有效载荷。通过 HDT 配置流程，设备之间交换有效载荷窗口能力，这些能力定义了有效载荷数据如何进行分组和传输。这些能力与第 3.2.3 节中描述的有效载荷聚合和基于块的传输机制协同工作，以提高信道利用率和传输效率。

由于 HDT 数据包承载的数据量可能远大于传统的蓝牙低功耗（Bluetooth LE）数据包，因此引入了额外的调度约束，以限制数据包的空中传输时间，并确保与 ACL 连接、CIS、BIS 以及其他并发蓝牙活动之间的共存。这些调度机制可确保在不影响蓝牙低功耗（Bluetooth LE）可预测的时序行为的前提下，实现更高的吞吐量。

增强型数据长度更新程序通过使用LL_LENGTH_REQ [v2]和LL_LENGTH_RSP [v2]，允许设备同时传输最大发送和接收有效载荷长度以及相关的定时参数。通过维护物理层（PHY）特定的限制，HDT 使控制器能够在保持与连接事件调度、等时操作以及多链路活动兼容的同时，最大限度地提高吞吐量。

3.2.4.3 蓝牙® HDT 连接质量

HDT 引入了一项可选的链路质量反馈（LQF）功能，该功能允许设备在运行过程中实时交换有关信道状况的信息。启用该功能后，设备之间可持续报告链路质量信息，从而使控制器能够更全面地了解当前的无线电状况。

这些报告可能包含信号质量测量数据以及推荐的工作速率，从而使控制器能够做出更明智的自适应决策。根据实施策略和测得的信道状况，控制器可调整HDT工作速率、修改传输行为，或在HDT与GFSK工作模式之间切换。

HDT 链路质量启用程序使用新的LL_HDT_LQF_REPORTING_IND控制 PDU 来启用或禁用链路质量反馈报告。LQF 可针对 ACL 和 CIS 传输分别进行配置，从而使不同类型的流量在适当情况下都能受益于信道质量感知功能。

通过直接展示当前信道状况，LQF 支持更高效地利用自适应速率操作，并有助于在各种无线环境下最大限度地发挥 HDT 的性能优势。

3.2.4.4 蓝牙® HDT 的可靠性与流量控制

HDT 引入了增强型可靠性机制，旨在高效支持大容量有效载荷传输。在基于数据包格式 1（PF1）的块式有效载荷架构基础上，HDT 通过块级恢复机制对传统的蓝牙® LE 确认行为进行了补充。

传统的蓝牙低功耗（Bluetooth LE）序列号和确认机制仍能确保数据包的排序并提供累积确认。HDT 通过对有效载荷块进行选择性确认，进一步扩展了这一模型。这在传输大量数据时，显著降低了重传开销。

HDT 还引入了增强的流量控制功能。通过 HDT 数据包头中携带的信息，当需要额外的缓冲或处理资源时，接收设备可以暂时暂停新有效载荷数据的传输。在此期间，重传活动仍可继续进行，既能确保可靠性机制正常运行，又能防止接收端过载。

一旦资源可用，便会自动恢复正常的有效载荷传输，无需上层干预或连接重新配置。这些机制共同提高了效率，保障了可靠性，并有助于HDT在严苛的运行条件下维持高吞吐量。

3.2.4.5 典型的蓝牙® HDT链路层 流程和控制消息

上文所述的链路层 功能是通过一系列新增和增强的程序及控制报文实现的。表3.2.4.5总结了具有代表性的链路层 程序以及用于建立、管理、保障和优化HDT运行的相关LL控制PDU。

程序	主要功能	代表性 LL 控制 PDU
HDT 配置交换	有效载荷窗口、速率能力、ACL/CIS HDT 参数	LL_HDT_CONFIG_REQ / LL_HDT_CONFIG_RSP
启用 HDT 链路质量	ACL/CIS 反馈报告	LL_HDT_LQF_REPORTING_IND（简体中文（大陆））
加密从密钥调度开始	EKS 的建立	LL_ENC_ECDH_REQ / LL_ENC_ECDH_RSP
数据长度更新	PHY 特定的有效载荷和空中时间限制	LL_LENGTH_REQ [v2] / LL_LENGTH_RSP [v2]
PHY 更新和加密刷新	PHY 切换、PCA 分配、MIC 更新、密钥刷新	LL_PHY_REQ [v2]、LL_PHY_RSP [v2]、LL_PHY_UPDATE_IND [v2]
创建连接的等时流	支持HDT的CIS建立	LL_CIS_REQ [v2]、LL_CIS_IND [v2]

这些协议共同构成了激活、管理、保障和优化 HDT 运行所需的信令框架，同时保持了与现有蓝牙低功耗（Bluetooth LE）链路层 架构的兼容性。它们还说明了 HDT 是如何在扩展现有蓝牙低功耗协议的基础上进行扩展，而非取代这些协议，从而在保持架构一致性和互操作性的同时，将更高的吞吐量整合到蓝牙生态系统中。

3.2.5 蓝牙® HDT HCI 层

主机控制器接口（HCI）是主机与控制器之间主要用于控制和状态通信的接口。为了支持 HDT 操作，蓝牙® LE 引入了新的 HCI 命令和事件，同时扩展了若干现有机制。这些增强功能使主机能够发现 HDT 功能、配置运行偏好、监控 PHY 状态转换、管理安全功能，以及控制支持 HDT 的等时传输。

与蓝牙架构一致，大多数 HDT 特定功能仍由控制器负责。诸如 PHY 状态转换、速率自适应、重传处理和数据包调度等对时序要求严格的功能，仍由控制器自主执行，而 HCI 则提供策略配置、诊断和应用感知所需的信息与控制功能。这既保留了主机决策与控制器执行之间的传统分离，又使应用程序能够充分利用 HDT 的功能。

HDT 所需的 HCI 增强功能可分为六大类：功能发现与配置、PHY 管理、吞吐量管理、安全管理、等时传输管理以及测试与诊断。表 3.2.5 总结了与 HDT 支持相关的主要 HCI 功能领域。

能力	费用项目
功能发现与配置	了解 HDT 的功能并配置操作偏好设置
PHY的选择与过渡协调	请求并监控 HDT PHY 的运行状况
数据长度和吞吐量管理	配置有效载荷限制和与吞吐量相关的参数
安全与加密管理	管理与 EKS 相关的功能并监控加密状态
等时传输管理	配置和监控支持 HDT 的 CIS 和 BIS 传输
测试与诊断	支持验证、调试和链路质量分析

以下各节概述了为支持 HDT 而引入的主要人机交互（HCI）功能。

3.2.5.1 功能发现与配置

在使用蓝牙® HDT 之前，主机必须确定本地和远程控制器所支持的功能，并配置应应用于未来连接的操作偏好。支持 HDT 的控制器会公开与所支持的 PHY 模式、HDT 速率能力、最大有效载荷大小、时序约束以及 HDT 相关安全功能有关的信息。这些信息使应用程序能够确定 HDT 操作是否适用于特定用例，并制定合适的操作策略。

HCI 还允许主机设置 HDT 的默认运行偏好。这些偏好可能包括首选的 HDT 速率、支持的数据包格式、有效载荷窗口功能以及与安全相关的参数。典型的接口包括LE 设置 HDT 默认参数命令，以及诸如LE 读取最大数据长度等增强型功能报告程序。

主机并不直接控制数据包级别的操作，而是表达其首选的操作行为，并将实时决策交由控制器处理。例如，主机可以指定ACL和等时传输的首选HDT速率范围，或表达对特定数据包格式的偏好。在实际运行过程中，控制器仍负责速率自适应、数据包调度以及其他时间敏感型决策。这种方法既提供了灵活性，又避免了主机不必要地参与链路层 的执行。

3.2.5.2 物理层选择与过渡协调

PHY 选择和 PHY 切换是蓝牙® HDT 在 HCI 层运行中最显而易见的方面之一。主机可通过现有的 PHY 选择机制，表明其支持或倾向于在 HDT PHY 上运行。此类请求传达了期望的运行行为，而控制器则仍负责确定是否能成功建立 HDT 连接。

当发生 PHY 转换时（无论是进入还是退出 HDT 工作模式），控制器都会通过 HCI 事件报告转换结果。这些通知使主机能够监控当前选定的 PHY、调整应用程序行为，并管理与吞吐量相关的预期，而无需详细了解链路层 的执行情况。典型的接口包括LE Set PHY命令和增强型LE PHY Update Complete事件，它们可让用户了解 PHY 转换后所处的运行模式。

由于HDT速率的选择仍由控制器控制，因此HCI报告侧重于物理层（PHY）选择和运行的结果，而非由链路层 执行的逐包决策。这保持了主机策略与控制器执行之间的传统分离。

3.2.5.3 数据长度和吞吐量管理

由于蓝牙® HDT 支持更大的有效载荷和更高的吞吐量，因此需要相应地增强 HCI 层级的配置和监控能力。主机可以配置与有效载荷相关的运行参数，并查询控制器的能力，从而在满足实现共存和时序约束的前提下优化吞吐量。

除了传统的有效载荷长度信息外，HDT 功能报告还会披露有效载荷窗口能力、最大接收数据包容量以及其他与吞吐量相关的运行参数。这些功能使控制器潜在的吞吐量更加透明，并有助于应用程序针对高带宽数据传输做出明智的缓冲、调度和资源分配决策。

HDT 继续将政策决策与链路层 的执行分离。主机可以配置首选的操作限制并监控协商出的能力，而控制器则在主动运行期间继续负责数据包聚合、有效载荷分段、重传管理以及调度决策。这种方法使应用程序能够受益于更大的有效载荷和更高的吞吐量，同时不会在主机层引入额外的协议复杂性。

协商有效载荷能力的变更可通过增强型LE 数据长度变更事件进行报告，从而使主机能够持续掌握活动连接的有效运行限制。这些接口与LE 设置数据长度和 LE 读取最大数据长度相结合，为支持 HDT 的系统中的吞吐量管理提供了主要的 HCI 框架。

3.2.5.4 安全与加密管理

第 3.2.6 节中所述的 Bluetooth® HDT 安全增强功能，是通过一组 HCI 控制和状态机制实现的，这些机制允许主机配置和监控与加密密钥调度 (EKS) 相关的功能，同时保持与现有 Bluetooth® LE 安全架构的兼容性。

典型的接口包括“LE 读取加密密钥调度调试模式”和“LE 写入加密密钥调度调试模式”命令。这些命令主要用于开发、测试和互操作性验证环境，适用于后续连接，而非修改活动加密会话的安全状态。

其他 HCI 增强功能可提供对 MIC 长度选择、EKS 使用情况以及加密刷新流程的可视化支持。通过LE Enable Encryption [v2]和Refresh Encryption Key [v2] 等命令，以及Encryption Change [v3]和Encryption Key Refresh Complete [v2] 等事件，主机可以监控与 HDT 操作相关的安全状态转换。

这些接口可确保应用程序随时掌握安全状态和配置变更情况，而无需直接参与底层的链路层 安全流程。与其他HDT功能一样，控制器继续管理对时效性要求较高的安全操作，而主机则能够持续掌握这些操作的结果和运行状态。

3.2.5.5 等时传输管理

蓝牙® HDT 扩展了蓝牙低功耗（Bluetooth LE）等时通信功能，因此需要相应的 HCI 支持，以支持连接等时组（CIG）、连接等时流（CIS）和广播等时流（BIS）。相关的 HCI 接口允许主机在保持既定的蓝牙低功耗等时管理模型的同时，配置支持 HDT 的传输层。

这些接口支持 HDT 特定的操作偏好设置，包括 HDT 速率、数据包格式选择、有效载荷能力以及 MIC 长度配置。通过这些机制，应用程序可以在保持与现有蓝牙低功耗（Bluetooth LE）流程兼容的同时，使传输行为符合吞吐量、延迟、可靠性和安全性要求。典型的配置接口包括LE Set CIG Parameters [v2]和LE Create BIG [v2]。

一旦传输建立流程完成，控制器将通过增强的状态事件报告由此产生的运行特性。诸如“LE CIS Established [v3] ”和“LE Create BIG Complete [v2]”等接口可提供对支持 HDT 的传输建立过程的可视性，并允许主机验证配置结果，并据此调整应用程序的行为。

通过扩展现有的等时管理机制，而非引入全新的控制模型，HDT 使应用程序能够利用显著更高的吞吐量，同时保留蓝牙开发人员已经熟悉的运行框架。

3.2.5.6 测试与诊断

除了运行控制功能外，蓝牙® HDT 还引入了 HCI 功能，旨在支持验证、性能测量、互操作性分析以及实施调试。这些功能可直观展示 HDT 特有的运行特性，并简化了在不同无线电条件和流量模式下对控制器性能的评估。

测试和诊断接口允许对控制器进行配置，使其采用针对 HDT 的特定测试参数，并为收集到的测量数据提供报告机制，其中包括与 HDT 链路质量和物理层（PHY）运行相关的信息。这些功能支持产品开发、认证测试、性能表征以及不同实现之间的互操作性验证。

与该功能相关的典型接口包括“LE 设置 HDT 参数测试”命令和“LE 测试报告 HDT 链路质量”事件。这些机制共同为开发人员和测试工程师提供了评估和优化 HDT 实现所需的信息。

3.2.5.7 典型的蓝牙® HDT HCI 命令和事件

上述 HCI 增强功能是通过新命令、扩展命令以及事件的组合来实现的。表 3.2.5.7 总结了与每个 HDT 功能领域相关的典型接口，并说明了主机如何与支持 HDT 的控制器进行交互。

能力	典型命令和事件
功能发现与配置	LE 设置 HDT 默认参数，LE 读取最大数据长度
PHY的选择与过渡协调	LE 设置 PHY，LE PHY 更新完成
数据长度和吞吐量管理	LE 数据长度设置、LE 数据长度变更
安全与加密管理	LE 启用加密 [v2]、刷新加密密钥 [v2]、加密更改 [v3]、加密密钥刷新完成 [v2]、LE 读/写加密密钥计划调试模式
等时传输管理	LE 设置 CIG 参数 [v2]、LE 创建 BIG [v2]、LE CIS 建立 [v3]、LE 创建 BIG 完成 [v2]
测试与诊断	LE 设置 HDT 参数测试，LE 测试报告 HDT 链路质量事件

这些命令和事件共同构成了主机与控制器之间用于 HDT 操作的主要管理接口。它们使应用程序能够发现控制器功能、配置运行偏好、监控系统状态以及管理支持 HDT 的传输，同时保持主机策略与控制器执行之间既定的架构分离。

3.2.6 蓝牙® HDT 安全

蓝牙 HDT 在现有的蓝牙® LE 安全架构基础上，引入了多项旨在支持高吞吐量通信的增强功能。这些增强功能强化了密钥管理，提升了完整性保护，并使安全流程与物理层（PHY）操作之间实现了更紧密的协调。

HDT 并未定义一套独立的安全架构，而是通过引入加密密钥调度（EKS）、支持更长的消息完整性检查（MIC）长度，以及与物理层（PHY）操作协调的安全流程，对现有的蓝牙低功耗（Bluetooth LE）安全机制进行了扩展。这些增强功能共同为 HDT 提供了所需的安全能力，同时基于的机制也可被其他蓝牙功能和用例所利用。

3.2.6.1 增强的消息完整性保护

传统的蓝牙®低功耗（Bluetooth® LE）通信采用 32 位消息完整性检查（MIC）。HDT 还支持 64 位和 128 位 MIC 长度，在传输大量数据时，能提供更强的保护，防止数据包被篡改、伪造以及传输错误。

3.2.6.2 具有安全意识的物理层（PHY）状态转换

蓝牙® HDT 通过“物理层更新”和“加密刷新”流程，将安全管理与物理层操作更紧密地整合在一起。该流程不再将物理层状态转换和加密更新视为独立的操作，而是允许设备在必要时协调物理层变更与相关的安全更新。

这种协调一致的方法使设备能够在GFSK和HDT工作模式之间切换，同时保持通信安全并最大限度地减少运行中断。通过同步物理层（PHY）和安全状态管理，设备能够适应不断变化的运行要求，而无需重新建立连接或中断上层服务。

MIC 长度的变更需要进行相应的密钥刷新，以确保安全状态与所选的保护级别保持一致。同时，密钥刷新操作可独立于 PHY 状态转换而进行，在保持强安全保护的同时提供了灵活性。

该流程通过LL_PHY_REQ、LL_PHY_RSP 和LL_PHY_UPDATE_IND 的增强版本来支持，这些版本提供了协调物理层操作和安全状态管理所需的信令。

3.2.6.3 安全架构兼容性

通过扩展现有蓝牙® LE 安全机制而非取代它们，蓝牙® HDT 使制造商能够在保持与更广泛的蓝牙生态系统互操作性的同时，采用增强的安全功能。这种方法简化了采用过程，并使产品能够利用 HDT 的功能，而无需采用根本不同的安全模型。

3.3 小结

蓝牙®高数据吞吐量（HDT）通过新增的高效物理层扩展了蓝牙®低功耗（LE）技术，该物理层能够支持高达 7.5 Mb/s 的比特率，同时仍与现有的蓝牙架构完全集成。通过对物理层（PHY）、数据包架构、链路层 、HCI 以及安全框架的增强，HDT 在显著提升吞吐量的同时，保留了蓝牙 LE 的互操作性、效率和部署灵活性。

这些增强功能共同为未来需要大幅提升数据传输能力的蓝牙应用奠定了可扩展的基础，包括下一代音频系统、可穿戴设备、工业解决方案以及其他新兴应用场景。HDT 展示了蓝牙低功耗（Bluetooth LE）如何在保持与现有蓝牙生态系统兼容的同时，持续演进以满足日益增长的带宽需求。

4. 蓝牙®低功耗等时参数 更新（IPU）

4.1 背景

4.1.1 静态 CIS 配置及其限制

蓝牙® LE Audio 引入了“连接等时流”（CIS），作为对时间敏感型应用的传输机制。 在建立 CIS 过程中，设备之间会协商物理层（PHY）选择、ISO_Interval、突发数（BN）、刷新超时（FT）、最大 SDU 大小（Max_SDU）以及传输时延等传输参数，这些参数在流的整个生命周期内保持不变。该模型简化了调度过程，并为等时通信提供了可预测的时序行为。

然而，在实际部署中，数据流处于活动状态时，运行条件往往会发生变化。由于干扰、移动性或环境变化，无线电质量可能会波动；此外，应用程序可能会在具有不同延迟、可靠性、吞吐量或功耗要求的运行模式之间切换。因此，仅靠单一的静态 CIS 配置，并不总能有效优化传输行为。

在蓝牙®低功耗（Bluetooth® LE）等时参数 更新（IPU）推出之前，要适应这些不断变化的要求，通常需要终止现有的CIS，并使用更新后的参数建立新的数据流。尽管这种方法在功能上有效，但可能会导致服务中断，需要进行额外的系统重新配置，并使不同运行模式之间的无缝切换变得复杂。

4.1.2 运行时自适应简介

蓝牙®低功耗（Bluetooth® LE）等时参数 更新（IPU）通过允许在CIS保持活动状态时更新传输参数，解决了这些限制。IPU不再将CIS配置视为一次性设置决策，而是允许设备在流的生命周期内在线路配置之间进行切换。

该功能使蓝牙®系统能够根据不断变化的无线电环境、应用需求和运行模式调整传输行为，而无需重新建立数据流。通过支持协调的运行时配置转换，IPU 在提高灵活性的同时，还保持了等时应用所需的连续性和同步特性。

以下各节介绍了支撑这一新型传输适配模型的设计理念、配置架构和运行时机制。

4.2 蓝牙® IPU 设计理念

4.2.1 从静态流到运行时配置管理

传统上，在建立连接后，连接等时流（CIS）的传输参数保持不变。因此，当运行需求发生显著变化时，要调整传输参数，可能需要终止当前的CIS，并建立一个具有不同参数的新CIS。虽然这种方法能够提供所需的传输特性，但可能会导致服务中断并增加系统重新配置的工作量。

IPU 提出了一种替代模型，在该模型中，无需替换数据流即可更新活动 CIS 的传输参数。当无线电条件、应用需求或系统策略发生变化时，设备可以在 CIS 保持活动状态的同时，选择一个合适的预定义配置并执行协调更新。这将传输自适应与数据流建立分离，使设备能够响应不断变化的需求，而无需重新建立数据流。

图 4.2.1 对比了流重建与 IPU 启用的运行时更新模型。

4.2.2 以配置为中心的适应模型

Bluetooth® IPU 通过一组预定义的 CIG 配置支持运行时自适应。每种配置代表 CIG 内各 CIS 的一个定义好的工作点，并包含该工作点所需的传输参数。实现方案可配置多种配置，以满足不同的应用需求、无线电条件或系统策略。

在运行过程中，会选择其中一种配置来定义活动CIS的传输行为。当条件发生变化时，可通过IPU程序选择并应用另一种配置。因此，这些配置代表了可用的传输工作点，而活动CIS则始终是应用所选配置的持久传输。

图 4.2.2 说明了运行时驱动程序、预定义配置、所选配置以及活动 CIS 之间的关系。

4.2.3 设计多个工作点

为 CIG 配置的各项设置可针对不同的传输目标进行设计。例如，一种配置可能侧重于吞吐量，另一种可能侧重于降低传输延迟，还有一种可能在恶劣的无线电环境下提供更高的鲁棒性。合适的配置集取决于产品支持的工作模式和自适应要求。

IPU 并未针对每个参数 或用例分别定义独立的更新流程，而是提供了一种在这些预定义工作点之间进行切换的通用机制。不同配置间存在差异的参数决定了更新所影响的传输方面，而 IPU 流程则负责协调所选配置何时以及如何生效。

以下各节将介绍如何识别和组织这些配置，主机与控制器之间如何划分更新职责，以及参数 的各种变更如何影响CIS的运行。

4.3 蓝牙® IPU 架构与关键概念

4.3.1 为什么存在多种配置

现代蓝牙®设备通常在需要不同传输特性的条件下运行。无线电质量、应用行为、功耗限制或延迟要求方面的变化，可能各自更适合不同的传输工作点。

IPU 不会在条件发生变化时逐一修改各个传输参数，而是将传输行为组织成一组预定义的配置。每种配置代表一个完整的运行点，可被选中并应用到一个处于活动状态的“连接等时流”（CIS）上。

这种方法将更新视为预定义配置之间的转换，而非对单个传输参数的独立修改，从而简化了运行时的适应过程。

表 4.3.1 列举了可能需要采用不同传输配置的运行要求示例，说明了为什么在所有运行条件下，单一的静态 CIS 配置未必是最优的。

运行要求	运输目标示例
音乐播放	更高的吞吐量和音质
语音通信	降低传输延迟
射频性能退化恢复	可靠性提高
功耗受限运行	放射性降低

4.3.2 组织运行时配置

支持多种运行配置意味着需要进行配置管理。IPU 采用分层模型来组织配置，将相关的运行点分组在一起。每个配置通过 Config_ID 进行标识，同时也可以使用 Config_Group_ID 和传输延迟组 (TL_Group) 标识符来组织配置。

从最高层级来看，配置与一个“连接等时组”（CIG）相关联。在 CIG 内部，配置可根据其传输延迟特性组织为 TL_Groups。在 TL_Group 内部，Config_Groups 提供了一种将支持相关传输工作点的配置进行关联的方式。Config_Group 内的各个配置通过其 Config_ID 进行标识。

该架构使设备能够维持多个预定义的工作点，同时为运行时自适应过程中的配置选择提供了一种结构化的机制。在此框架内，既可以管理由主机创建的配置，也可以管理由控制器自主创建的配置。

如图4.3.2所示，IPU引入了一种分层组织模型，其中与延迟相关的分组与个别传输配置相互分离。与其将配置视为互不相关的参数 集合，不如将其视为一个更大配置空间中的成员，该空间定义了CIG的潜在工作模式，这种视角往往更为有用。

4.3.3 为什么传输延迟组很重要

传输延迟是等时传输的一项重要特性，因为传输延迟的变化会影响缓冲行为、呈现时机以及应用层处理要求。

因此，IPU 通过传输延迟组（TL_Groups）来组织配置。同一 TL_Group 内的配置具有相同的传输延迟特性，而与不同 TL_Group 关联的配置则代表不同的传输延迟模型。

该组织在运行时转换过程中至关重要，因为更新过程中有效载荷的处理在一定程度上取决于该转换是保持在同一个 TL_Group 内，还是跨越了 TL_Group 边界。

4.3.4 主机和控制器的职责

并非所有配置变更都具有相同的范围或影响。有些更新仅影响链路层 的运行，而另一些则可能影响传输延迟、缓冲假设或应用层行为。

IPU 通过将主机和控制器的职责区分开来，体现了这一区别。

主机负责应用层适配决策，包括根据应用需求、运行模式、质量目标或系统策略来选择或请求传输配置。控制器负责执行相应的更新程序并协调传输过渡。

这种分离使得IPU能够同时支持应用驱动和控制器驱动的自适应调整。例如，当应用程序切换运行模式时，主机可能会发起配置变更；而控制器则可能根据无线电条件或其他链路层 条件的变化，自主调整传输参数。

如图4.3.4所示，主机决定传输转换应何时发生以及为何发生，而控制器则负责协调和执行该转换。

4.3.5 适应维度

Bluetooth® IPU 的一个显著特征在于，运行时自适应功能并不局限于单一传输协议参数 。不同的配置可能会改变 CIS 行为的各个方面，包括无线电性能、传输频率、可靠性、延迟以及事件调度。

从建筑学的角度来看，这些变化可以通过几个适应维度来理解。

适应目标	参数示例
PHY / 链路自适应	物理层（PHY）、传输速率、重传参数
码率自适应	Max_SDU
日程安排的灵活性	锚点，ISO_Interval
延迟自适应	传输延迟，TL_Group
运行模式适应	与不同应用需求相关的配置变更

如表 4.3.5 所示，IPU 配置可支持针对多个传输目标进行自适应调整。根据所选的工作点不同，配置变更可能会同时影响一个或多个参数。这为调整无线电行为、比特率、调度、时延以及应用程序工作模式提供了一个通用框架。

尽管该规范定义了多种更新场景，但其中大多数可理解为这些适应维度上的变体。这种视角提供了一个有用的框架，有助于理解不同的参数 变更如何影响CIS的运行，而无需逐一考察每种可能的更新组合。

以下各节将介绍IPU如何在保持同步和维持有效载荷连续性的同时，协调这些维度之间的过渡。

4.4 配置生命周期与运行时协调

4.4.1 配置生命周期

Bluetooth® IPU 引入的一个关键概念是将配置定义与配置激活分离。配置不再仅在建立 CIS 时才创建，而是可以独立于活动传输进行定义、配置和维护。

每个已配置的配置都代表一个“连接等时组”（CIG）的完整传输工作点。一个配置可定义物理层（PHY）选择、ISO时序特性、调度行为、重传参数、传输时延特性以及相关的同步信息。配置通过唯一的Config_ID值进行标识，并可在建立CIS之前进行配置。

为了同时支持由主机管理和由控制器管理的配置分配，Config_ID 值被划分为不同的分配范围。配置定义与运行时更新流程相互独立。配置可以预先定义和分配，因此当需要更改工作点时，更新流程可以激活现有配置，而非在过渡过程中定义新配置。 0x01 至 0x7F 范围内的 Config_ID 值由主机分配，而 0x80 至 0xFF 范围内的值可由控制器自主分配。这种分离既可避免冲突，又能同时支持应用驱动和控制器驱动的自适应模型。

配置一旦完成配置，即可供运行时选择，并在后续运营需求发生变化时予以激活。由于配置定义与流的创建是解耦的，因此多个配置可以在一个 CIG 内共存，并在流的整个生命周期内始终可用。

配置管理与流建立之间的这种分离是IPU的一项基本架构特征。与早期的CIS实现不同——在那些实现中，一旦流建立完成，传输参数实际上就固定下来了——IPU允许通过在预定义的工作点之间进行选择，使传输行为得以演进。

因此，传输适配便成为一个配置选择和激活的过程，而非配置创建的过程，这使得CIS能够在无需重新建立的情况下适应不断变化的需求。

4.4.2 协调运行时配置更新

尽管配置更改最终会影响各个CIS的传输参数，但更新操作是在CIG级别进行协调的。这使得属于同一CIG的多个CIS能够协调一致地完成过渡，并在整个更新过程中保持同步。

当设备判断出另一种传输工作点更适合当前运行条件时，运行时自适应便开始启动。配置变更的动因可能源于应用工作模式的切换、无线电环境的变化、延迟要求、可靠性目标，或是系统级自适应策略。

确定目标配置不会立即修改当前活动的CIS。在新配置生效之前，两台设备必须通过蓝牙® IPU更新程序协调过渡过程。

这种协调机制确保参与设备在激活更新之前，就目标配置及其相关的传输特性达成一致。通过将配置选择与激活分离，IPU 使得适应性决策能够独立于安全传输过渡所需的时序约束而进行。

在最常见的部署模型中，中央节点选择目标配置并启动 CIS 更新流程。IPU 还支持由外设发起的更新请求，允许外设指示可能需要采用不同的传输工作点，同时仍由中央节点负责做出最终的更新决策。

无论启动器 如何，更新均遵循相同的协调模型，并最终在同步的更新边界处生效。在此过程中，CIS始终保持建立状态并可供持续运行。这使得传输行为能够随着运行要求的变化而演进，而无需每次都终止并重新建立数据流。

4.4.3 基于Instant的激活与同步

配置更新在请求后不会立即生效。相反，新配置将在一个预先定义的激活点（称为“Instant”）生效。

“Instant” 提供了一个通用的同步边界，使两台设备能够同时过渡到更新后的配置。如果没有协调激活，一台设备可能会在另一台设备尚未准备就绪之前就开始使用更新的传输参数进行操作，这可能会导致调度不一致、有效载荷错位或暂时失去同步。

因此，在应用过渡之前，更新流程会首先就目标配置及其激活时间达成一致。两台设备将继续使用当前配置运行，直到达到商定的时刻，届时所选配置将生效。

当更新通过调整锚点偏移量影响 CIS 时序定位时，同样采用基于“瞬时”的方法。在这些情况下，更新不仅会修改传输特性，还会改变未来 CIS 事件的时序位置。通过在预定义的“瞬时”安排该变更，两个控制器都能对更新后的事件时间线保持一致的视图。

锚点调整也可在不更改当前 Config_ID 的情况下进行。在这种情况下，更新会调整未来 CIS 事件的放置位置，同时保持底层传输配置不变。这使得调度优化和时序重新对齐能够独立于任何传输参数 过渡而进行。

通过将配置激活与一个通用的CIS事件边界关联起来，蓝牙® IPU可确保两个控制器以确定性方式过渡到新的时序模型，无论正在更新的传输参数为何。无论该变更是否影响吞吐量、重传行为、传输延迟或未来事件的定位，均适用相同的同步原理。

虽然达到“Instant”状态即完成了配置激活过程，但仍需采用额外的机制来确保在过渡过程中有效载荷的连续性和时序的一致性。当更新的配置影响到传输时序、延迟特性、调度行为或有效载荷传输时，这些机制就显得尤为重要。

4.5 在配置过渡期间保持连续性

4.5.1 运行时转换与连续性

在更新时刻激活新配置并不一定意味着与先前配置相关的所有传输活动都已完成。根据正在更新的参数不同，与先前配置相关的数据包在更新时刻之后仍可能处于传输过程中。

因此，蓝牙® IPU 提供了在配置转换过程中协调有效载荷处理的机制。转换有效载荷和刷新点使控制器能够保持同步，并确定何时可以释放与先前配置相关的传输状态。激活新配置只是 IPU 更新过程中的一个步骤。

4.5.2 过渡期间的有效载荷管理

当与先前配置相关联的有效载荷仍在处理过程中时，可能会发生 CIS 更新。Bluetooth® IPU 定义了“过渡有效载荷”和“过渡后有效载荷”，用于管理更新瞬间期间的有效载荷处理。

过渡有效载荷与“更新时刻”之前的CIS参考锚点相关联。对其的处理取决于更新的特性，以及该更新是否更改了传输延迟组或缩小了最大数据包有效载荷大小。

当更新更改了 TL_Group_ID 或降低了 Max_Packet_Payload 时，过渡有效载荷将在更新瞬间被清空。这可确保与先前传输配置相关联的有效载荷不会在过渡后继续使用已不再适用的传输模型。

对于其他更新场景，清空点（Flush Point）将根据适用的CIS更新规则确定。这使得过渡有效载荷（Transition Payloads）能够在更新瞬间（Update Instant）期间继续处理，同时保持SDU的同步。

过渡后有效载荷使用“更新时刻”作为其CIS参考锚点。当ISO_Interval缩短时，对这些有效载荷的处理尤为重要，因为与新配置相关联的有效载荷可能需要根据更新后的事件时间进行调度。

这些机制共同作用，使 IPU 能够在保持同步的同时在不同配置之间切换，并妥善管理与“更新时刻”双方相关的数据负载。

4.6 协议扩展

4.6.1 主机控制器接口扩展

尽管蓝牙® IPU 引入了重要的新运行时功能，但由此带来的协议变更相对较少。新增功能的大部分都集中在少数几个 HCI 命令和事件中，这些命令和事件支持配置管理和运行时更新。

在主机控制器接口（HCI）层，新命令允许主机定义 CIG 配置、删除先前定义的配置、发起配置更新，并参与更新决策。相应的 HCI 事件允许控制器报告更新完成情况，并传达来自外设侧的更新请求。

表 4.6.1 总结了 IPU 引入的主要 HCI 新增功能。

机制	目的
LE 添加 CIG 配置	定义一个额外的运行时配置
LE 删除 CIG 配置	删除先前定义的配置
LE 更新 CIG	启动配置转换
LE 更新 CIG 外设请求回复	响应来自外设的更新请求
LE CIS 更新活动	将更新完成情况通知主机
LE 更新 CIG 外设请求事件	向主机通知外设更新请求

这些命令和事件共同使主机能够在 CIG 的整个生命周期内管理多个传输工作点，而不仅仅是在流建立期间。

4.6.2链路层 扩展

在链路层 中，蓝牙® IPU引入了新的控制流程，支持配置定义、配置删除、由中央设备发起的更新以及由外设发起的更新请求。这些流程提供了在活动CIS保持建立状态期间，协调传输适配所需的信令框架。

IPU 引入的链路层 主要新增功能汇总如表 4.6.2 所示。

机制	目的
LL_CIG_CONFIG_REQ / RSP	创建配置定义
LL_CIG_CONFIG_REMOVE_IND	删除配置定义
LL_CIS_UPDATE_REQ / RSP简体中文（大陆）	执行配置更新
LL_CIS_PERIPHERAL_UPDATE_REQ	从外设端请求更新

这些流程通过允许配置状态在运行期间发生变化，将CIS的生命周期延伸至创建和终止之后。结合前几节所述的激活和连续性机制，它们构成了运行时传输适配的协议基础。

尽管更新会应用到CIS的传输行为上，但更新的执行是在CIG级别进行协调的，以确保属于同一CIG的多个CIS在整个过渡过程中保持同步。

4.7 具有代表性的更新情景

前几节介绍了蓝牙® IPU 如何通过配置分发、协调激活和连续性管理来实现运行时传输适配。本节将说明这些功能如何应用于系统的不同层。

这些示例是特意选取的，旨在体现三种常见的适应触发因素：

• 无线电状况的变化
• 运输要求的变化
• 应用程序行为的变化

这些内容共同展示了CIS如何在运行过程中演进，而无需重新建立数据流。

4.7.1 动态射频自适应

蓝牙® IPU 的主要动机之一，在于能够根据无线电环境的变化调整传输特性。

图 4.7.1 展示了一个示例，其中在同一个 CIG 内配置了多个配置。一种配置可能在无线电条件良好时优先考虑传输效率，而另一种配置则可能在数据包丢失率开始上升时提供更高的鲁棒性。

在运行过程中，控制器会监控数据包误码率（PER）等无线电质量指标，并判断何时需要切换至不同的工作点。一旦确定了目标 Config_ID，主机将使用LE Update CIG命令发起切换。随后，各控制器通过CIS Update 流程协调更新工作，并在约定的时刻激活新配置。

当后续信道状况恶化时，可采用相同的操作流程切换回更具弹性的配置。从应用程序的角度来看，音频流在整个过程中始终保持活动状态，仅底层的传输配置发生变化。

此示例说明了在CIS保持活动状态时，IPU如何根据不断变化的无线电条件调整传输配置。

相同的适配框架同样适用于 LE 1M、LE 2M 和 LE 编码物理层（PHY），以及 LE 高数据吞吐量（HDT）等较新的传输技术。 例如，可以针对不同的 HDT 速率集定义配置，使每种配置都能使用合适的子时段。较低速率的配置可支持 HDT2、HDT3 和 HDT4，而较高速率的配置则可支持 HDT6 和 HDT7.5。将这些工作点区分开来，可以在可用空闲时间内为重传机会的调度提供更大的灵活性。

这使得IPU能够在引入新的传输功能时，提供一个通用的配置和更新框架。

4.7.2 自适应比特率

蓝牙® IPU 还支持自适应比特率，允许为同一 CIS 配置多个具有不同最大 SDU 大小（Max_SDU）的设置。由于 Max_SDU 直接影响每个 SDU 间隔内传输的应用数据量，因此不同的配置可对应不同的比特率工作点。

例如，设备可能定义多种配置，这些配置对应于不同的音质级别。在链路条件良好时，系统可能会选择一个 Max_SDU 较大的配置，以支持更高比特率的音频传输。当链路条件变差时，系统可能会切换到一个 Max_SDU 较小的配置，在保持活动 CIS 的同时降低传输比特率。

图4.7.2展示了一个示例，其中预先配置了多个具有不同Max_SDU值的配置。随着运行条件的变化，IPU使活动CIS能够在这些配置之间进行切换，从而实现比特率自适应，而无需重新建立数据流。

这种方法可以在确保服务连续性的同时，使音质和传输容量动态调整，并在整个过渡过程中保持CIS连接处于活动状态。

4.7.3 音频模式切换

虽然前面的示例主要由传输条件驱动，但有些更新源于应用程序行为的变化。

LE Audio 设备通常在多种应用模式下运行。音乐播放、语音通信、助听应用以及交互式音频服务可能会优先考虑不同的传输特性，包括延迟、比特率和可靠性。

蓝牙® IPU 允许预先配置针对这些不同工作模式的优化设置，并在 CIS 保持活动状态时激活这些设置。例如，当发起语音通话时，设备可从以音乐为主的配置切换为以语音为主的配置。主机识别出适合新工作模式的配置，并通过主机控制器接口发起更新。随后，各控制器通过 CIS 更新程序协调该切换过程，并在约定的时刻激活新配置。

当通话结束、音乐播放恢复时，也可以采用相同的方法进行反向过渡。由于所需的配置可以预先定义，因此该过渡可以在无需重新建立CIS的情况下改变传输特性。

4.7.4 共存与调度灵活性

蓝牙® IPU 还能提供灵活的调度能力，以支持与其他无线流量的共存，并与其他蓝牙®等时流进行同步。

例如，IPU 更新可以调整 CIS 的锚点，从而改变 CIS 与广播等时流（BIS）（例如 Auracast® 流）之间的时序关系。这可以使 CIS 的时序与其他等时活动更有效地对齐。

IPU 还可以调整 ISO_Interval 参数，以增加 CIS 事件之间的间隔。这些间隔可以为其他无线流量（包括较大的 Wi-Fi 数据包）提供额外的空闲时间，从而改善蓝牙®与其他无线技术之间的共存性。

这些调度变更可通过与其他 IPU 配置变更相同的协调更新机制进行应用，从而在 CIS 保持活动状态的同时，使时序行为得以演进。

4.8 总结

蓝牙®低功耗（Bluetooth® LE）等时参数 更新（IPU）将“连接的等时流”（CIS）的适用范围扩展到了固定传输模型之外，并引入了在CIS保持活动状态时演进传输行为的能力。

IPU 并未将传输参数视为建立数据流时的一次性结果，而是引入了一个以配置为中心的框架，在该框架中，可以在 CIG 的整个生命周期内配置、选择和激活多个工作点。

运行时更新通过基于Instant的激活机制进行协调，使两台设备都能在共同的同步边界处过渡到新的配置。其他连续性机制（包括过渡有效载荷处理和刷新点协调）可在传输状态演变过程中确保有效载荷处理的连续性。

为了支持这些功能，IPU引入了一组紧凑的“主机控制器接口”（Host Controller Interface）和“通用指令集”（链路层 ）扩展，从而实现了配置管理、运行时自适应以及协调的更新执行。

这些机制共同将传输自适应从流建立操作转变为运行时能力。IPU 可在保持活动 CIS 的同时，支持对不断变化的无线电条件、自适应比特率、应用模式转换以及调度或共存要求的自适应调整。通过提供一种用于定义和激活替代配置的通用机制，IPU 使传输行为能够演进，而无需重新建立流。

5. 蓝牙®加密密钥表（EKS）

5.1 背景

5.1.1 蓝牙® LE 加密技术的演变

蓝牙®低功耗（Bluetooth® LE）通常通过“带分选器的加密启动”流程建立加密连接。在此模型中，设备在推导蓝牙链路层 加密所用的会话密钥之前，会先交换初始化向量和会话密钥分选器。这种方法为广泛应用场景中的蓝牙低功耗通信提供了安全且兼容的基础。

随着蓝牙技术向更高性能的传输层和更先进的安全架构发展，在建立、管理和更新加密素材方面需要更大的灵活性。特别是，人们越来越需要实现传输层之间更强的加密隔离、支持不断演进的加密上下文，以及更灵活的密钥生命周期管理。

为满足这些要求，蓝牙引入了加密密钥调度（EKS）——这是一个将基于ECDH的密钥建立与分层密钥派生及集成密钥刷新功能相结合的新框架。

5.1.2 为何需要新的密钥管理框架

传统的蓝牙®低功耗（Bluetooth® LE）加密机制直接从长期密钥（LTK）和交换的会话参数中派生会话密钥。虽然这种模式很有效，但在连接建立后，它在管理加密材料方面提供的灵活性有限。

Bluetooth® EKS 采用了一种不同的方法。EKS 并非直接从单一密钥源推导出加密材料，而是建立了一个由多个输入构成的加密基础，随后通过结构化的分层体系推导出会话加密材料。这种将密钥建立、传输特定密钥推导以及后续密钥更新相互分离的做法，为 Bluetooth LE 加密材料提供了更灵活的生命周期。

5.2 技术概述

蓝牙®加密密钥调度机制为蓝牙®低功耗（LE）加密素材确立了结构化的生命周期。该机制首先为连接建立加密基础，随后利用分层派生框架生成针对特定传输层的加密素材。由于加密基础的建立与会话密钥的生成是分离的，因此该架构也可支持其他工作模式及后续的密钥更新，包括机会加密和连接内密钥刷新。

5.2.1 建立加密基础

蓝牙® EKS 的第一阶段建立了后续密钥派生过程所使用的加密基础。

传统的蓝牙®低功耗（Bluetooth® LE）加密采用“带分隔符的加密启动”流程。在此过程中，主设备（Central）和从设备（Peripheral）通过 LL_ENC_REQ 和 LL_ENC_RSP PDU 交换会话密钥分隔符（SKD）和初始化向量（IV）的值。这些交换的值与长期密钥（LTK）结合，生成用于蓝牙®低功耗加密（链路层 ）的会话密钥。

EKS 引入了一种不同的方法。设备不再交换 SKD 和 IV 值，而是使用 LL_ENC_ECDH_REQ 和 LL_ENC_ECDH_RSP PDU 交换 ECDH 公钥、随机值以及与加密相关的参数。这些消息包含：

• ECDH 公钥（PubKey_C 和 PubKey_P）
• 随机值（Rand_C 和 Rand_P）
• 加密标志（Flags_C 和 Flags_P）
• 公钥类型信息
• 与MIC相关的操作偏好

两台设备利用交换的公钥，基于蓝牙 P-256 椭圆曲线，各自独立地计算出相同的 ECDH 共享密钥。

如图5.2.1所示，“基于密钥调度方案的加密启动”流程不仅建立了加密连接。除了生成ECDH共享密钥外，该流程还会交换控制信息，这些信息随后将成为EKS派生过程的一部分。这些交换的数据随后会被纳入EKS密钥层次结构中。

ECDH 共享密钥不会直接用作会话密钥。相反，该流程会建立初始化 EKS 密钥层次结构所需的加密输入和协商上下文。一旦推导出必要的加密材料，设备便会使用 LL_START_ENC_REQ 和 LL_START_ENC_RSP 完成现有的三向加密握手。

因此，通过图5.2.1所示流程建立的ECDH共享密钥和连接上下文，便成为下一节所述基于CMAC的密钥层次结构的输入。

5.2.2 构建蓝牙® EKS 密钥层次结构

在建立加密基础后，EKS 会使用基于 CMAC 的密钥派生框架，将“加密开始与密钥调度”过程中交换的信息转换为蓝牙® LE链路层 加密所使用的加密素材。图 5.2.2 展示了用于执行此转换的密钥层次结构。

如图5.2.2所示，EKS通过结构化的分层体系来推导和管理加密材料，而不是直接从长期密钥生成会话密钥。k2、ee12、kv12 和k3等标签代表基于 CMAC 的派生函数，这些函数应用于该层次结构的不同阶段。图中的矩形代表加密函数，圆角框代表加密值，阴影框代表 EKS 生命周期中的事件。

图 5.2.2 中所示函数和标签的详细定义，可参见《蓝牙® 核心规范》第 6 卷 E 部分第 4 节。因此，本概述侧重于该层次结构的目的以及由此产生的加密材料的作用，而非每个导出函数的数学运算。

《蓝牙®核心规范》，第6卷，E部分，第4节，图4.1。

为了初始化该层次结构，EKS 将与“加密开始与密钥调度”过程相关的若干加密输入结合起来：

• ECDH 共享密钥：由两台设备根据在 LL_ENC_ECDH_REQ 和 LL_ENC_ECDH_RSP 中交换的公钥独立计算得出
• 长期密钥：当存在现有的蓝牙安全连接时，由主机提供
• AA：ACL连接的访问地址
• HPA：若存在ACL连接，则为该连接的HDT数据包地址；否则，为单字节值0x00
• PDU_C：由中央站传输的 LL_ENC_ECDH_REQ PDU 的 CtrData 字段
• PDU_P：外设传输的 LL_ENC_ECDH_RSP PDU 的 CtrData 字段

AA、HPA、PDU_C 和 PDU_P 共同为派生过程提供了特定于连接的上下文。PDU_C 和 PDU_P 包含在加密建立过程中交换的加密标志、随机值、公钥类型和公钥。 《蓝牙®核心规范》还定义了将 PDU_C 和 PDU_P 提供给 AES-CMAC 计算时所采用的字节序，以确保两个控制器构建的派生输入完全一致。

通过结合 ECDH 共享密钥、适用的 LTK 以及特定于连接的上下文信息，EKS 将生成的加密素材与 ACL 连接和 EKS 协商绑定在一起。因此，EKS 不仅将 ECDH 结果转换为会话密钥，还通过结构化的派生过程，将新生成的 ECDH 派生素材、可用的现有蓝牙凭证以及当前连接的上下文信息结合在一起。

该过程生成的第一个中间值是“派生密钥”（Derived Secret），它构成了EKS层次结构中不断演进的根节点。派生密钥用于生成一个或多个“流量密钥”（Traffic Secrets），而每个流量密钥随后又用于生成AES-CCM加密所需的会话密钥和初始化向量。

这种分层结构将连接级别的加密基础与各个传输所使用的加密材料区分开来。如下节所述，它使 EKS 能够为 ACL 连接及其关联的 CIS 传输创建独立的加密上下文，同时为后续的密钥刷新操作奠定基础。

5.2.3 管理ACL和CIS加密材料

图5.2.2中介绍的分层结构使蓝牙® EKS能够在保持共同加密基础的同时，针对不同的传输类型独立管理加密素材。EKS并非为连接相关的所有流量生成单一的会话密钥，而是利用“流量密钥”（Traffic Secrets）来创建针对特定传输类型的加密上下文。

建立 ACL 加密连接后，EKS 会根据与该连接关联的“派生密钥”生成一个“ACL 流量密钥”。随后，该“ACL 流量密钥”将用于派生 AES-CCM 所使用的会话密钥和初始化向量 (IV)，以保护加密 ACL 连接上的流量。该“派生密钥”和“ACL 流量密钥”仅保存在控制器内部，不会暴露在 EKS 框架之外。

当创建一个新的连接等时流（CIS）时，EKS 会通过为新的传输生成额外的加密材料来扩展层次结构。两台设备利用当前的派生密钥，结合相应的 CIG_ID 和 CIS_ID 值，共同生成一个新的派生密钥以及与该流相关的初始CIS 流量密钥。随后，CIS 会话密钥和初始化向量将从该 CIS 流量密钥中派生出来。

因此，应将图5.2.2视为一个分支层次结构，而非单一的线性链。ACL连接维护着自己的ACL流量密钥和相应的会话密钥，而每个关联的CIS则维护着独立的CIS流量密钥和会话密钥。创建新的CIS也会使该层次结构所使用的派生密钥递增。

这种针对传输层的分支机制是 EKS 引入“派生密钥”（Derived Secret）和“流量密钥”（Traffic Secret）层的主要原因之一。通过为 ACL 和 CIS 传输分别维护独立的流量密钥，EKS 在保持共同的连接级信任基础的同时，实现了通信流之间的加密隔离。因此，即使多个传输上下文源自同一 EKS 层次结构，它们也能在不共享相同会话密钥的情况下共存。

5.2.4 机会加密

上一节中描述的传输特定加密上下文，无论加密基础是如何建立的，均通过蓝牙® EKS 层次结构进行创建和管理。在最常见的情况下，EKS 使用主机提供的长期密钥 (LTK) 进行初始化。然而，即使不存在先前建立的蓝牙安全关系，该架构同样可以运行。这种运行模式被称为“机会加密”。

机会加密允许两台设备在无需事先配对或建立绑定关系的情况下建立加密通信。设备不再依赖已绑定的长期密钥（LTK），而是使用在“带密钥调度功能的加密启动”过程中建立的ECDH共享密钥，并结合《蓝牙®核心规范》中定义的固定全零LTK值。

主设备通过 LL_ENC_ECDH_REQ 中的相应标志请求机会性加密。仅当“机会性加密主机支持”功能可用时，从设备才会接受此模式。否则，从设备将以“加密模式不可接受”错误拒绝该请求。

与传统 EKS 操作（其使用由主机提供的 LTK）不同，机会加密使用全零的 LTK 值。除这一区别外，创建和维护连接的加密材料所采用的建立、导出和密钥管理流程均与传统 EKS 操作相同。

通过允许在无需事先配对或建立绑定关系的情况下进行加密通信，机会性加密扩展了蓝牙®低功耗（Bluetooth® LE）加密的适用场景范围。然而，由于不存在预先建立的蓝牙信任关系，机会性加密无法提供中间人攻击防护。《蓝牙®核心规范》指出，其机密性和完整性特性与采用“LE安全连接即用”（LE Secure Connections Just Works）关联模型进行配对的设备相当。

5.2.5 更新加密材料

前几节所述的传输特定加密上下文是基于 EKS 层次结构维护的“流量密钥”构建的。由于前一节所述的访问控制列表 (ACL) 和 CIS 会话密钥是从“流量密钥”派生而来，而非直接源自原始的加密基础，因此 Bluetooth® EKS 可以在连接生命周期内动态调整加密材料，而无需重建整个层次结构。

EKS 支持两种更新加密素材的方法：重启加密和刷新加密。

重新启动加密

在某些情况下，必须使用新的加密上下文重新建立加密连接。为了支持这一功能，蓝牙® LE 采用了“加密暂停”流程。

在“加密暂停”过程中，加密功能将暂时暂停，并在重新启用加密之前执行一个封装的“加密开始”过程。在暂停期间，数据 PDU 不会以未加密形式传输。

如果最初是使用 EKS 建立连接的，则在重启过程中将采用相同的“使用密钥调度开始加密”程序。该过程实际上重复了第 5.2.1 节中描述的密钥建立阶段，在生成新的会话密钥材料之前，先建立新的加密基础并重建 EKS 层次结构。在此过程中，现有连接将得以保留。在封装式重启过程中，不允许进行机会性加密。

加密刷新

EKS 还支持在不重建整个加密上下文的情况下刷新加密材料。

与重新启动加密不同，刷新操作完全在现有的 EKS 层次结构内进行。两台设备不会重复进行 ECDH 交换并重建加密基础，而是更新现有的 ACL 流量密钥，并根据更新后的值推导出新的会话密钥和初始化向量。原始的 ECDH 共享密钥、派生密钥以及特定于连接的上下文保持不变。

刷新ACL会话密钥不会重置数据包计数器或有效载荷编号。如果在密钥变更前已传输某个有效载荷，且在密钥变更后必须重传该有效载荷，则该有效载荷将被重新加密，并使用新的会话密钥重新计算其MIC。

尽管“重启”和“刷新”最终都会生成新的会话密钥，但它们在 EKS 层次结构中的操作层级不同。重启加密是通过新的“加密启动”流程重建加密上下文，而刷新加密则是通过更新 ACL 流量密钥，并根据该更新值推导出新的会话密钥，从而演进现有的加密上下文。实际上，刷新操作允许引入新的会话密钥，而无需重复最初建立连接时进行的 ECDH 密钥交换。

这一区别体现了将“流量秘密”（Traffic Secrets）引入 EKS 架构的主要优势之一：加密材料可以独立于原始密钥建立过程而演进。

5.2.6 MIC的选择与HDT的操作

除了建立和管理加密密钥外，“使用密钥计划开始加密”过程还会确定如何对连接应用完整性保护。

在“使用密钥调度开始加密”过程中交换的加密标志决定了连接的消息完整性码（MIC）的行为。

在 GFSK 物理层上运行的连接使用 32 位 MIC。对于 LE HDT 物理层操作，当主设备（Central）和从设备（Peripheral）均指示允许使用 64 位 MIC 时，则使用 64 位 MIC；否则，使用 128 位 MIC。

因此，MIC的长度是在EKS加密设置过程中确定的，而不是在加密开始后独立选定的。所选定的MIC行为将成为连接上下文的一部分，并被纳入蓝牙® EKS层次结构中。

LE HDT PHY 上使用的 MIC 长度随后可通过 PHY 更新和加密刷新程序进行修改，从而能够在 EKS 框架内协调 PHY 特性及相关完整性保护参数的变更。

尽管 EKS 最初是与 Bluetooth® HDT 一起推出的，但它被定义为一项独立的控制器功能。因此，应将 HDT 视为 EKS 框架的一种应用，而非其存在的唯一理由。

本节所述的功能，包括分层密钥派生、针对特定传输方式的“流量密钥”（Traffic Secrets）、机会加密、加密重启和密钥刷新，共同构建了一个可重用的安全基础，该基础能够支持 HDT 之外的蓝牙技术。

5.2.7 与使用分流器的加密方法的比较

在探讨了蓝牙® EKS 如何建立、推导和管理加密密钥之后，将该架构与传统的“以分组器开始加密”流程进行比较将大有裨益。这两种方法最终都使用 LL_START_ENC_REQ 和 LL_START_ENC_RSP 握手协议，将连接切换至加密运行模式。主要区别在于握手之前交换的信息，以及由此产生的加密密钥的推导方式及其后续管理方式。

表 5.2.7 总结了传统的“使用分流器开始加密”流程与 EKS 框架之间的主要架构差异。

方面	使用分流器进行加密	EKS
密码学基础	LTK + SKD/IV	ECDH 共享密钥 + LTK + 连接上下文
关键结构	会话密钥	派生密钥 → 流量密钥 → 会话密钥
运输分离	未定义	《ACL与CIS流量秘笈》分册
重要更新	重新启动加密	重新启动或刷新加密
机会主义加密	不支持	已支持

5.3 小结

蓝牙®加密密钥调度机制提供了一个用于建立和管理蓝牙®低功耗（LE）加密密钥的分层框架。它结合了ECDH共享密钥、相应的长期密钥以及特定于连接的上下文信息，从而为ACL和CIS传输生成独立的加密密钥。

EKS 还支持机会性加密、加密重启、连接内密钥刷新以及增强型 MIC 操作。这些功能共同构成了 HDT 所需的安全基础，同时使 EKS 能够保持作为一项独立且可重用的蓝牙功能。

6. 蓝牙® 临时应用密钥（TAK）

6.1 背景

6.1.1 蓝牙安全架构的发展历程

蓝牙长期以来一直提供用于建立信任并保护设备间通信的机制。这些机制围绕以下几个核心安全功能构建：

• 配对，即在设备之间建立共享密钥
• 绑定，即存储这些密钥以备将来使用
• 设备认证，用于验证共享密钥的持有权

• 加密，用于保护传输中数据的机密性
• 消息完整性，用于防止数据被未经授权地篡改

随着时间的推移，蓝牙安全架构已从传统的BR/EDR机制演进为更先进的方法，例如LE安全连接。尽管底层加密技术已得到显著改进，但其运行模式基本保持不变。

在大多数情况下，蓝牙安全机制假设设备通过配对建立信任关系，然后通过绑定维持该信任关系。因此，安全状态在多次连接和交互中得以保持。

该模型非常适用于那些会随时间推移反复进行通信的设备，例如智能手机、可穿戴设备、耳机和输入设备。不过，该模型假设信任关系具有长期性，且值得维持。

6.1.2 瞬态相互作用中带状态配对的局限性

随着蓝牙®低功耗（Bluetooth® LE）向新的应用领域扩展，越来越多的交互正变得短暂且具有事务性，而非持久性。如今，蓝牙已广泛应用于数字钥匙、门禁系统、票务、基于凭证的访问、共享基础设施以及临时设备配置等场景，在这些场景中，设备之间可能仅进行一次交互，或在关系终止前仅在有限时间内进行交互。

在这些情况下，传统的基于配对的安全模型可能会带来不必要的复杂性。配对和绑定旨在在设备之间建立并维持长期的信任关系，从而允许在未来的连接中重复使用密钥和安全机制。然而，当交互是临时性的时，维持持久的安全性可能益处甚微。

这可能会带来若干挑战。短暂的交互仍可能生成长期的绑定信息，从而占用设备上有限的存储资源。此外，信任关系可能已经通过蓝牙协议栈之外的机制建立起来，例如基于云的身份服务、数字凭证、证书或其他特定于应用程序的身份验证系统。因此，仅为了获取加密密钥而进行配对，可能会导致已经完成的身份验证过程被重复执行。

这些趋势反映了系统设计方面更广泛的转变。现代应用程序越来越倾向于将身份管理与传输技术分离，从而使身份验证和信任决策可在应用程序层级处理，而通信技术则专注于保护所交换的数据。

为了支持该模型，蓝牙引入了一种无需配对的安全架构，该架构可在无需配对或建立连接的情况下实现链路层 加密。在此方案中，身份验证和密钥建立由更高层的应用程序完成，而蓝牙则继续为通过无线链路交换的数据提供标准化的传输保护。

这种方法并非要取代现有的基于配对的模型，而是扩展了蓝牙安全架构，以支持那些既不需要也不希望维持长期信任关系的临时性、基于会话的交互。

6.2 技术概述

6.2.1 什么是临时应用程序密钥（TAK）

临时应用密钥（TAK）是由上层应用程序提供的一个128位密钥，用于为蓝牙®低功耗（Bluetooth® LE）连接建立链路层 加密。从功能上讲，它在加密过程中与长期密钥（LTK）的作用相同，但在生成和管理方式上存在根本区别。

传统的蓝牙®低功耗（Bluetooth® LE）安全机制通过由安全管理器协议（SMP）管理的配对流程生成加密密钥。相比之下，TAK是通过由更高层应用程序或规范定义的身份验证和密钥建立过程生成的。蓝牙安全管理器不参与该密钥的生成。

因此，信任建立与传输保护被分离。身份验证由更高层的应用程序负责，而蓝牙在建立共享密钥后，会提供标准的链路层 加密。

TAK 的生命周期是刻意设计为短暂的。TAK 会提供给蓝牙主机，供其在加密启动过程中使用，并在该过程启动后由主机丢弃。不会建立任何配对关系，也不会保留任何长期的蓝牙安全状态。

6.2.2 非配对安全架构

Bluetooth® TAK 为蓝牙低功耗（Bluetooth® LE）引入了一种名为“非配对安全模型”的新安全架构。与依赖配对和绑定来建立信任关系的传统蓝牙安全机制不同，该模型允许在不使用安全管理器的情况下建立加密连接。

在此架构下，高层应用程序会对对等设备进行身份验证并建立共享密钥。随后，生成的TAK将提供给蓝牙主机，并用于启动链路层 加密。蓝牙协议栈的其余部分（包括GAP、ATT、L2CAP和控制器）则继续正常运行。

如图6.2.2所示，负责身份验证的应用程序在蓝牙安全管理器之外运行。该应用程序不参与蓝牙配对流程，而是直接建立信任关系，并向主机提供一个临时应用程序密钥。随后，蓝牙协议栈使用该密钥在连接期间建立并维持链路层 加密。

其关键的架构区别在于，在采用TAK加密的连接中，安全管理器协议（SMP）并不参与其中。配对、密钥生成和绑定步骤均被跳过，从而将信任建立的任务委托给更高层的应用程序，同时蓝牙继续提供链路层 的机密性和完整性保护。因此，在此模型下运行的设备虽然经过加密，但并未进行配对或绑定。

由此形成了一种架构，在该架构中，连接可以在不建立持久信任关系的情况下进行加密。身份验证和密钥建立在蓝牙安全框架之外进行，而现有的蓝牙® LE 加密机制则保持不变。

虽然“非配对”安全模型定义了 TAK 如何集成到蓝牙® LE 架构中，但对该模型的支持是通过引入一种新的蓝牙® LE 安全模式来正式实现的。下一节将介绍安全模式 4 如何扩展现有的蓝牙® LE 安全框架。

6.2.3 LE 安全模式及模式 4 的引入

蓝牙®低功耗（Bluetooth® LE）定义了多种安全模式，以满足不同的通信需求。在蓝牙® TAK 推出之前，蓝牙低功耗支持安全模式 1 来保障点对点低功耗连接的安全，以及安全模式 3 来保障加密广播通信的安全。这两种模式共同为面向连接和基于广播的通信场景提供了保护机制。

非配对安全模型的引入为该框架新增了一种安全模式：LE 安全模式 4。与依赖蓝牙管理的安全流程（如配对或广播密钥分发）的现有安全模式不同，安全模式 4 允许使用由上层应用程序提供的临时应用密钥建立加密连接。

安全模式	安全级别	费用项目
模式 1	第1级	无身份验证且无加密
第2级	带加密功能的未认证配对
第3级	带加密功能的身份验证配对
第4级	经过身份验证的 LE 安全连接，采用 128 位强度加密密钥进行加密配对
模式 3	第1级	无安全措施
第2级	使用未经身份验证的 Broadcast_Code
第3级	经过身份验证的 Broadcast_Code 的使用
模式 4（新）	第2级	使用临时应用程序密钥 (TAK) 建立加密的临时连接

如表 6.2.3 所示，安全模式 1 仍是保障点对点低功耗（LE）连接安全的主要机制。安全性是通过由安全管理器协议（SMP）管理的蓝牙配对流程建立的，安全级别越高，其身份验证和加密要求就越严格。目前，大多数蓝牙® LE 设备均采用安全模式 1 进行工作。

安全模式 3 通过保护广播等时流（BIS）来处理另一类通信。与通过配对生成加密密钥不同，模式 3 使用 Broadcast_Code 来控制对加密广播内容的访问。安全级别决定了 Broadcast_Code 是通过经过身份验证的机制还是未经身份验证的机制进行分发的。

安全模式 4 的引入为蓝牙® LE 安全带来了根本不同的方法。安全模式 1 通过蓝牙配对流程建立信任，并通过绑定维持该信任；而模式 4 则假设身份验证和密钥建立由更高层规范在外部完成。 随后，蓝牙利用生成的临时应用密钥（Transient Application Key）建立链路层 加密连接，而无需建立绑定关系或保留长期安全状态。这使得模式4特别适用于需要安全通信但无需持久信任关系的临时交互场景。

总而言之，安全模式 4 仅应在参与设备已通过能够建立具有 128 位安全强度的共享密钥的高层协议规范进行身份验证后使用。

6.2.4 建立由 TAK 保护的连接

当处于安全模式 4 下的设备从上层应用程序获取了临时应用密钥（TAK）后，即可使用该密钥建立加密的蓝牙® LE 连接。与传统的蓝牙安全流程不同，身份验证和密钥建立是在蓝牙协议栈之外进行的。蓝牙仅负责使用提供的密钥应用链路层 加密。

图 6.2.4 说明了高层认证与蓝牙链路层 保护之间的分离。与基于配对的安全机制不同，信任关系是在蓝牙协议栈之外建立的，且在启动蓝牙® LE 加密启动程序之前，会先推导出一个共享密钥。如图所示，通过以下操作序列建立起由 TAK 保护的连接：

步骤 1：建立连接

参与的设备首先建立一个标准的蓝牙® LE ACL 连接。在此阶段，该连接尚未进行加密。

步骤 2：更高层级的身份验证

高层应用会根据其自身规范中定义的流程对对等设备进行身份验证。根据具体应用的不同，身份验证过程可能在带内进行，也可能通过带外机制进行。该身份验证过程独立于蓝牙安全管理器，且发生在蓝牙安全框架之外。

步骤 3：TAK 的推导与配置

身份验证成功后，两台设备将推导或获取一个具有128位安全强度的共享密钥。该密钥将成为临时应用密钥（TAK），并提供给蓝牙主机，用于加密设置过程。从功能上讲，在加密过程中，TAK的作用与长期密钥（LTK）相同。

第 4 步：加密启动流程

主机使用 TAK 启动标准的蓝牙® LE 加密启动程序。在此过程中，TAK 作为加密密钥提供给链路层 ，而EDIV和Rand值则设置为零，因为该密钥并非通过蓝牙配对程序生成。随后，控制器利用现有的蓝牙® LE 加密框架建立加密会话。

第 5 步：TAK 的处置

启动加密开始程序后，主机将丢弃 TAK。控制器使用 TAK 建立加密上下文，并在加密上下文建立后不再保留 TAK。上层应用程序可根据自身的安全策略，保留或丢弃其拥有的密钥副本。不会生成任何绑定信息，也不会存储任何长期的蓝牙安全状态。

6.2.5 运行时行为与会话管理

一旦建立了由 TAK 保障的连接，其运行时行为便与传统的基于配对的连接有所不同。主要区别在于，在安全模式 4 下运行的设备不依赖配对、绑定或安全管理器协议 (SMP) 来维护安全状态。相反，该连接采用由上层应用程序定义的安全策略，并结合身份验证过程中建立的临时应用程序密钥（TAK）来运行。

在确定应如何保障连接安全时，设备会考虑对等设备的绑定状态以及上层应用程序的要求。如果对等设备已建立绑定，则该连接将采用现有的基于配对的安全模型以及已绑定的长期密钥（LTK）。 已配对的连接不使用临时访问密钥（TAK）。如果对端设备未配对，且上层应用程序配置为使用非配对安全模型，则该连接将在安全模式 4 下运行。

与安全模式 1 不同，在安全模式 4 下运行的设备不会为满足安全要求而启动蓝牙配对程序。如果需要加密且有有效的 TAK，主机将在授予对所请求服务的访问权限之前，使用该 TAK 启用链路层 加密。如果没有 TAK，则服务请求将被中止，而非回退到配对流程。

同样，在安全模式 4 下运行的连接不会使用配对来建立安全性。如果需要加密，则必须提供有效的 TAK 才能建立链路层 加密。在安全模式 4 下运行的连接中，配对不会作为建立安全性的替代机制。

服务访问决策既基于连接的当前状态，也基于上层规范所定义的策略。当服务要求加密时，必须在授予访问权限之前对连接进行加密。当存在身份验证要求时，只有在根据负责建立信任的上层策略满足这些要求的情况下，才会接受由TAK保护的连接。

安全模式 4 的运行时行为与安全模式 1 存在根本性差异，其概要如表 6.2.5 所示。

场景	安全模式 4 的行为
无需加密	服务请求正常进行
需要加密，且支持TAK	链路层 使用 TAK 启用了加密功能
需要加密，但没有 TAK	服务请求已中止
需要身份验证	决策受上级政策约束
已收到配对请求	请求被拒绝
通过配对实现安全升级	不允许

因此，安全模式 4 作为一种独立的安全模型运行，而非基于配对的安全机制的变体。信任关系由上层应用程序在外部建立，而蓝牙仅负责在连接的整个生命周期内实施链路层 保护。

6.2.6 TAK 保障连接中的 GATT 相关考虑因素

TAK 的会话导向特性会影响 GATT 层上的应用程序行为。由于在安全模式 4 下运行的设备不会建立绑定关系，因此蓝牙协议栈不会在连接之间保留服务级状态。因此，每个由 TAK 保护的连接都被视为一个独立的会话。

这种行为在处理客户端特性配置（CCC）设置时尤为明显。在安全模式 4 中，CCC 配置被视为临时配置，连接结束时将被丢弃。因此，需要接收通知或指示的应用程序必须在每次建立新的 TAK 加密连接时，重新配置相应的 CCC 值。

安全模式 4 还要求使用 LE GATT 安全级别特征来传达 GATT 服务器的安全要求。该特征允许 GATT 服务器在通过 TAK 加密连接运行时，指定访问其服务和属性所需的安全级别。

因此，基于 TAK 的安全机制引入了一种完全面向会话的运行模式，在此模式下，安全状态和相关服务配置仅在连接存活期间存在。当连接终止时，TAK 以及任何与会话相关的服务状态都会被丢弃。

6.2.7 安全注意事项

TAK 用于为蓝牙® LE 连接建立和维持链路层 加密。一旦建立加密，该连接即可受益于蓝牙® LE 加密框架提供的机密性和完整性保护。

使用 TAK 的上层规范负责建立信任关系，并确定 TAK 的生成、获取及提供给蓝牙主机的具体方式。这包括为保护密钥建立过程所需的身份验证和安全程序。

因此，采用 TAK 的更高层规范负责：

• 对对等设备进行身份验证
• 推导或获取用作TAK的共享密钥
• 防范中间人攻击
• 定义控制何时以及如何向蓝牙主机提供 TAK 的策略

TAK 架构的一个关键含义是，身份验证和防范中间人攻击的功能由上层规范提供，而非由蓝牙配对流程提供。因此，TAK 加密连接的安全特性取决于上层规范所采用的身份验证和密钥建立流程。

这种分离使得上层规范能够定义适合其应用的身份验证和信任机制，同时利用标准化的蓝牙®链路层 加密技术来保护通过该连接交换的数据。

6.3 小结

蓝牙®瞬时应用密钥（Bluetooth® Transient Application Key）引入了一种全新的非配对安全模型，该模型无需配对或绑定即可建立加密的蓝牙®低功耗（LE）连接。身份验证和密钥建立由更高层的应用程序完成，而蓝牙则利用生成的密钥提供蓝牙®低功耗（链路层 ）的机密性和完整性保护。

为了支持这一功能，蓝牙®低功耗（Bluetooth® LE）引入了安全模式 4，通过一项专门针对临时交互设计的新选项，对现有的安全框架进行了扩展。与传统的基于配对的安全机制不同，模式 4 不会建立持久的信任关系，也不会保留长期的安全状态。

通过将信任建立与传输保护分离，TAK 扩展了蓝牙安全架构，从而支持基于会话的安全通信，而无需建立持久的信任关系。TAK 并非取代现有的基于配对的安全模型，而是通过为在蓝牙协议栈之外建立信任的应用程序提供一种替代方案，对现有模型进行了补充。

因此，“临时应用密钥”和“安全模式 4”的引入标志着蓝牙®低功耗（Bluetooth® LE）安全架构的一次重要演进，它能够实现安全、加密且基于会话的交互，而无需配对、绑定或建立持久的信任关系。

7. 蓝牙®加密产品调试（EPD）

7.1 背景

加密在保护用户数据和通信方面发挥着至关重要的作用。与此同时，它也为协议分析带来了挑战，因为如果没有访问保护该连接的凭据，就无法完全解码捕获到的流量。蓝牙®加密产品调试（EPD）通过为授权的调试工具提供一种标准化方式，使其能够访问分析加密蓝牙流量所需的活动加密信息，从而解决了这一挑战。

从历史上看，通常可以通过分析配对过程中建立的长期安全凭证（例如长期密钥（LTK））来解析加密的蓝牙流量。在许多部署场景中，获取这些凭证所提供的信息足以让协议分析器和调试工具重建连接的加密状态，从而支持互操作性测试、产品验证和故障排除工作。

然而，随着蓝牙加密技术的不断发展，主动加密凭证越来越多地在控制器内部生成和维护。在基于主机控制器接口（HCI）的架构中，主机和外部调试工具可能无法访问这些凭证，这使得加密流量更难进行分析和故障排除。这一点在加密密钥调度（EKS）中尤为明显，因为保护连接的加密状态是在控制器内部推导和维护的。 如果没有获取活动加密凭据的标准化途径，主机开发人员可能需要借助专有机制来获取控制器密钥，从而对捕获的空中流量进行解密。EPD 通过为主机提供一种获取活动加密状态的标准化机制来应对这一挑战，使测试环境能够同时捕获空中流量和 HCI 流量，并支持自动解码、调试和互操作性测试。

为应对这一挑战，蓝牙®加密产品调试（EPD）引入了一种标准化机制，允许控制器将当前有效的加密凭据报告给本地主机，以供调试之用。通过提供对当前保护连接的加密状态的可视性，EPD 有助于在保持协议分析和互操作性调试功能的同时，不改变蓝牙加密的工作方式。

7.2 技术概述

7.2.1 对活动加密状态的可视性

蓝牙® EPD 可提供对正在积极保护加密蓝牙®连接的加密信息的可见性。EPD 不会披露配对记录、绑定数据库或其他历史安全信息，而是专注于控制器当前维护的、用于保护连接设备之间数据传输的加密状态。

图 7.2.1 说明了加密可见性如何从传统的蓝牙® LE 加密演变为基于加密密钥调度 (EKS) 的加密。

在传统的LE加密中，调试工作通常从获取长期密钥（LTK）开始。由于通常可以通过LTK以及加密建立过程中交换的信息来重建当前的加密状态，因此协议分析仪通常能够推导出会话密钥并解密捕获的流量。

然而，在 EKS 中，该过程变得更为复杂。如图 7.2.1 所示，EKS 引入了一个内部密钥层次结构，其中利用基于 ECDH 派生的共享密钥以及其他加密输入来派生流量密钥，进而生成用于保护连接的会话密钥和初始化向量 (IV)。在这种情况下，仅凭对长期凭证的可见性，可能已无法提供足够的信息来确定当前保护用户流量的加密状态。

EPD 通过提供对活动加密状态的可视性来应对这一挑战，而非提供配对或绑定过程中使用的长期凭证。EPD 不报告 LTK，而是报告与加密连接相关的会话密钥和初始化向量（IV），从而使调试工具能够与控制器主动维护的加密上下文保持同步。

7.2.2 基于 EKS 的加密模式

为了更好地理解图7.2.1中所示的加密活动状态，有必要简要探讨在使用加密密钥调度（EKS）框架时，加密凭据是如何建立的。

当两台设备均支持 EKS 时，将通过“基于密钥调度启动加密”流程建立加密连接。与传统的 LE 加密不同，EKS 引入了由控制器管理的密钥派生流程，该流程利用 ECDH 生成的共享密钥以及其他加密输入，来建立用于保护连接的加密状态。这些流程最终会生成用于加密流量的会话密钥和初始向量（IV）。

EKS 支持两种部署模式。

• 带长期密钥（LTK）的 EKS

在此模式下，由主机提供的 LTK 将与 ECDH 生成的共享密钥以及在建立加密连接过程中交换的其他加密输入一起参与派生过程。由此生成的流量密钥随后用于派生用于保护该连接的会话密钥和初始向量（IV）。

• 机会主义加密

在此模式下，加密是通过 EKS 框架建立的，无需依赖先前分发的 LTK。该规范将 LTK 输入定义为零值密钥，而会话密钥和初始向量（IV）则由 ECDH 密钥交换及相关 EKS 流程推导得出。

无论加密是如何建立的，这两种部署模型最终都会在控制器内创建一个活动加密状态，该状态由保护连接的会话密钥和初始向量（IV）表示。这些值由EPD报告，并通过主机控制器接口（HCI）提供给调试工具。

7.2.3 蓝牙® EPD 报告机制

为了提供对活动加密状态的标准化访问，EPD引入了一个轻量级的宿主控制器接口（HCI）报告框架。该功能包括两个用于管理报告行为的HCI命令，以及一个用于向宿主传递加密信息的HCI事件。

EPD 旨在用于受控的开发、测试和互操作性环境，在产品正常运行期间不应启用该功能。

表 7.2.3a 总结了 EPD 功能所引入的人机交互（HCI）要素。

组件	目的
读取加密密钥调试报告模式命令	读取当前的EPD报告配置
写入加密密钥调试报告模式命令	启用或禁用加密报告
加密密钥调试报告事件	报告与活动连接相关的加密信息

如表 7.2.3a 所示，“读取和写入加密密钥调试报告模式”命令允许主机查询和配置报告行为，而“加密密钥调试报告”事件则提供了调试工具所需的实际加密信息。这些新增功能共同构建了一种标准化机制，可通过 HCI 公开加密信息，而无需依赖供应商专有的诊断工具。

“加密密钥调试报告”事件包含与连接当前加密状态相关的信息。如表 7.2.3b 所示，EPD 报告的是当前与加密连接关联的会话密钥和初始向量（IV），而非 LTK 等长期凭证。这些值代表控制器正在维护的加密状态，并与用于对流量进行加密和解密的信息直接对应。

参数	费用项目
连接句柄	标识加密连接
会话密钥	与该连接关联的加密密钥
会话密钥长度	会话密钥的长度
IV	与该连接相关的初始化向量
IV 长度	初始化向量的长度

7.2.4 事件生成行为

蓝牙® EPD 采用事件驱动的报告模型。控制器不会持续报告加密信息，而是在连接的新加密凭据生效时，才生成“加密密钥调试报告”事件。这种方法既确保了每当活动加密状态发生变化时，调试工具都能收到最新的加密信息，又避免了不必要的报告开销。

触发事件	已生成加密密钥调试报告
HCI_加密_变更	是
HCI_加密密钥刷新完成	是
HCI_LE_CIS_已建立	是

如表 7.2.4 所示，报告的生成与连接的加密状态变化直接相关。当首次启用加密时、当现有会话密钥被刷新时，或者当新的加密 CIS 可用时，控制器会生成一份包含该连接相关加密信息的“加密密钥调试报告”。

这种基于事件的方法有助于确保在连接的整个生命周期内，调试工具始终与当前的加密状态保持同步。随着加密凭据随时间推移而变化，系统会生成额外的报告，以反映用于保护该连接的更新后的会话密钥和初始向量（IV）。

由于报告仅在加密状态发生变化时才会生成，因此 EPD 在最大限度降低实现开销的同时，仍能为调试工具提供分析加密的蓝牙® 流量所需的信息。

7.2.5 蓝牙® EPD 报告工作流程

前几节介绍了EPD报告的信息以及报告发生的条件，而要全面理解主机与控制器之间的交互关系，最好通过图7.2.5所示的报告工作流来理解。

图 7.2.5 展示了一个典型的 EPD 报告流程。在主机启用加密密钥调试报告功能后，每当为加密连接生成新的会话密钥时，控制器都会生成一份加密密钥调试报告，并将相关的会话密钥和初始向量（IV）发送给主机。这种基于事件的工作流使调试工具能够在连接的整个生命周期内与当前的加密状态保持同步。

该工作流程可概括如下：

1. 主机通过“写入加密密钥调试报告模式”命令支持EPD报告功能
2. 使用标准的蓝牙加密程序建立加密连接
3. 加密连接将启用一个新的会话密钥
4. 控制器会生成一份加密密钥调试报告，其中包含与该连接相关联的会话密钥和初始向量（IV）
5. 主机接收该报告，并可向协议分析仪、互操作性测试系统或其他调试工具提供信息

每当生成后续会话密钥时，系统可能会生成额外的报告，以确保调试工具与活动加密状态的变化保持同步。例如，当 PHY 状态切换至或离开 HDT 时，或者当触发自愿密钥刷新时，CIS 连接的活动加密状态可能会发生变化。在这些情况下，EPD 会向主机提供更新的会话密钥和初始向量（IV），以便调试工具能够继续使用当前的加密状态对加密流量进行解码。

7.3 总结

蓝牙®加密产品调试（EPD）提供了一种标准化机制，可通过主机控制器接口（HCI）揭示加密蓝牙®连接的当前加密状态。EPD 并非依赖于对长期凭证（如长期密钥（LTK））的可见性，而是直接提供对当前保护该连接的会话密钥和初始化向量（IV）的访问权限。

随着蓝牙加密技术通过加密密钥调度（EKS）等机制不断演进，用于保护用户流量的凭证可能通过控制器管理的加密流程来建立和维护。在这种情况下，仅靠对长期凭证的可见性可能已不足以进行协议分析和互操作性调试。EPD 通过提供对控制器维护的活跃加密状态的标准化可见性，解决了这一挑战。

通过两个 HCI 命令和一个专用的报告事件，EPD 使协议分析仪、互操作性测试系统和调试工具能够与加密连接的变化保持同步，同时避免使用供应商专有的日志记录机制或专有调试接口。

通过将调试可见性与底层的加密建立流程解耦，EPD 确保无论是在传统的 LE 加密部署还是基于 EKS 的加密部署中，加密的蓝牙流量均可被观察和调试。

8. 蓝牙®功率等级说明

Bluetooth® Core 7.0 已从规范中删除了历史上的蓝牙功率等级定义。虽然功率等级长期以来一直被用作描述设备发射功率能力的参考分类，但蓝牙认证和符合性评估始终基于《Bluetooth® 核心规范》中定义的适用无线电要求。因此，删除功率等级定义不会影响认证流程、互操作性或设备行为。

蓝牙®设备历来与功率等级相关联，该等级体系根据设备的最大发射功率对其进行分类。对于 BR/EDR 和 LE 设备，这些分类如表 8a 和 8b 所示。

力量课程	要求
1	100 mW (20 dBm) ≥ Pmax > 2.5 mW (4 dBm)
2	2.5 mW (4 dBm) ≥ Pmax > 1 mW (0 dBm)
3	1 mW (0 dBm) ≥ Pmax

力量课程	要求
1	100 mW (+20 dBm) ≥ Pmax > 10 mW (+10 dBm)
1.5	10 mW (+10 dBm) ≥ Pmax > 2.5 mW (+4 dBm)
2	2.5 mW (+4 dBm) ≥ Pmax > 1 mW (0 dBm)
3	1 mW (0 dBm) ≥ Pmax ≥ 0.01 mW (-20 dBm)

尽管在产品文档和营销材料中被广泛提及，但功率等级历来仅作为描述性分类，而非合规要求。蓝牙认证和合规性始终基于《蓝牙®核心规范》中定义的适用无线电要求。因此，《蓝牙®核心规范 7.0》从规范中删除了历史上的功率等级定义。

因此，删除“功率等级”定义不会影响资格认证程序、互操作性预期、无线电性能要求或设备行为。相反，此项变更进一步明确了信息性产品分类与规范性蓝牙要求之间的区别。

9.结论

Bluetooth® Core 7.0 在多个关键领域对 Bluetooth® LE 进行了扩展，包括数据吞吐量、等时传输、安全性和实现支持。HDT 在保持与现有 Bluetooth® LE 架构集成不变的同时，显著提高了数据吞吐量；IPU 支持主动 CIS 传输，可在无需重新建立数据流的情况下适应不断变化的运行需求；而 EKS 为加密材料的建立、分离和更新提供了更灵活的框架。 TAK 通过支持无需配对或绑定即可进行的安全、会话导向的交互，进一步扩展了蓝牙安全模型；而 EPD 则提供了对活动加密状态的标准化可见性，以支持协议分析、调试和互操作性测试。

总体而言，这些增强功能推动了蓝牙技术的持续演进，在保持蓝牙架构基础的同时，实现了更高的性能、更强的适应性以及更灵活的安全和开发模型。因此，蓝牙® Core 7.0 在扩展蓝牙功能的同时，也保持了支撑该技术的互操作性和架构一致性。

10.参考文献

项目	地点
蓝牙®核心规范 v7.0	https://www.bluetooth.com/specifications/specs/core-specification-v7/