第 4 章 同步流

 机器翻译，仅用于学习记录，原文链接

如果您过去使用过蓝牙®应用程序，那么您可能会集中于配置文件，而几乎不看蓝牙®核心规范。这是可能的，因为蓝牙经典音频配置文件使用定义良好的传输配置与蓝牙®核心规范设置，因此不需要了解在配置文件或其相关协议下面发生了什么。对于蓝牙LE音频配置文件，这种情况会发生变化，因为与任何蓝牙经典音频配置文件相比，您更有可能影响蓝牙®核心规范的工作方式。

为了尝试使最灵活的系统成为可能，这不仅可以满足今天的音频需求，而且还可以满足我们甚至还没有想到的需求，规格必须允许更大程度的灵活性。为了实现这一点，我们做出了一个基本的架构决策来分割音频平面和控制平面。这意味着，新的同步物理通道已经被定义，以传输音频流。这些都位于旁边，但都是独立于现有的蓝牙LE的ACL链接。蓝牙®核心规范中的同步物理通道可以让你建立许多同步音频流，它们能够传输所有类型的音频，从非常低的语音质量，到令人难以置信的高音乐质量。除了一个例外，我们将在后面看到，同步流不包含任何控制信息——它们纯粹用于携带音频。伴随的ACL通道用于设置等时流，打开，关闭，添加音量和媒体控制，以及我们需要的所有其他功能，使用标准的GATT程序，这是蓝牙LE的一部分。

为了提供对不同的延迟、不同的音频质量和不同级别的健壮性所需的灵活性，开发人员需要能够控制这些同步流的配置方式。这是在通用音频框架的配置文件堆栈中完成的。这意味着，当你开始使用蓝牙LE音频应用程序时，即使你只是使用顶级的配置文件，你仍然需要知道相当多的底层等时流是如何工作的。这与你在之前的大多数蓝牙应用程序中所经历的情况有所不同。为了帮助理解蓝牙LE音频的整体架构，我们需要了解这些同步流是如何开发的，它们是做什么的，以及如何使用它们。

4.1 蓝牙 LE 音频拓扑

到目前为止，蓝牙规范主要关注点对点连接：中央设备连接到外围设备，并交换数据。这是一个非常受限的拓扑结构。许多公司已经开发了专有扩展来增加灵活性，就像我们看到的真正的无线立体声耳塞，但开发同步流是为了应对这些专有解决方案无法提供的更广泛的拓扑结构。除了将手机连接到一对耳机或单个扬声器之外，蓝牙LE音频还需要向左耳塞和右耳塞分别发送左右信号。它还需要能够将相同的信息发送到多个耳塞，并扩大设备和流媒体的数量。这些都涵盖在当前的蓝牙LE音频规范。它们还为进一步的音频应用提供了基础，在空间音频、环绕立体声和语音识别能力方面的工作已经在进行中。

等时流有两种类型：单播广播和广播。单播连接，被称为连接的等时流（CIS），是最接近现有的蓝牙音频用例。在这个意义上，“连接”意味着它们在两个设备之间传输音频数据，在两个设备之间使用一个确认方案来提供流量控制。已连接的等时流有一个ACL控制通道，该通道在携带音频数据的CIS的整个生命周期中一直启动并运行。

广播等时流（BIS）的一个非常相似的结构被用于广播，但有一个很大的区别。对于广播，传输同步流的设备不知道可能有多少设备在那里接收音频。设备之间没有连接，也不需要ACL链路。最简单地说，广播纯粹是混杂的。但是，也可以向广播中添加控制链接。在控制器级别，连接流和广播等时流之间有明显的区别，这是基于数据是否被承认。然而，许多应用程序将在单播和广播之间切换，以满足不同的用例，而用户不知道发生了什么。但目前，我们将专注于基本知识。

广播允许多个用户听到相同的内容，其方式与 FM 收音机或广播电视相同。对蓝牙 LE 音 频广播功能的要求最初是由拾音线圈的助听器应用驱动的，在这种应用中，在公共场所佩 戴助听器的多个人可以收听相同的信号。拾音线圈可以提供良好的音频质量，但主要用于语音。凭借蓝牙 LE Audio 的更高质量以及显著降低的安装成本，该行业设想了更广泛的应用程序和使用情况，包括管理商业和酒店场所音频服务的机会。传统的拾音线圈位置， 如会议中心、剧院和礼拜场所;每个拥有耳机和耳塞的人都可以访问公共信息，例如航班公告、火车发车时间和公交时间，而不仅仅是佩戴助听器的人。广播也适用于更个人的应用程序，一群人可以收听同一台电视，或分享他们手机上的音乐。最后一个示例展示了蓝牙LE 音频应用程序如何在无形中来回切换底层协议。如果您将音乐从手机流式传输到耳塞，则可能使用的是连接的同步流。当您的朋友过来问他们“您也想听这个吗”时，您的音乐共享应用程序会将您的手机从私人单播连接切换到加密的广播连接，这样你们都可以听到相同的音乐，无论是在耳塞、助听器、耳机还是扬声器上。在应用程序层，聆听音乐并与

蓝牙 LE 音频建立在蓝牙 LE 规范中存在的基本不对称性之上，其中一台设备 - 中央设备，负责设置和控制同步流。Central 可以连接到许多外围设备，使用 Isochronous Streams 发送和接收音频数据。不对称意味着 Peripheral devices 的功耗可以低得多。

对于 CIS，外围设备现在对同步流的配置方式有发言权，这将影响音频质量、延迟及其电池寿命，从而使它们能够比蓝牙经典音频配置文件更好地控制音频流。对于 BIS，Central负责决定它传输的内容，而 Peripheral 则负责决定它想要接收哪些 Broadcast Isochronous Streams。两者彼此独立运行，尽管可以让它们进行通信以支持更复杂的应用程序。

重复我们在第 3.3 节的术语概述中所说的内容，随着我们向上推进蓝牙 LE 音频规范的堆栈，我们将遇到设备所执行角色的许多不同的名称。在 BluetoothCore 规范中，它们被定义为中央设备和外围设备。在 BAPS 规范集中，它们称为 Client （客户端） 和 Servers（服务器），在 CAP 中，它们称为 Initiator （发起方） 和 Acceptor（接受方）。发起方角色始终存在于负责调度同步流的中央设备中。接受器是参与这些流的设备。始终有一个 Initiator，但可以有多个 Acceptor。 

当我们进入顶级配置文件时，会出现大量新的角色名称，包括 Senders、Broadcasters 和 Receivers。我将忽略所有这些名称，并在大多数时间使用 Initiator 和 Acceptor 名称（即使它们在技术上是角色），因为我认为它们最能解释蓝牙 LE Audio Streams 的工作方式。当不涉及 Audio Stream 时（Control 规范就是这种情况），我将回到使用 Client和 Server。

理论上，该规范可以支持多达 31 个单独的单播同步流，这些流可以连接 31 个不同的设 备。这对于音频来说实际上是不现实的，因为我们在三四个流之后就开始耗尽带宽。

BluetoothCore 规范中限制 31 个流的原因是同步流功能旨在支持许多不同的时间关键型应 用程序，而不仅仅是音频。其中一些需要的带宽比音频少得多。当我们查看 LC3 编解码器时，我们会发现我们必须在延迟、音频质量和稳健性之间做出一些权衡，这些权衡限制了我们实际可以支持的音频流数量。

对单播可以支持的流数量的广播时间限制是使用广播的原因之一。如图 4.4 所示，单个Broadcast Source 可以与多个 Acceptor 通信，这些 Acceptor 通常被配置为成对的设备，接收单个单声道或单独的左右音频声道。根据所需的音频质量（通常决定采样率，从而决定广播时间使用情况和最大流数），广播源可能能够提供更强大的功能，例如以不同语言同时传输音频流。这些是设计蓝牙 LE Audio 应用程序时需要了解的权衡，我们将在以下章节中更详细地介绍。

4.3 连接的同步流

为了解释 BluetoothCore 规范中的同步功能，我们将从单播和连接的同步流开始，它们被称为 CIS。它们的结构相当复杂，但它建立在一些非常简单的原则之上。首先，我将介绍如何设计 Connected Isochronous Streams，解释其组成部分及其工作原理，然后了解Broadcast 的不同之处。这为你进入 Generic Audio Framework 奠定了基础，我们将Isochronous Streams 用于工作。

4.3.1 CIS 结构和时间

在设计数字音频时，通常会有这样一个限制，即要以标准、一致的速率对输入的音频进行采样。对传入音频进行采样和编码后，它会被发送到蓝牙发射器，再发送到接收设备。该系统是重复的，音频数据受时间限制，传输之间有一个恒定的间隔，称为等时间隔（ISO_Interval）。CIS 中每个同步间隔的开始称为其锚点。如图 4.5 所示，传输从Initiator 向 Acceptor 发送包含音频数据 （D） 的数据包开始。当 Acceptor 收到它时，它会发回一个确认，并且该过程会定期重复。图 4.5 中的第三个数据包没有确认，因此发起方会假定它没有被接收。 

大多数现代编解码器都经过优化，以 10 毫秒的帧速率运行，即它们一次采样 10 毫秒的音 频，这在音频质量和延迟之间提供了很好的折衷。这是 LC3 的首选设置，LC3 是蓝牙 LE Audio 的强制编解码器。除非我另有说明，否则我们将假设本书使用 10 毫秒的采样间隔，因此同步间隔将始终为 10 毫秒或 10 毫秒的倍数。

4.3.1.1 同步有效载荷

在设备之间发送的空中接口数据包（如图 4.5 中的“D”所示）的 PDU 中的数据结构非常简单。如图 4.6 所示。 

编码的 ISO PDU 前面是前导码和访问地址，后跟 CRC。当通过 LE 1M PHY 传输时，它们会增加 8 或 12 个八位字节（取决于ISO PDU 负载中是否包含消息完整性检查 （MIC），以及使用 LE 2M PHY 时为 9 个或 13个八位字节。如果包含 MIC，则会减少最大有效负载大小。CRC 是针对整个 ISO PDU（即报头、负载和 MIC）计算的。对于 CIS，ISO PDU 称为 CIS PDU，其结构如图 4.7 所示。 

• （ LLID（链路层 ID），表示它是成帧还是无帧
• NESN 和 SN，下一个预期序列号和序列号，用于链路层级别的确认和流控制，
• CIE，关闭同步事件位和
• NPI。Null Payload Indicator（空负载指示器），指示负载为空 PDU，标识没有要发送的数据。

 4.3.1.2 子事件和重新传输

我们将介绍 ISO PDU 标头中的控制位，因为它们与 CISes 工作原理的解释相关。在此之前，我们需要查看 Connected Isochronous Stream 的结构。我们已经讨论了等时间隔，即CIS 的连续锚点之间的时间。锚点是发起方传输 CIS 的第一个数据包的点，也是每个连续同步间隔的起点。在 CIS 中，如果需要，我们可以多次重传 CIS PDU，因为 CIS 结构支持多个子事件。每个子事件从来自发起方的传输开始，然后是 150μs 的帧间距 （T_IFS）之后来自接收端的响应，并在 Acceptor 的预期响应的最后一点结束。CIS 中的所有 Subevent 都构成一个 CIS 事件，该事件从 CIS 的 Anchor Point 开始，到接收到 Acceptor 接收的最后一个传输位结束。这在图表中更容易理解，如图 4.8 所示。

连续子事件之间的时间定义为Sub_Interval间距，即该 CIS 的子事件的最大持续时间，加上最小子事件空间 （T_MSS），定义为至少 150μs。子间隔间距是在配置 CIS 时确定的，并且在 CIS 的生命周期内不会更改。

4.3.1.3 跳频

定义 Subevent 的一个重要原因是，Bluetooth LE Audio 会更改每个 Subevent 上的传输信道频率，如图 4.9 所示，以防止干扰。

BluetoothCore 5.2 引入了一种新的信道选择算法，该算法比 BluetoothCore 4.0 中最初定义的算法更高效。这适用于每个 Subevent。如果 Subevent 未发送，则信道跳频方案假定该 Subevent 已发送，并移至下一个 Subevent 的下一个频率信道。

4.3.1.4 关闭 Subevent

当我们查看同步 PDU 标头时，我们看到有一个 Close Isochronous Event 位 – CIE。发起方使用它来表示它已收到来自接受方的确认，确认接受方已成功接收其数据包，以便它将停止该特定 PDU 的进一步重传。在图 4.10 中，发起方已经发出了它的第一个 PDU 并收到了确认，因此它随后发送了一个 CIE 位设置为 1 的数据包，以告诉接受端不会有进一步的传输，因为它已经成功收到了响应并正在关闭事件。它通常不会费心将音频数据包含在该传输中，因此它还会设置 Null Packet Indicator 位，允许它缩短传输的数据包。（图 4.10 显示了原始 CIS 事件的持续时间，以便进行比较。

​

这允许 Acceptor 进入休眠状态，直到下一个 Isochronous Interval。发起方可以利用这段时间做其他事情。由于许多 Initiator 还将与其他蓝牙设备交互，并可能与 Wi-Fi 共享他们的无线电和天线，因此额外的时间可能很有用。对于 Acceptor，在它准备好执行某项作之前关闭其接收器可以带来显著的省电。

如果 Acceptor 未收到带有 CIE 位的标头，则它可以继续侦听每个计划子事件中的数据，但不会从发起方接收任何数据包来响应。

4.3.2 控制音频质量和稳健性

在介绍了 CIS 中传输的基本时序之后，我们现在可以看到用于控制音频质量和链路稳健性的参数。对于许多音频应用程序，延迟很重要。对于某些应用程序，例如当您收听实时流时，将延迟降至最低非常重要，尤其是在您也可以听到环境声音的情况下。另一方面，如果您通过手机流式传输音乐并且听不到或看不到来源，那么延迟就无关紧要了。其他应用程序（例如游戏）具有不同的优先级，如果您在看电影时听音频，则口型同步就变得很重要。

基本音频配置文件 （BAP） 可以通过 LE_Set_CIG_Parameters HCI 命令设置许多影响音频质量和延迟的参数。我们将在第 7 章中看看它是如何做出这些选择的，但现在，我们需要了解如何配置 Isochronous Channel 结构。为了影响延迟和健壮性，应用程序可以请求的关键项目是：

• 最大传输延迟，它设置发起方可以花费的最长时间传输控制器为特定 CI接收的SDU。
• CIS 两个方向的最大 SDU 大小
• 两个方向的 SDU 间隔

Maximum Transport Latency （最大传输延迟） 会影响整体端到端延迟，尽管它只是其中的一个元素。虽然许多应用程序都希望最大限度地减少延迟，但在现实世界的无线世界中，您还需要解决无线链路固有的脆弱性，因为数据包可能会丢失。为了确保足够的健壮性（转化为渲染的语音和音乐流，而不会出现丢失、咔嗒声和静音），我们需要使用各种技术来帮助确保音频数据在可接受的时间范围内通过。这可能会导致延迟增加。

4.3.2.1 刷新超时和子事件数

• NSE - 子事件的数量。这指定了将在每个 Isochronous Interval 中计划的Subevent 的数量。它们用于 CIS PDU 的初始传输及其后续的重新传输。它们可能不会全部使用，但这是一个固定的预定数量。
• FT – 刷新超时。Flush Timeout 定义在丢弃 PDU 之前可以使用多少个连续的同步间隔来传输 PDU。不再传输的点称为Flush Point。
• BN – 突发数，即在每个 CIS 事件中为传输提供的 PDU 数量。

这些可能很难掌握，因此查看一些简单的示例很有用。

子事件数 （NSE） 是这三个选项中最直接的。它只是在每个同步间隔内可用的传输同步PDU 的机会数。在最简单的示例中，只为传输，PDU 将在第一个子事件中传输，然后可以在同一同步间隔内的后续子事件中最多重传 （NSE-1） 次。如果是单向 CIS，一旦 PDU 的传输被接收器确认，控制器就可以在该PDU 的下一次计划传输的报头中设置关闭同步事件 （CIE） 位（可以是没有数据的 CIS空 PDU），并且该 CIS 事件中的任何剩余子事件都将成为其他无线电应用的空闲广播时 间。

在这种情况下，Flush Timeout 为 1，因为 Flush Point 与 Isochronous Interval 的CIS Event 结束时间一致。这个简单的情况如图 4.11 所示。为清楚起见，以下示例仅涉及一个 Acceptor。 

在此示例中，NSE 设置为 4，因此每个数据包有四次传输机会。在第一个 CIS 事件中，四次尝试均未成功，因此数据包 P0 被刷新，接受器将需要尝试使用某种形式的数据包丢失校正来重建它。

第二个数据包 （P1） 在第二次尝试后成功，之后发起方将关闭事件。第三个数据包（P2）首次成功。

如果 Flush Timeout 增加，则数据包的传输可以继续进行更多的 Isochronous Intervals。图 4.12 说明了 NSE 保持为 4，但 Flush Timeout 增加到 3 的示例。 

这说明了一个问题。如果您只使用两个参数 – NSE 和 FT，则它允许数据包支配传输槽，直到它到达其刷新点。在图 4.12 中，第一个有效载荷 P0 在通过时遇到问题，它占据了前三个同步间隔中的所有子事件，使 P1 和 P2 等到刷新点 FP0 之后。虽然这种情况应该并不常见，但它可能会使后续有效载荷更加暴露，直到足够多的有效载荷通过以使系统恢复平衡。

4.3.2.2 突发数

解决此问题的方法是允许在单个同步间隔中传输多个有效载荷，以便每个同步间隔中的子事件可以在多个 PDU 之间共享，而不是由其中一个 PDU 独占使用。这是通过利用突发数（BN） 实现的，BN 是为 CIS 事件中传输而提供的有效负载数。在上面的示例中，在 CIS事件中只有一个有效载荷被传送到控制器，在这种情况下，SDU 和 PDU 生成的节奏与同步间隔相同，这意味着每 10 毫秒同步间隔有一个编码的 10 毫秒音频帧可用。如果我们想使用 BN 并继续每 10 毫秒对传入的音频通道进行采样，我们需要将 Isochronous Interval 增加到该间隔的倍数，以便我们在每个 Isochronous Interval 中有更多的有效载荷可用。

这意味着，通过解决一个问题，我们可能会产生另一个问题，这会增加延迟。

在图 4.13 中，Isochronous Interval 已加倍，允许在每个间隔内提供两个有效载荷。10毫秒编解码器帧和 20 毫秒同步间隔的组合意味着 Initiator 在每个同步间隔内有两个有效载荷可供传输。这样做的结果是，现在每个 Isochronous Interval 中有两个 flush点。在我们的简单示例中，每个 Flush Point 都发生在两个 Subevent 之后。对于 FT 和NSE 参数的更复杂的组合，可以根据 BluetoothCore 规范 [第 6 卷，B 部分，4.5.13.5]中的方程式计算出刷新点的位置。

回到图 4.13，我们看到 Initiator 在第一个 Subevent 中发送数据包 P0，该数据包被确认，因此控制器立即继续传输数据包 P1，在确认之前传输了 3 次。

在第二个同步间隔中，传输数据包 P2，但 Acceptor 发送 NACK 以指示收到的数据包中的错误。由于 Flush Timeout 设置为 1 且 BN=2，因此数据包 P2 的 Flush Point 处于相同的同步间隔中，在另外两次传输尝试之后出现，但接受器均未成功接收。

此时，发起方开始传输 P3，尽管在此示例中，接收方再次使用 NACK 进行响应，以指示它收到的数据包存在问题。两次尝试后，P3 将由 Initiator 刷新。

在图 4.13 的最后一个同步区间中，P4 被成功传输，给 P5 留下了 3 次机会，但都未成功。在每种情况下，发起方都将尝试在 PDU 的刷新点之前传输每个可用子事件中的 PDU。

每次确认传输后，它将移动到下一个可用数据包，或者，如果没有其他可用的数据包，则关闭 Isochronous Event。

在此示例中，将丢弃 P2、P3 和 P5。在现实生活中，我们期望得到更好的确认率 – 这只是一个例子来说明这个原则。

作为最后一个示例，图 4.14 显示了将 Flush Timeout 增加到 2 的效果，Burst Number为 2，这提供了以两个连续的同步间隔传输的机会。在此示例中，不会刷新任何数据包。

使用 Flush Timeout 和 Burst Number 对于提供更多跨多个同步间隔的重新传输机会非常有用。如果您处于嘈杂的环境中，它们特别有用。但是，它们对延迟有影响。刷新超时的每一次增加都会增加延迟，因为重新传输分布在更多的同步间隔中，而突发数会增加同步间隔的持续时间。请注意，Burst Number 仅适用于在同步间隔内到达的多个负载。它不能用于解决我们在图 4.12 中看到的单个有效载荷占用传输机会的问题，但这是处理干扰的主要技术。所以，这始终是一种权衡。

Burst Number 和 Flush Timeout 不能由 Host 直接设置。主机及其上运行的应用程序只能设置最大传输延迟、最大 SDU 大小和 SDU 间隔的值。然后在控制器中计算 BN 和 FT，其中考虑了芯片中的任何其他无线电要求。

主机可以使用 LE Set CIG Parameters HCI 命令（即 NSE - 1）请求重传号码 （RTN），但控制器仅将其视为建议。

了解这些参数对 Isochronous Channel 结构的潜在影响是有用的。我们可以在 TMAP 的表3.15 中找到这一点，该表提供了控制器如何解释 CIS 的 Host 值以适应不同作条件，例如优先考虑通话时间以实现共存或最小化延迟。参数的确切分配始终取决于Controller 中 scheduler 中的算法，该算法将由芯片供应商设置。在为请求的同步信道分配值之前，这将考虑其他资源要求，例如其他蓝牙连接和并发 Wi-Fi 流。

4.3.3 框架

CIS PDU 报头中需要了解的另一个参数是一对 LLID（链路层 ID）位，它指示 CIS 是成帧的还是未成帧的。Unframed 是指 PDU 由一个或多个完整的编解码器帧组成的情况。当Isochronous Interval 是编解码器帧长度的整数倍时，使用它。相比之下，Framed 是指编解码器帧长度和 Isochronous Interval 不匹配的地方，这会导致编解码器帧在多个SDU 之间分段。这开始变得复杂，但在 Initiator 可能需要支持具有不同时序的Bluetooth 连接时，这一点很重要。当我们研究 ISOAL 时，我们将重新审视这一点 - 同步适应层，它旨在应对这种不匹配。

如果数据包是 CIS 空 PDU，由 ISO PDU 报头中的空 PDU 指示符 （NPI） 位指示，则LLID 位将被视为 RFU 位，应予以忽略。

4.3.4 多个 CISes

在介绍了单个单向 CIS 的所有功能后，下一步是添加更多功能。最常见的应用是Initiator 分别将立体声音频流发送到左耳塞和右耳塞时。在这种情况下，Initiator 将使用两个不同的 Acceptor 设置单独的 Isochronous Streams。在图 4.15 中，我们可以看到它是我们之前看到的直接扩展 - Initiator 从第一个 Acceptor 发送并接收确认，然后对第二个 Acceptor 重复此作。

需要注意的重要一点是，虽然左右音频通道是同时采样的，但 ISO PDU 是串行发送的。 

请注意，当我们有多个 CIS 时，它们总是具有相同的 Isochronous Interval。它们的锚点 不同，因为数据是按顺序发送的，但对于每个 CIS，它们的锚点间隔相同。每个锚点表示该CIS 从发起方到接收方的首次传输点。 

这种方法的缺点是，如果您有一个可靠的连接，其中确认了数据包的第一次传输，则最终每个 CIS 之间都会出现间隙。在手机等通常共享蓝牙和 Wi-Fi 无线电的设备中，这是浪费的通话时间，本可以用于其他用途。为了解决这个问题，控制器可以选择交错 CIes 作为替代方法，如图 4.18 所示。

在这种情况下，CIS 0 的每个子事件后跟 CIS 1 的子事件，依此类推，其余 CIS 的子事 件。该图重复了图 4.17 的示例，其中 NSE 为 3，并显示 CIS 0 发送和接收其第一个子事 件，然后是 CIS 1。如果两个接受方都收到这些第一次传输并确认它们，则它们可以关闭其 CIS 事件。这导致它们传输后出现更大的差距，从而释放了可用于其他目的的通话时间。

4.3.5 双向 CISes

我们上面定义的多个单向连接的同步流复制了 A2DP 的使用案例。对于耳塞和许多其他音频应用程序，我们也希望恢复数据，这需要双向性。一种方法是在相反的方向设置第二个CIS，我们将使用一个 CIS 将音频从手机传输到耳塞，另一个 CIS 从耳塞传输到手机。但是，这是低效的。Bluetooth Core 规范通过将返回数据添加到 Acceptor 的确认数据包中来提供优化。它仍然是单个 CIS，但现在用于两个单独的音频流。 

在图 4.19 所示的示例中，Initiator 设置了具有左 Acceptor 和右 Acceptor 的单个 CIS。两者都从 Initiator 接收数据，但左侧的 Initiator 也会将数据从其麦克风发送回 手机。我们之前看到的相同原则也适用。数据由发起方发送，接受器立即响应确认接收（或未接收），如果有数据，则将其包含在返回的 CIS PDU 中。如果该返回 PDU 返回良好的 CRC，则 Initiator 将确认它，关闭事件，并将数据传输到正确的 Acceptor CIS。

两个方向的确认都使用 ISO PDU 报头中的 NESN 和 SN 位，在确认数据包时翻转位。在图4.19 中，所有传输的数据包都具有相同的 ISO PDU 格式。标记为“Ack”的 PDU 不包含音频数据，因此会将 NPI 位设置为 1 以指示它们的 CIS PDU 为空。来自左侧 Acceptor的数据包将与 Initiator 的 “L” 和 “R” 数据包的格式相同，但将包含来自Acceptor 麦克风的数据。

NSE 的值适用于 CIS 中的两个方向，因为相同的子事件用于将 PDU 传输到接收器和从接收器传输 PDU。一旦确认了一个方向的有效负载，未来的传输就可以将该 PDU 的有效负载替换为 null 有效负载。（这对 Subevent 的时间没有影响，但可以节省少量电量。

发起方可以在单向或双向 CIS 的 ISO PDU 报头中设置 CIE 位，以指示它不会在当前 CIS事件中传输任何其他有效载荷数据。除非已确认两个方向的负载，否则它不应关闭 CIS 事件。如果发起方已确认其数据包，但尚未从接受器收到预期的数据包，则它应继续在每个可用子事件中传输 CIS 空 PDU 数据包，以便为接受器提供重新传输的机会。

Acceptor 还可以在其 ACK 中设置 CIE 位，以指示它不会响应该 CIS 事件中的任何其他数据包。

双向 CIS 中的两个方向可以具有不同的属性，例如 codec 和 PHY，甚至可以由不同的应用程序使用。甚至一些结构参数对于两个方向也可能不同。FT 和 BN 可以不同，Max_PDU 和Max_SDU 值也可以不同，这也意味着 SDU_Intervals 可以不同，尽管一个需要是另一个的整数倍。但是，ISO_Interval、Packing、Framing 和 NSE 必须相同。

4.3.6 CIS 中的同步

一旦我们添加了第二个 Acceptor，两个 Acceptor 都彼此独立地工作，但在 Initiator的控制下。如果他们是一个 Coordinated Set（我们在 Section 3.9 中介绍过），他们将知道另一个存在，因为他们知道 Coordinated Set 中有多少成员。但是，您的左耳塞和右耳塞不一定知道另一个存在、打开或接收数据。用户可能会拿出一个与朋友分享，或者其中一个电池可能会没电。即使他们有通讯手段，也不能保证他们会一直保持联系。为了解决这个问题并使它们能够精确地渲染或捕获音频流，BluetoothCore 规范中的同步通道功能包括一种同步方法，该方法允许在两个或多个 Acceptor 之间实现微秒级的渲染精度，而无需任何 Acceptor 知道任何其他 Acceptor 的存在（或其他）。如果你怀疑它，这是微秒，而不是毫秒。图 4.20 说明了如何做到这一点。

在 CIG 中，为该 CIG 中的每个 CIS 安排 CIS 事件。对于一对耳塞，这将是两个 CIS 事件 - 一个用于左耳塞，一个用于右耳塞。它可以更多，例如使用多声道音响系统。这些CIS 事件构成了一个 CIG 事件。在图 4.20 中，为简单起见，多个 CIs 显示为顺序。它们同样可以交错。

BluetoothCore 规范定义了一个 CIG 参考点，该参考点可能与第一个 CIS 的锚点重合，但不能晚于第一个 CIS 的锚点。通常，它会在此之前发生。它还定义了一个 CIG 同步点，该同步点在该 CIG 中最后一个 CIS 事件的最后一个可能的接收事件之后发生。此时，Initiator 知道每个 Acceptor 都有一切可能的机会接收已发送给它的每个 PDU，并有时间为 Initiator 返回任何数据。

为了重建此公共点，每台设备都会收到其支持的每个 CIS 的单独 CIS 同步延迟的通知，该延迟是从与该 CIS 关联的 ACL 链路的即时计算得出的。这允许它计算 CIG 同步点，这是每个设备上的通用时间戳。有了这些知识，每个设备都可以确定何时应该开始解码音频。BAP 添加了一个名为 Presentation Delay 的功能，它告诉 Acceptor 何时呈现解码的流。随着我们向上移动并开始深入研究 QoS 和延迟的基本概念的细节，我们将了解如何使用 Presentation Delay 来增加渲染时间的灵活性。

如果您的设备带有麦克风，则存在相同的同步问题，但在这种情况下，您需要协调Acceptor 捕获音频的点。如果它使用双向 CIS 的上行链路，它将使用相同的 CIG 同步点，但可能需要与用于渲染来自发起方的下行链路音频数据的值不同的 Presentation Delay 值，因为 Acceptor 需要额外的时间来捕获和编码音频流。

同步计时以微秒精度定义。这意味着 CIG 中所有 Acceptor 的 Controller 都分配了一个时间戳，该时间戳彼此之间的差距在几微秒内。这需要传达给渲染音频流的应用程序层。做到这一点的方法取决于实现。这些规范没有定义音频数据最终渲染的准确性，但典型的实现实现从左到右同步的值在 5 到 10 微秒之间，这意味着左右耳塞可以将两个音频流呈现给比大脑可以辨别的距离更近的耳朵。

4.3.7 CIG 状态机

在介绍了构成 Connected Isochronous Streams 的所有功能之后，我们可以看看如何将它们组合在一起以配置和建立 Connected Isochronous Group。 

4.3.8 适用于 CISe 的 HCI 命令

BluetoothCore 规范定义了五个 HCI 命令，用于通知控制器每个 CIG。第一个是 LE Set CIG Parameters 命令 [第 4 卷，E 部分，7.8.97]，该命令创建一个 CIG 并在其中配置一个 CIes 数组。CIG 中的每个 CIS 可以是单向的，也可以是双向的。每个 PHY 都可以为每个方向使用不同的 PHY。

首次使用 LE Set CIG Parameters 命令创建 CIG，将其移动到 Configured CIG 状态，并在阵列中定义的 CIe 数量。该命令可以多次使用，以向 CIG 添加更多 CIS，或修改已经定义。每个 CIS 都分配有一个 Connection 句柄。

每次发出命令时，控制员应尝试计算 CIG 中所有 CIe 的计划，该计划满足 HCI 参数指定的要求，如果成功，将通过 HCI 完成命令确认这一点。请注意，Host 使用 HCI 命令发送的两个参数 – Packing 和 RTN（重新传输的次数）只是建议。财务总监在制定时间表时应该尽量适应他们，但可以忽略他们，或者尝试以他们为指导的最佳情况时间表。Burst Number、Flush Timeout 和 NSE 的链路层参数由 Controller 的调度算法决定，不能由更高的层规范显式设置。一些配置文件规范提供了建议，为特定用例提供最佳设置，但这取决于特定的芯片实现，即这些设置是可由应用程序访问，还是仅由调度器决定。

从主机发送的 HCI 参数与 Controller 设置的 HCI 参数之间的这种不匹配可能看起来很奇怪，但有一个很好的理由，即防止顶级配置文件或应用程序尝试优先考虑整个无线电作。许多蓝牙芯片包括 Wi-Fi，它们通常共享一根天线。因此，Controller 需要弄清楚如何满足两者的需求。Bluetooth 技术实现也可能运行多个配置文件。智能手机没有理由不能接收蓝牙 LE 音频广播流，然后将其作为一对连接的同步流重新传输到一对助听器（可用通话时间和处理资源的物理限制除外）。但是，在配置文件级别，这些应用程序可能都不知道另一个应用程序的存在。如果每个人都可以规定 BN、FT 和 NSE 的确切值，那么它们很可能无法与其他应用程序的约束共存。这就是为什么 HCI 命令阻止了这种级别的控制，允许控制器找出如何最好地将所有东西组合在一起。应用程序开发人员无法访问调度算法 – 它们是蓝牙芯片的关键部分。但是，重要的是要了解为什么您无法决定您想要什

么，并意识到过度指定音频应用程序需求的危险。

配置完所有 CIS 后，将使用 LE Create CIS 命令创建所需的每个 CIS，这会导致 CIG 进入活动 CIG 状态。此时，并非所有 CI都需要创建。只要使用 LW Create CIS 命令创建其中一个，CIG 也会建立。从这时起，可以断开一个 CIS 的连接，并在任何一点创建另一个CIS，当应用程序决定从使用耳塞中的麦克风转向使用智能手机上的麦克风时，这可能很有用。但是，这确实假设控制器设法安排了所有 CIS，并可能导致分配的通话时间无法用于其他用途。

CIG 将保持 Active CIG 状态，直到最后一个 CIS 断开连接。此时，它将变为 Inactive CIG 状态。可以使用 LE Remove CIG 命令将其永久删除，也可以再次使用 LE Create 命令将其返回到活动 CIG 状态在至少一个 CIes 上。

由于每个 CIS 都是由发起方创建的，因此每个接收端都将通过链路层命令收到连接参数的通知，从而导致 HCI LE CIS 请求事件 [第 4 卷，E 部分，7.7.65.26] 发送到其主机。

如果它接受请求，它将使用 HCI LE 接受 CIS 请求命令 [第 4 卷，E 部分，7.8.101] 进行响应，导致发起方和接受方主机都收到 HCI LE CIS 已建立事件 [第 4 卷，E 部分，7.7.65.25]。当我们进入 ASCS 时，我们将看到它们如何与 Isochronous Stream 状态机一起工作。

这样就完成了对 CIG 和 CIS 的所有组成部分的审查，以及我们如何将单播连接的同步流组合在一起。现在，我们将看看广播的类似物，我们必须做同样的事情，但没有在两个设备之间建立连接以允许它们协商自己在做什么的奢侈。

4.4 广播同步流

广播音频是蓝牙技术的一个全新概念。过去，音频总是直接从一台设备流式传输到另一台设备，正如我们在前面的章节中看到的那样。该概念现在已经通过 Connected Isochronous Streams 进行了扩展，因此我们可以将音频流式传输到多个设备。但这些设备仍处于连接状态，并且正确接收的每个数据包都会得到确认。使用 broadcast 时，没有连接。广播发射机范围内的任何设备都可以拾取广播音频流。与 Bluetooth Classic Audio 配置文件的最大区别在于它是单向的 – 没有确认。这意味着从技术上讲，可以构建一个不包含接收器但只进行传输的广播源。如果 Broadcast Streams 已加密，则接收设备将需要适当的Broadcast_Code来解密它们。

没有确认有一个实际的好处，即它通常会导致更大的范围。发生这种情况是因为连接上的链路预算通常非常不对称。广播发射机通常由市电供电，因此可以轻松地以允许的最大功率进行传输。这为它与耳塞提供了良好的链接预算。但是，耳塞不太可能以超过 0dBm（1mW） 的速率发送确认，这既是为了节省电池电量，也是因为它的小天线的增益可能会低于 0dB。这意味着耳塞接收广播传输的链路预算可能比返回确认路径高 10 – 20dB。

后者决定了 CIS 的最大范围。没有接收弱确认的限制，广播发射机可以覆盖相当大的区域 - 远远超过使用连接的同步流传输或经典的 BR/EDR 实现所能实现的。以 4mW 运行的广播发射机的演示已经实现了超过 50 米的可用射程。

4.4.1 BIS 结构

广播同步流和组的结构与我们刚刚看到的连接的同步流非常相似，但最大的区别是它是单向的，没有得到承认。

图 4.22 显示广播同步流具有相同的基本 PDU 结构，包括标头、有效负载和可选的 MIC（如果要加密）。但是，BIS 的报头要简单得多，因为它不需要 CIS PDU 报头中的 SN 和NESN 流量控制位。它以相同的两个链路层 ID （LLID） 位开头。这些指示 PDU 是成帧的还是未成帧的。然后是 CSSN 和 CSTF，它们用于指示存在可选的 Control Subevent。

CSSN 是控制子事件序列号，CSTF 是控制子事件传输标志，表示该 BIS 事件中存在控制子事件。这些是新的，在 Connected Isochronous Streams 中不存在。在 BIG 中，有一个Control Subevent，可用于向每个 Acceptor 提供控制信息。我们在广播中需要这些，因为没有 ACL 来通知 Acceptor 诸如跳跃序列的变化之类的事情。标头中唯一的其他信息是有效负载的长度。

如果我们看一下图 4.23 中 Broadcast Isochronous Stream 的结构，它也非常熟悉。BIS 和 CIS 之间的根本区别在于 BIS 中没有确认。BIS 完全由子事件组成，这些子事件包含发起方发送的数据。数据流不是双向的 – 一切都是从广播源传输的。与 CIS 一样，每个Subevent 都在不同的频道上传输。 

BIG（由一个或多个 BIS 组成的广播同步组）和 CIG 之间的一个显著区别是可能存在控制子事件，如图 4.23 中的虚线所示。当它发生时（在 BIG 事件中，ISO PDU 的报头包含CSTF 标志），控制子事件将在最后一个 BIS 的最终子事件之后传输，并为控制信息发送到接收广播流的每个设备提供了机会。我们将在 Section 4.4.3 中介绍它的作用。

如图 4.23 所示，广播同步流具有与 Isochronous Interval 相同的基本元素，以及 BIS和 BIG Events 的锚点。由于没有确认或返回数据包，因此定义了Sub_Interval时间，即单个 BIS 中连续子事件开始之间的时间。这也是最后一个 BIS 的最终 Subevent 开始与Control Subevent（如果存在）之间的时间。

如果 BIG 包含多个 BIS，则每个 BIS 由一个 BIS_Spacing分隔。通过调整 Sub_Interval 和 BIS_Spacing 的值，BIS 可以以 Sequential 或 Interleaved 方式排列，如图 4.24和图 4.25 所示。如果 BIS_Spacing 大于 Sub_Interval，则它们将按顺序排列。如果它更小，它们将被交错。 

两个图都显示了两个 BIS，每个 BIS 的 NSE 都设置为 2（即每个 BIS 有两个子事件）。从这些数字中可以得出一些重要的观察结果。首先，控制子事件永远不会计入 NSE 中 - 它是一个完全独立的子事件。第二个原因是，当存在 Control Subevent 时，它不会影响任何其他数据包或锚点。它被安排在最后一个 BIS 的最后一个 Subevent 之后。但它确实扩展了 BIG 事件，用于包含控制子事件的 Isochronous Intervals。 

虽然 CIS 可以在设备收到音频数据包后停止传输音频数据包，但广播源不知道它们是否已被接收，因此它必须重复每个传输。但是，一旦 Acceptor 收到数据包，它就可以关闭其无线电并等待下一个计划的BIS 事件。这再次凸显了我们在蓝牙 LE 中的不对称性。由于广播源始终在传输，因此它的功耗通常比接收器（可能是耳塞）高得多。一般来说，这意味着广播源需要更大的电池或永久电源。由于它们通常是公共场所的电话或基础设施发射器，因此这通常不是问题。

但是，如果广播传输被嵌入到手表或腕带等小型设备中，则应记住这一点。与 CIs 不同，所有 BISs 具有相同的 timing structure。虽然每个单独的 CIes 的结构通常根据其编解码器配置进行定制，以优化 PDU 大小的子事件，但每个 BIS 子事件的长度相同，这必须适合正在传输的最大 PDU。该约束是因为整个 BIS timing structure 是在 BIGInfo 中定义的，BIGInfo包含在 Periodic Advertisements 中。BIGInfo 结构的大小有限，因此无法为不同的 BIS 指定不同的时序 – 它指定了 “one size all”。这意味着，如果您想以 48kHz 采样率广播一个频道，以 24kHz 广播第二个频道，则较小的24kHz 频道仍将为较大的 48kHz 数据包分配 BIS 子事件定时，这会浪费广播时间。如果

这会导致问题，另一种方法是在单独的 BIG 中传输数据包。在这种情况下，这意味着一个 BIG 用于 48kHz 采样数据包，另一个 BIG 用于 24kHz 采样数据包。缺点是这增加了复杂性并使广告量翻了一番，因为每个广告都需要自己的广告集。实施者需要决定哪种方法最适合他们的特定应用程序。设计人员需要考虑是否将所有 BIS 放入单个 BIG 中。在某些应用程序中，将它们分成不同的 BIG 可能更有效地利用通话时间。

4.4.2 BIS 中的稳健性

BIS 参数的定义方式与 CIS 略有不同，因为在没有确认的情况下，我们需要采用一些不同的策略来最大限度地提高接收传输的机会。

BIS 仍然具有突发数 （BN），即每个同步间隔内的负载数，以及子事件数 （NSE），其定义方式与 CI相同。为了弥补缺少确认的问题，BluetoothCore 规范引入了 Group Count 的概念，这在发送重传的方式中引入了额外的多样性。

组计数定义为 NSE 与突发数 （NSE/BN） 的比率等时间隔。它用于确定 BIS 中重传的排列方式，将它们分配给组，这些组用于在传输方案中添加多样性。（这些组与广播同步组无关 - 不幸的是，将同一个词用于两个完全不同的概念。

图 4.26 显示了 BIS 的两个示例，每个示例都包含 6 个子事件，因此 NSE = 6。在第一种情况下，我们将 Burst Number 设置为 3。这意味着可用于该 BIS 事件的三个负载中的每一个都会发送两次。在第二个示例中，右侧有相同数量的 Subevent，但 Burst Number为 2，因此我们有两个负载的 3 次重传。每个子事件都有一个组号 （g），范围从 0 到（组计数 -1）。因此，在左侧图中，我们的 Group Count 为 2，包括组 0 和组 1。在右侧示例中，有三个组：组 0、组 1 和组 2，组计数为 3。

需要注意的重要一点是，尽管这两个示例看起来相同，但它们将具有不同的 Isochronous Intervals。假设我们的每个有效负载都表示一个包含 10 毫秒编码音频的编解码器帧，则左侧示例的同步间隔为 30 毫秒，因为它包含三个有效负载 – P0、P1 和 P1。右侧的示例将具有 20 毫秒的同步间隔，因为有两个有效负载 P0 和 P1。它说明了 Burst Number对延迟的影响，因为 Acceptor 必须等待更长的时间才能渲染音频。

Group Count 与蓝牙核心规范中包含的另外两个新参数配合使用，以增加传输的时间多样性，从而提供增强的稳健性：

• 立即重复计数 （IRC），它定义了携带与当前事件相关的数据的组的数量，以及
• 预传输偏移 （PTO）。预传输的概念是允许“early” 传输数据包，希望接收设备能够提前接收到音频数据包，允许其断电，然后准备好在最终传输机会出现时呈现它们。

这些参数由 Controller 中的调度程序计算，用于替换 CIS 中使用的 Flush Timeout。对于 CIS，Flush Timeout 本质上是一个结束停止，用于终止 PDU 的传输。在大多数情况下，从来不需要它，因为一旦 Initiator 收到已收到其数据的确认，它就可以关闭事件并停止传输。广播源不能这样做 – 它必须继续传输。因此，最大化数据包传输的多样性是有利的，以便为每个 Acceptor 提供找到数据包的最佳机会。他们越早做到这一点，他们就能越早入睡，直到下一个孩子到来。

Pre-Transmission Offset 的工作原理是引入与当前事件关联的 Subevent 以及与未来事件关联的 Subevent 的概念。将 Subevent 分配给 PDU 的方案甚至比 CIS 的方案更复杂，因此最好的解释是通过一系列示例来显示更改值的效果。这一切都由 Controller 完成，应用程序无法访问，但在设置 HCI 参数以配置流时，了解它会有所帮助。

为了说明未来子事件的概念，图 4.27 演示了一个 BIS 事件，其中 NSE 为 8 个子事件;其中前 5 个与当前 BIS 事件相关联，后 3 个用于未来 BIS 事件的数据。

我们现在可以将所有内容与更多示例放在一起。

这些子事件组被赋予一个数字 （g） ，我们在图 4.26 中首次看到。这与立即重复计数（IRC） 一起，根据以下规则确定在每个传输槽中发送哪些有效载荷，这些规则在BluetoothCore 规范第 6 卷 B 部分 4.4.6.6 中定义： 

• 如果 g < IRC，则组 g 应包含与当前 BIS 事件相关的数据。

• 如果 g ≥ IRC，则组 g 应包含与未来 BIS 事件相关的数据，即当前 BIS 事件之后的 PTO ×（g - IRC + 1） BIS 事件。

我们现在看几个例子，它们说明了这些不同的参数如何导致各种不同的重传方案。 

在图 4.28 中，我们有 4 个 NSE 为 4 的 Subevent。Burst Number 为 1 表示每个 BIS事件中提供了一个新负载（因此本例的 Isochronous Interval 为 10 毫秒）。Immediate Repeat Count 为 3，这意味着与每个事件关联的数据在前三个槽中传输。当 IRC = 3 且PTO = 1 时，该 BIS 事件中的最后一次传输来自下一个 BIS 事件。因此，在每个 BIS 事件中，总是有 3 次当前数据传输加上 1 次来自下一个事件的数据传输。

如果看起来我们发明了时间旅行，那我们并没有。我们只是稍微改变了我们的定义。在我们拥有 p0 和 p1 PDU 之前，事件 x 不会发生。所以 p1 实际上是事件 x 中的当前数据。这表明，只要 PTO 大于 0，延迟开始增加，因为 Sync 参考点只有在最后一次可能的数据传输之后才能出现，对于 p1来说，这是在 Event x+1 中。

图 4.29 显示了将 Subevent 的数量增加到 5 时会发生什么。此处，IRC 仍为 3，但由于NSE 为 5，因此提供了两个子事件，这些子事件与未来 BIS 事件的数据相关联。这些用于从事件 x+1 和事件 x+2 预传输数据包。这意味着传输分布在更多的同步间隔中，数据来自三个连续的 BIS 事件。这有助于提供针对可能持续多个同步间隔的宽带干扰突发的稳健性，但代价是更大的延迟，延迟又增加了 10 毫秒。 

图 4.30 通过将 PreTransmission Offset 增加到 2 来进一步扩展的情况。这导致包含来自 x+2 BIS 事件和 x+4 BIS 事件的数据，有效地将音频数据传输分散到五个事件中，与PTO = 0 时相比，延迟总共增加了 40 毫秒。在此图中，我们只显示了第一个 BIS 事件 x中组 3 和组 4 的箭头，否则该图将变得非常混乱且难以阅读。 

 最后，在图 4.31 中，我们将 NSE 设置为 6，Burst Number 和 IRC 设置为 2，并将 Pre-Transmission Offset 也是 2。通过这些设置，每个 BIS 事件都包含该 “当前” 事件的两个数据包，一个接一个地传输，如图 4.26 所示，最后两个子事件用于数据包，用于将来的两个事件。因为 BN 为 2，所以 Isochronous Interval 将为 20ms。由于 PTO 为2，p4 和 p5 来自未来的两个同步区间，因此延迟比图 4.28 的简单示例大 50 毫秒。

这些 BIS 参数允许一些非常灵活的传输方案，以应对延迟和稳健性方面的不同要求。但是，这些是 Bluetooth Core Specification 参数，由芯片 Controller 中的调度程序设置。配置 BIG（其中所有 BIS 都具有相同的基本同步参数）时，主机应用程序只能请求重新传输次数（RTN，即 NSE – 1）、SDU 间隔和最大传输延迟。与 CIes 一样，重传号码只是一个建议。由芯片决定如何将这些参数转换为 NSE、BN、IRC 和 PTO 的值。这意味着在不同芯片上运行的同一主机应用程序可能会导致不同的配置。如果广播发射机同时运行其他蓝牙和 Wi-Fi 应用程序，就像智能手机或 PC 一样，这也可能意味着配置可能会因会话而异。

在下一章中，我们将讨论 Quality of Service，我们将了解如何将它们用于不同的广播情况。但是，应用程序开发人员基本上无法访问这些参数，除非芯片供应商提供专有方法来访问它们。

总之，Flush Timeout 和 Pre-Transmission Offset 都会增加延迟。对于 CIS，Flush Timeout 有助于在 Initiator 和 Acceptor 之间共享电池节省，因为使用确认意味着可以关闭事件。使用 BIS 时，如果没有确认，广播发射机必须在每个 Subevent 上发射。PTO通过提供多样化的传输，使其有最好的机会获取数据包，从而有效地为 Acceptor 节省所有电量。但是，这些节省需要通过对延迟的影响来平衡。请注意，这种平衡是由Initiator 决定的，因此广播发射机的设计人员需要考虑他们的选择对 Acceptor 的影响，因为它们可能会影响他们的电池寿命。同样，Acceptor 的设计者需要了解 Broadcast Transmitter 可能向他们抛出的方案范围。

4.4.3 Control 子事件

控制子事件 [BluetoothCore 规范，第 6 卷，B，4.4.6.7] 通常是一个罕见的事件，不需要包含在每个 BIG 事件中。通常，Control Subevent 用于声道映射更新等项目，因此仅在需要将该信息提供给接收广播音频流的所有设备时偶尔发生。使用 Control Subevents的优点是设备不再需要扫描来查找基本的 BIG 信息，例如正在使用的跳频通道。这最大限度地减少了接收器为确保其与 BIG 及其中的 BIS 保持同步而必须做的工作量。没有它们，Broadcast Sink 将需要继续广播接收器需要继续接收定期广告列车，并定期检查 BIGInfo 以发现任何更改。这几乎肯定会导致同步在跳跃序列更改时丢失一段时间。广播接收器可以持续监控 BIGInfo 以查找更改，但这是不可取的，因为会消耗电池。因此，Control 子事件的原因。

使用控制子事件时，它将在六个连续的 BIG 事件中传输。然后，它可以在任何后续的 BIG事件中传输，但一次只能传输一个控制事件 - 不允许交错不同的控制子事件。在包含控制子事件的 BIG 事件中，BIS 子事件的每个 BIS 标头都必须将控制子事件传输标志（CSTF） 设置为 1，以表示该 BIG 事件中存在控制子事件。其控制子事件序列号（CSSN） 将告诉接收者是否与他们已经接收到的子事件相同。它在包含新控制 PDU 的BIG 事件开始时递增 1（7 换行为 0）。Control 事件使用与所有其他 Subevent 相同的跳频方案，采用同一 BIG 事件中第一个 BIS 事件的索引。

目前，为 Control Subevent 定义的唯一用途是更新广播传输的跳转序列。打算更新其跳频序列的广播发射机将需要使用它，否则当跳频序列更改时，接收器将失去同步，并且需要重新同步，从而导致接收中断。Acceptor 可以通过计算 BIG_Sync_Delay 值是否包括偶尔的 Control Subevent 所需的额外 BIS 事件来确定广播发射机是否支持 Control Subevent。由于 Control Subevent 的长度可变且通常较短，因此它通常对 airtime 的使用影响很小。

4.4.4 BIG 同步

与连接的同步流一样，单个接收设备（通常是一对耳塞或助听器）不一定知道彼此的存在。为了保持音频渲染同步，他们需要使用 BIG 中包含的信息来了解何时需要渲染解码的音频数据包。为了使它们能够做到这一点，定义了一个 BIG Synchronization Point，它与音频数据传输的结束时间相吻合。由于我们在广播中没有要考虑的确认，因此该 BIG 同步点正好位于 BIG 中最后一个 BIS 的最后一次 BIS 传输的末尾。通常，这将与 BIG 活动的结束相吻合。但是，如果存在控制子事件，BIG 同步点将保留在最后一次 BIS 子事件传输的末尾，而 BIG 事件将延伸到控制子事件的末尾，如图 4.32 所示。

在 BIG 同步点，正在侦听该 BIG 中任何广播同步流的每台设备都将知道其他每台设备都已收到其数据;因此 BIG Synchronization Point 是一个固定的时间点，它们都可以在该时间点应用 Presentation Delay。这是在堆栈的较高位置定义的，并指示需要渲染音频的点。

这里需要注意的一点是，音频不是在 BIG 同步点渲染的，而是在 Presentation Delay 的末尾渲染的，该延迟从 BIG 同步点开始。由于广播仅包含来自广播源的传输，因此Presentation Delay 值仅适用于 Broadcast Sink 上的渲染。

4.4.5 用于 BI 的 HCI 命令

与连接的同步流一样，主机应用程序可以定义 SDU 间隔、最大 SDU 大小和最大传输延迟，即允许在 BIS 中传输 SDU 的最长时间。与 CIG 一样，控制器中的调度程序可以使用这些来指导它定义实际的链路层参数，即 NSE、BN、IRC 和 PTO。

设置 BIG 的过程比设置 CIG 简单得多，主要是因为没有与任何接收设备通信。这是广播发射机做出的单方面决定，其中只需要一个 HCI 命令。LE_Create_BIG 命令配置并创建一个 BIG，其中包含Num_BIS数量的 BIS。没有添加或删除单个 BIS 的选项 – 一切都在单个 LE_Create_BIG作中完成。要终止 BIG，LE_Terminate_BIG HCI 命令将结束并删除它。

这两个命令仅适用于 Initiator。如果有足够的资源和通话时间，可以同时创建和传输多个 BIG。这些行为彼此独立。

对于想要从 BIG 中接收一个或多个 BIS 的 Acceptor，有两个类似的命令，这个过程称为与 BIS 同步。它们是 LE_BIG_Create_Sync Command 和 LE_BIG_Terminate_Sync Command。但在我们开始之前，我们需要看看 Acceptor 如何找到 Broadcast Source 并连接到它。

4.4.6 查找广播音频流

当我们查看连接的同步流时，我们没有讨论设备是如何启动连接的。原因是，使用Connected Isochronous Streams 的设备以与其他所有蓝牙 LE 设备完全相同的方式进行连接，使用正常的广告和扫描程序。他们配对、绑定、设置 ACL 链接、发现彼此的功能，然后继续设置流。如果它们是协调集，则 CAP 过程可确保该集的所有成员都应用相同的过程。使用广播音频流时，由于没有连接，因此不会发生任何配对和协商过程。相反，接收设备需要找到一种方法来发现正在发生的事情transmitd，并找出如何与它同步。

执行此作的方法称为扩展广告，已添加到 BluetoothCore 5.0 中。回到基础，图 4.34 显示了用于蓝牙 LE 的通道。对于蓝牙 LE，2.4 GHz 频谱分为 40 个通道，每个通道宽 2MHz。其中三个保留用于固定频率的广告 - 频道 37、38 和 39，被称为主要广告频道。

选择这三个信道的位置是为了避开 Wi-Fi 频谱中最常用的部分。三个广告频道之间是 37个通用频道，编号从 0 到 36，通常用于数据传输。

如果其他设备能够接收其传输，广播源需要提供相当数量的信息。他们不仅需要根据跳频信道告诉接收器传输的位置，还需要提供有关 BIG 及其组成 BIS 结构的所有详细信息，我们刚刚介绍了这些。在许多情况下，可能有多个广播发射机在 Acceptor 的范围内运行，尤其是在公共场所使用它们时，因此有多个广播同步流供该 Acceptor 选择。接受器需要能够区分它们，这意味着广播播发包含有关每个广播流内容的信息。所有这些都需要广播源传达大量信息。要适应三个主要广告渠道，即渠道 37、38 和 39，而不会有使它们超载的风险，这太过分了。

为了克服这一限制，BluetoothCore 5.0 的扩展广告方案允许将广告信息移动到通用频道- 频道 0 到 36。为此，广播源在其主广告中包括一个辅助指针 （AuxPtr），该指针通知设备在通知设备在通用渠道（现在用作 Secondary Advertising 渠道）中提供了更多广告信息。

辅助指针提供扫描设备确定这些辅助通告的位置所需的信息。此时，扫描仪不知道 AuxPtr是用于广播还是其他用途。只有当它找到并读取 Extended Advertisement 时，这一点才会变得明显。图 4.35 说明了此方案的基本结构。 

 

• ADV_EXT_IND：扩展广告指示，使用主要广告渠道。每个 BIG 都需要自己的广告集和 ADV_EXT_IND 。每个 ADV_EXT_IND 的标头包括广告地址 （AdvA）、ADI（包括此扩展集的集 ID）Advertisements） 和指向以下 Auxiliary Pointer 的 Auxiliary Pointer：

• AUX_ADV_IND： Auxiliary Advertising Indications.这些通道通过 37 个通用通道传输。它们包含特定于 BIG 的广告数据，表明它是音频广播，以及由 Public Broadcast Profile 定义的一些高级信息（我们稍后会介绍）。

ADV_EXT_IND数据包中存在辅助指针 （AuxPtr） 表示可以在扩展通告中找到部分或全部通告数据。但是，描述和定位广播流所需的信息量仍然大于通常适合扩展广告数据包的信息量。为了适应这种情况，扩展通告可以通过将 AuxPtr 包含到辅助 AUX_CHAIN_IND PDU 来链接更多数据包，但它不会。相反，它会设置一个定期广告队列，其中包括有关 BIG 及其BIS 的所有信息，这些序列位于AUX_SYNC_IND PDU – 辅助同步信息，即定期通告。

该AUX_ADV_IND包括一个 SyncInfo 字段，该字段告诉扫描程序如何查找 Periodic Advertising。定期广告的结构如图 4.36 所示。

这些广告包含两条重要信息。第一个是 Additional Controller Advertising Data 字段（ACAD）。这是接收设备的控制器所需的信息，用于描述 BIG 及其组成 BIS 的结构。第二个是接收设备的 Host 的信息，包含在 AdvData 字段中。这包括基本音频公告服务UUID 和 BASE，其中包含 BIG 中流的详细定义，包括编解码器配置和元数据，它们以用户可读的格式描述音频流的使用案例和内容。

定期广告系列中的AUX_SYNC_IND数据包会定期传输，因此一旦扫描设备找到它们，它就可以继续跟踪它们，而无需返回主或扩展通告，从而节省电量。广播源可以关闭其扩展通告，但保持定期通告列车运行。

回顾此过程的工作原理，查找和接收广播音频流所需的数据从 Extended Advertisement开始。该AUX_ADV_IND包含广播音频公告服务 UUID，该 UUID 将扩展通告标识为属于特定广播音频流，并使用 3 个八位字节Broadcast_ID标识它。Broadcast_ID在 BIG 的整个生命周期内保持不变。AUX_EXT_IND可能包含来自顶级配置文件的其他服务 UUID。这些允许扫描设备尽早过滤它找到的不同广播，这样它就不需要与 PA 同步并解码它携带的信息，以获取它不感兴趣的广播。该功能对于帮助选择公共广播特别有用，这些广播是这些内容在公共广播配置文件 （PBP） 中定义，PBP 定义公共广播公告 UUID。

在确定它喜欢 BIG 的外观后，扫描仪将与定期广告列车同步。这些通告使用通用通道 0 到 36。与扩展通告一样，如果需要，可以使用另一个 AuxPtr 将它们链接起来以包含更多数据。对于广播音频，它们包含两条重要信息。

第一个是 Additional Controller Advertising Data 字段，即 ACAD。ACAD 包含广告数据结构。这些是包含广告数据 （AD） 类型及其关联数据的数据结构。所有正在主动广播的设备都将使用 ACAD 发送 BIGInfo 结构，该结构提供接收设备检测广播和了解 BIS 计时所需的所有信息。这是将在 CIG 中传递给链路层接受器的信息，但在广播中没有直接连接，这是不可能的。因此有了这种替代方法。

图 4.37 显示了 BIGInfo 的结构。它从 BIG_Offset 开始，它准确地通知设备在哪里可以找到与此 AUX_SYNC_IND PDU 相关的 BIG。接下来，BIGInfo 描述了该 BIG 的结构：

• 基本间隔 – ISO_Interval、Sub_Interval 和 BIS 间隔

• BIG （Num_BIS） 中BIS 的数量及其特性 - NSE、突发数、PTO、IRC 和成帧，

• 数据包信息 - Max_PDU、SDU_Interval、Max_SDU 和 bisPayloadCount。 

• 物理信道访问信息，以 SeedAccessAddress、BaseCRCInit、信道映射 （ChM）和 PHY 的形式，以及

• 组初始化向量 （GIV） 和组会话密钥派生 （GSKD） 的形式，以允许对加密的广播流进行解码。如果存在最后两个字段，则扫描设备知道广播已加密，这意味着它需要获取 Broadcast_Code（如下所述）来解密音频流。

GIV 和 GSKD 的存在是判断 BIG 是否包含加密 BIS 的简单方法。如果 BIS 不存在，则BIGInfo 会更短，表示 BIS 未加密。

在我们离开 BIGInfo 之前，有一件重要的事情要重复一遍，那就是所有的 BIS 都有完全相同的参数。这与 CIG 形成鲜明对比，在 CIG 中，多个 CI可以具有不同的参数。在 BIG中，一个设置适用于正在使用的每个 BIS，必须指定该设置以满足不同 BIS 的最高要求。

唯一的例外是 Control Subevent。它们具有可变长度，由其 BIS PDU 接头描述。BIG 的结构必须考虑到任何 Control Subevent 的最大预期大小（可能大于 BIS 中的音频数据PDU）。

4.4.7 同步到广播音频流

获得 BIGInfo 后，设备可以使用此信息来找出这些 BIS 的位置。BIG_Offset 与BIG_Offset_Units 一起告诉接收器在 BIGInfo 数据包开始后第一个 BIS 的锚点将位于何处（请记住，对于广播，没有 ACL 来提供计时时刻，就像 CIS 一样）。图 4.38 显示了如何使用此信息。

Acceptor 可以在 BIG 中接收任意数量的 BIS。在蓝牙 LE Audio 中，这称为与 BIG 或BIS 同步。在大多数现实生活中，Broadcast Sink 不希望与所有 BIS 同步。耳塞或助听器通常只想与 BIG 的左、右或单声道音频流同步，即使这三个音频流都存在于 BIG 中，而一副耳机则希望与左侧音频流同步而一副耳机希望同时与左声道和右声道同步。

要确定要连接到哪些 BIS 或 BIS，扫描设备需要查看 PDU 定期通告中包含的第二个重要信息AUX_SYNC_IND该信息。这是广播音频源终端节点结构 （BASE），它包含在每个 AUX_SYNC_IND PDU 的 AdvData 字段中，遵循基本音频公告服务 UUID。

4.4.8 BASE – 广播音频源终端节点结构

要了解 BASE，我们需要进入 Basic Audio Profile，这是我们在 Generic Audio Framework （GAF） 中遇到的第一个配置文件。它是配置和管理音频流的关键配置文件，适用于连接的同步流和广播同步流。

BIGInfo 描述了 BIG 的结构，告诉设备它包含多少个 BIS 以及在哪里可以找到它们，但这只是关于它们存在的事实的实际信息。它不提供任何关于广播音频流中的内容或不同 BIS如何相互关联的信息。BASE 提供该详细信息，告诉设备每个 BIS 中包含哪些音频信息及其配置方式。如果范围内有多个广播源，如果接收器能够选择它收听的广播源，这一点至关重要。BASE 由三个级别的信息组成，如图 4.39 所示。当我们在第 8 章中了解如何设置Broadcast Stream 时，我们将更详细地重新讨论这一点。 

最高级别 – 级别 1，提供对 BIG 中的每个 BIS 都有效的信息 – a single Presentation Delay 和组成 BIS 划分为的 Subgroups 的数量。这些子组包含具有共同特征的 BIS，这些特征可能是它们的编码方式或音频流的语言。

每个子组在 BASE 的第 2 级中有更详细的描述，其中为该子组中的 BIS 提供编解码器信息，以及以 LTV 结构形式提供的流元数据。其中大部分是人类可读形式的数据字符串，例如节目信息，建议元数据至少包含广播名称，以便能够显示它的扫描设备可以使用它来帮助用户在不同的音频流之间进行选择。这也是提供语言 LTV 的地方。

最后，BASE 的第 3 级为每个 BIS 提供特定信息。这包括其 BIS_Index（标识它在 BIG中的显示顺序）以及其 Audio_Channel_Allocation LTV（标识它所代表的音频位置），例如左、右或单声道。级别 3 可以包含特定 BI 的一组不同的编解码器信息，这将覆盖级别 2 的子组值。通常，任何具有不同编解码器参数的 BIS 都会被放置在单独的子组中。如果它涉及不同的采样频率，通常将其放入单独的 BIG 中会更有效。

BASE 中包含的信息允许广播接收器确定它是否要接收 BIG，以及它想要同步到该 BIG 中包含的哪些 BIS，并告诉它该特定 BIS 在整个 BIG 中的位置。解析完 BIGInfo 和 BASE后， Acceptor 就拥有了同步到任何 BIS 所需的所有信息 在大多数情况下，广播源将仅传输单个 BIG，但可以传输多个 BIG。这可能发生在公共信息广播中，其中不同类型的消息可能包含在不同的 BIG 中。例如，机场可能使用一个BIG 来发布航班公告，第二个 BIG 用于一般安全公告，第三个加密的 BIG 用于员工公告。在这种情况下，每个 BIG 将有自己的一组主要广告，每个广告都有不同的广告集 ID（SID），以及包含其特定 Broadcast_ID BIGInfo 和 BASE 的扩展广告序列（参见图4.40）。

SID 不应经常更改 - 在设备经历电源循环之前，它通常是静态的，并且通常终身保持静态。至少在 BIG 的使用寿命内，Broadcast_ID 是静态的。广播接收器可以利用这些 ID重新连接到它们知道的广播源（如果它们识别 SID 和 Broadcast_ID）。

Broadcast Source 和 Broadcast Sink 之间没有任何连接，这意味着发射机不知道它们的功能。这可能会导致广播源选择本地接收器无法支持的参数。设计人员需要了解Broadcast Transmitter 计划支持的设备的可能功能，特别是在编解码器设置和Presentation Delay 的值方面。蓝牙 SIG 发布的公共广播配置文件 （PBP） 和 Auracast™ 简单发射器最佳实践指南包含有助于确保互作性的建议，特别是对于公共广播应用程序。它们是产品设计人员的良好起点。

4.4.9 帮助查找广播

预期广播音频的使用方式将与单播音频截然不同。助听器行业热衷于使用蓝牙 LE Audio 广播来补充和扩展当前的拾音线圈基础设施，使场馆的安装更具成本效益。今天，大多数拾音线圈用于扩声，特别是对于佩戴助听器的人。未来，由于消费类耳塞和耳机可以接收相同的广播传输，因此可能会部署更多的公共音频信息服务，因为它们增强了每个人的可访问性。

蓝牙 LE Audio 广播也有可能成为电视的标准配置，无论是在健身房和酒吧等公共场所，还是在家中。Bluetooth SIG 的 Auracast™ 计划正在将广播作为咖啡馆共享音乐和个人音乐的解决方案进行推广。

如果市场以这种方式发展，用户通常会发现自己处于多个广播源的范围内，这意味着他们需要选择要接收的广播源。AUX_ADV_IND数据包中的配置文件 UUID 可能提供第一级选择，但设备仍需要检测和解析每个 BIG 的 BASE 信息才能做出决策。（在早期，可以选择您找到的第一个 BIG，然后按一个按钮移动到下一个，但从长远来看，这不是可扩展的用户体验。这给产品设计师带来了一个问题，因为像耳塞这样的设备没有空间放置显示器，而且通常几乎没有空间放置任何按钮。此外，扫描过程相对耗电——持续扫描会对耳塞或助听器的电池寿命产生明显影响。

为了解决这一限制，蓝牙 LE Audio 规范引入了 Commander 的概念，即代表其 Acceptor执行扫描作的角色。它允许用户选择广播，然后指示接收设备与选定的 BIS 或 BIS 同步。Commander 角色可以作为手机、智能手表、耳塞盒或专用远程控制设备中应用程序的一部分实现。事实上，任何与 Broadcast Sink 连接的蓝牙 LE 设备都可以充当 Commander。实现 Commander 角色的设备称为广播助理，在广播音频扫描服务 （BASS）中定义。它们可以集成到电视等设备中，以帮助自动连接到耳塞和耳机。

4.4.10 定期广告同步传输 – PAST

广播助理扫描指示存在扩展广告的广告，其方式与任何其他扫描设备完全相同。一旦发现它们，它就可以同步到关联的定期广告序列，其中包含广播音频公告服务 UUID，然后发现随附的 BIGInfo 和 BASE 结构。在读取和解析找到的 BASE 元数据之前，它可能会对其扫描应用过滤器，然后它向用户提供可用广播流的列表，通常通过显示人类可读的广播名称。

用户做出选择后，广播助理将使用 PAST 程序向广播接收器提供查找相关定期广播列车所需的信息。这允许广播接收器直接跳转到这些广告数据包，获取 BIGInfo 和 BASE 并同步到适当的 BIS，而无需在扫描中花费精力。此过程称为定期广告同步传输或 PAST，在BluetoothCore 规范 Vol 6，B 部分，5.1.13 中定义。

广播助理向用户提供的信息级别完全取决于实现。手机应用程序可以列出范围内的每个广播源;它可以根据用户偏好限制显示的信息量，或者使用从一组耳塞中读取的预配置设置。

Broadcast Assistant 同样可以是手表或健身手环上的一个按钮，它可以从找到的Broadcast Sources 列表中选择最后一个已知的同步流。广播助理还可以包括应用程序，用于获取解密私有加密广播所需的Broadcast_Code，方法是通过与广播源或代理建立蓝牙连接，或者使用带外 （OOB） 方法，例如扫描 QR 码。

4.4.11 Broadcast_Code

加密流在蓝牙技术中并不新鲜;安全性和机密性一直是规范的重要组成部分。但是，在发送和接收设备之间没有连接时实施加密（如蓝牙 LE Audio 中的广播流）会引入一个新问题，即如何获取加密密钥。

许多广播流不会加密;它们将公开广播，以便任何人都可以接收它们。但是，这会产生一些问题。首先，任何在范围内的人都可以接收它们。由于蓝牙技术在穿墙方面非常有效，因此在会议室、酒店房间甚至家中都可能是一个问题，因为相邻房间的人可能会无意中从您的电视中拾取音频。这可能从烦人到尴尬不等，具体取决于内容是什么。在商业环境中，它很可能是机密的，因此添加加密至关重要。基本的机密性是感应线圈系统固有的，因为音频传输只能在感应线圈的范围内拾取。为了在蓝牙 LE 音频广播中提供相同级别的身份验证，需要对音频数据进行加密，这需要接收器获取解密密钥，即 Broadcast_Code。

查找广播的设备可以通过检查定期广告链中 BIGInfo 的长度来检测广播音频流是否被加密。如果流已加密，则数据包将包含额外的 24 个八位字节，其中包含一个组初始化向量（GIV） 和一个组会话密钥多样化器 （GSKD）。扫描程序将检测它们的存在，并结合其他元数据来确定是否与此类流同步，具体取决于它们是否能够检索Broadcast_Code。

尽管广播不需要广播源和接收器配对，但在许多情况下会存在 ACL 连接。这听起来可能很奇怪，但这种安排允许加密连接的数量远远超过单播所能达到的水平，而不会达到通话时间限制。预计这将是大多数家用电视的工作方式，这样邻居就听不到你正在听的内容，但有多个授权听众可以同时听到音频。在这种情况下，用户将与电视配对，使用 BASS 的功能来获得Broadcast_Code。Broadcast_Code 是 Host 应用程序的属性。Host 在设置 BIS 时将其提供给 Controller，并且它同样可以将其提供给受信任的设备。在公共场所、会议室和酒店中，可能会使用带外方法，这可能类似于用于连接到 Wi-Fi 接入点的打印信息。

Broadcast_Codes也可以通过其他带外方法获得，例如扫描二维码、点击 NFC 终端，甚至包含在可下载的剧院门票中。我们将在第 12 章和第 14 章中更详细地探讨这些配置请注意，用于描述广告数据包中的广播的元数据未加密。因此，应注意确保它不包含机密或可能令人尴尬的信息。

4.4.12 广播拓扑

Bluetooth LE Audio 中包含的功能为查找广播提供了多种选项。我们将在后面的章节中更详细地介绍它们，但下图显示了一些常见的。在大多数情况下，它们显示单个“广播信息”流，其中包含所有广告信息。

最简单的情况，一副耳机会自行扫描以查找和选择广播音频流，如图 4.41 所示。 

图 4.42 本质上是相同的，但指出 Broadcast Sink 也可以是一部手机。在这里，它可以扫描广播源，向用户显示广播音频流的可用选项，然后将音频渲染到一副有线耳机。它同样可以使用蓝牙（蓝牙经典音频或蓝牙 LE 音频）传输流，尽管这不太可能有效利用通话时间。 

图 4.43 显示了预期的最常见用例，其中电话、手表或遥控器等设备充当广播助理，扫描广播音频流并将其选择呈现给用户，然后使用 PAST（定期广告同步传输功能）允许用户的耳机或耳塞连接到选定的流。正如我们将看到的，Broadcast Assistant 还可用于音量控制和静音，允许用户查找、选择和控制广播音频流的渲染。图 4.44 对此进行了说明，该图显示了如何使用手机上的应用程序来显示和选择广播流，以及控制一对耳塞的音量和平衡。 

尽管音频流的广播源和广播接收器之间没有连接，但设备可以使用 ACL 连接来帮助同步到BIS。这方面的一个例子是家用电视，它使用加密的广播音频来允许房间中的多人连接到它。为了实现这一点，电视将包括一个广播助手，它将与每个用户的耳机配对，如图 4.45 所示。当用户选择连接到电视时，广播助理将提供如何使用 PAST 同步到 BIS 以及传输 Broadcast_Code的详细信息。这可以通过按下耳机上的 按钮来实现，或者只需靠近即可实现，因为用户位于电视广播助手的范围内。

这是构成音频共享基础的拓扑之一，其中许多朋友可以从一部手机共享音乐。Chapter 12 更详细地解释了这些选项。 

4.5 ISOAL – 同步适应层

ISOAL [BluetoothCore 规范第 6 卷，G 部分] 是同步流功能最复杂的方面之一。好消息是它在蓝牙芯片中为您照顾，但了解它为什么是必要的以及它的作用是有用的。ISOAL 用于广播和单播音频流。

ISOAL 的存在是为了解决当用于连接到 Initiator 的不同设备的传输间隔不匹配时会发生什么问题。最常见的原因是 Acceptor 仅支持 10ms 的帧大小（它希望使用 10ms 同步间隔），但 Initiator 需要使用 7.5ms 的间隔，因为它正在运行与其他蓝牙设备的连接，例如较旧的鼠标和键盘，这些设备只能以 7.5ms 的时间间隔运行。随着新的外围设备变得更加灵活，这种情况会随着时间的推移而改变，但在此之前，ISOAL 提供了一种在整个蓝牙生态系统迁移到 10 毫秒时间间隔时容纳它们的方法。

ISOAL 层位于 codec 和 Link Layer 之间的数据路径中。如果编解码器是在 Host 中实现的，则可以通过 HCI 或通过专有接口（无论编解码器位于何处）交付来自编解码器的编码SDU。如图 4.46 所示，ISOAL 提供分段和重组或分段和重组，并负责在有帧或未成帧 PDU中发送编码的音频数据。

根据 Host 层提供的设置，Controller 可以决定是使用有帧还是无帧 PDU。对于未成帧的PDU，如果 SDU 可以安装在单个 PDU 中，则同步自适应管理器可能会对它们进行分段，但会在没有分段标头的情况下发送它们。这是传输同步数据的最有效、延迟最低的方式。如果 SDU 大于 Maximum PDU size（最大 PDU 大小），它将被分段并在多个未成帧 PDU 中发送。重组或重组过程会将它们重新组装回 SDU 中。仅当 ISO_Interval等于或是SDU_Interval 的整数倍时，才能使用无帧 PDU，而 PDU 本身等于采样帧或采样帧的整数倍。这意味着 SDU 的生成需要与传输时序同步，以便它们不会彼此漂移。否则，您需要使用成帧 SDU。

对于成帧 SDU，同步自适应管理器会添加分段标头和可选Time_Offset。该 Time_Offset允许在 PDU 之间对多个 SDU 进行分段，从而提供一个参考时间，以保持 SDU 生成和传输时序之间的关联。如果您需要更多详细信息，ISOAL 的完整规范包含在 BluetoothCore 规范的第 6 卷 G 部分第 6 节中。

设计人员需要了解的 ISOAL 的主要方面是 BluetoothCore 规范的这一部分包含定义 Transport_Delay 的方程集。Transport_Delay是整体延迟的关键组成部分，即 SDU 被呈现进行传输与它准备好在适当的 Synchronization Reference 处进行解码之间的时间。

• 对于成帧 SDU，CIG 传输延迟为：Transport_Latency = CIG_Sync_Delay + FT × ISO_Interval + SDU_Interval需要使用 CIG_Sync_Delay、FT 和 SDU_Interval 的相应值分别计算 Central to Peris和Peripheral to Central 方向。

• 对于使用成帧 SDU 的 BIG，Transport_Latency = BIG_Sync_Delay + （PTO × （NSE÷BN–IRC）） × ISO_Interval + ISO_Interval + SDU_Interval

• 对于未成帧的 SDU，计算略有不同。对于 CIG： Transport_Latency = CIG_Sync_Delay + FT × ISO_Interval - SDU_Interval同样，您需要将 CIG_Sync_Delay、FT 和 SDU_Interval 的相应值用于 Central to Peripheral 和 Peripheral to Central 方向。