第11章-顶层蓝牙® LE Audio profile

机器翻译结果，仅用于学习，不喜勿喷，原文档链接。

在介绍了通用音频框架中的所有内容之后，我们现在来到了LE audio 的上层profile。尽管它们仍被称为profile，但在大多数情况下，它们比我们讨论过的底层profile或蓝牙经典音频profile要简单得多。它们通常不定义程序，而是将自己限制在配置、指定强制组合可选功能的新角色，以及添加超出 BAP 的 QoS 要求。在这样做的过程中，他们通过定义功能组合来满足常见的用例来提高标准。

在本章中，我们将了解这些profile包含的内容。由于它们依赖于 GAF spec中已经定义的特性，它们没有补充服务spec。 HAP –Public Broadcast Profile 是个例外，因为相应的听力访问服务为助听器引入了新的预设特征。 TMAP——电话媒体和音频profile有一个名义上的 TMAS 服务，它包含在 TMAP spec中。公共广播profile没有服务。这是广播应用程序固有的异常，它不期望在Initiator 和Acceptor之间建立连接。缺少连接意味着不可能存在client-server关系，因此没有机会提供服务spec。

蓝牙工作组目前正在开发一些上层profile，但计划采用的前三个profile是：

• HAP 和 HAS – Hearing Access Profile and Service ，它定义了旨在用于助听器生态系统的产品的要求。
• TMAP – Telephony and Media Audio Profile 。这旨在涵盖经典 HFP 和 A2DP profile的主要功能，并添加由LE audio 拓扑产生的新功能。
• PBP – Public Broadcast Profile ，它是LE audio 共享用例的基础（参见第 12 章）。它标识广播音频流可以被任何LE audio acceptor接收。

这些以草稿形式公开提供，但仍可能发生变化。本章的内容反映了它们在撰写本文时的状态，记录在第 13.2.2 节中。

由于整个LE audio 的开发都是由助听器行业开始的，所以从 HAP 和 HAS 开始似乎是公平的。

11.1 HAPS - Hearing Access Profile and Service

听力访问profile和服务旨在满足助听器生态系统中使用的设备的要求，包括助听器、为助听器提供音频流的产品以及用于控制助听器的附件。

助听器与耳塞和其他acceptor不同，因为它们始终处于开启状态，捕捉和处理环境声音以帮助佩戴者。这意味着驱动听力访问profile的所有用例都将LE audio 设想为环境音频的附加音频流。这使它们与众不同，因为蓝牙连接并不是购买它们的事实原因。它们的不同之处还在于，佩戴它们的每个人都有听力损失，因此它们在音频质量（以及因此 QoS 设置）和电池寿命之间的要求不同。白天把助听器拿出来给它充电是一个比耳塞佩戴者更重要的动作，因为你在这段时间可能听不到声音。提高音频质量会增加功耗，因此听力访问profile对 BAP 规定的设置没有额外的 QoS 要求，使用语音的 16_2 LC3 编解码器设置（16kHz 采样率，7 kHz 带宽）和音乐的 24_2 编解码器设置（24 kHz 采样率，11 kHz 带宽）。由于许多助听器不会遮挡耳朵，因此除了蓝牙流外，还可以听到环境声音。出于这个原因，助听器通常更喜欢使用低延迟 QoS 设置来避免环境和传输声音之间的回声。

HAP spec描述了被认为是助听器的产品的物理设备配置。该profile定义了四种不同的acceptor配置，所有这些配置都包含在文档中的通用术语“助听器”中。这些是

• 单个助听器，呈现单个LE audio 流，
• 单个助听器接收单独的左右音频流并将解码的音频组合到单个音频通道中，
• 一对助听器（也称为双耳助听器），它们是协调组的成员，为每只耳朵支持单独的左右音频通道，以及
• 一种助听器，使用单个蓝牙链接，但为每只耳朵提供单独的左右音频输出。这些被称为带状助听器，每只耳朵的助听器和蓝牙收发器之间都有有线连接，蓝牙收发器通常位于颈带或头戴式耳机中。

听力访问profile为助听器生态系统定义了四种不同的角色：

• HA（Hearing Aid），是上述四种助听器中的任何一种。
• HAUC（Hearing Aid Unicast Client），它是一个可以与助听器建立单播音频流的Initiator 。单播音频流可以是单向或双向的。
• HABS（Hearing Aid Broadcast Sender），它是发送广播音频流的Initiator ，以及
• HARC（Hearing Aid Remote Controller），这是一种控制音量的设备电平、静音状态和助听器预设（我们稍后会介绍）。

Hearing Access Profile的大部分列出了不同产品迭代所需的 BAP 和 CAP 功能的强制组合。虽然许多是显而易见的，例如将一对助听器的 CSIS 大小特性设置为 2，但它们确保任何声称支持该profile的产品都将包含相同的特性并且是可互操作的。这本质上是低功耗蓝牙音频上层profile的重点——通过明确指定必须存在哪些底层profile、服务和功能，确保特定用例的互操作性。

有限制。每个助听器都必须能够接收符合 BAP 强制要求的单播或广播音频流，但不需要接收已使用其他可选 QoS 设置进行编码的音频流。它必须接受来自任何支持 HARC 角色的设备的音量控制命令，这可能是独立的远程遥控或手机上的应用程序。这意味着助听器配件将首次在全球范围内与任何品牌的助听器互操作。

所有助听器都需要支持«铃声»、«会话»和«媒体»Context类型，这意味着它们都将支持来电。但是，它们不需要支持呼叫控制或在通话时返回语音流。这是一个实际的决定，因为许多助听器将麦克风放置在用户周围以获得最佳拾音效果，而不是佩戴者的声音，因此用户在通话时使用手机的麦克风通常会更好。这些是制造商在其产品营销中需要传达的限制。

HAP 和 HAS 引入了一个新概念，即对 Presets 的支持。预设是专有的音频处理配置，助听器制造商包括在内，以优化输入耳朵的声音。通常，他们会调整处理以应对不同的环境，例如餐馆、商店、办公室、家庭等。HAP 和 HAS 不会尝试标准化这些设置，而是提供制造商可以映射到其特定实施的编号方案。然后，用户可以按其编号选择特定预设，或循环浏览它们。它包括添加友好名称的功能，以便应用程序可以显示当前预设和其他可用预设。它还支持动态预设，其中预设的Availability可能会根据助听器的状态而改变。例如，当没有可用的感应线圈环路时，为接收感应线圈信号而优化的预设将不可用。预设是目前特定于助听器的功能。有关它们的更多信息，请参阅 HAPS spec。

在 HAS 的预设功能中，有一个有趣的选项，它可能会扩展到其他profile。这是一种使用非蓝牙无线电将命令从一个助听器中继到另一个助听器的能力，而无需commander根据其中一个人的通知向其他集合成员制定程序。这是同步本地操作，它通知commander发送到一个助听器的任何预设命令都可以在本地中继到集合的另一个成员，这在第 3.2.2.8 节中进行了描述 - HAS 的 3.2.2.8。

HAP 的另一个增强功能是包括即时警报服务 [HAP 3.5.3] 的选项。这允许不支持音频流的设备向助听器提供警报，它可以将其作为警报呈现给用户。没有定义具体的用例，但建议制造商可能希望将此功能包含在门铃或微波炉等产品中，以帮助告知助听器佩戴者他们需要做出回应的事情。

HAP 要求的目的是支持为助听器设想的所有用例，如图 11.1 所示。

由于许多助听器用例将涉及用户听到环境声音以及接收到的LE audio 流，因此预计设备将倾向于使用低延迟 QoS 模式。为了帮助确保低延迟，HA 角色中的所有设备都应支持低延迟 QoS 模式的接收和传输的Presentation Delay值 20 毫秒。

听力访问profile中的最后一个细微差别是第 4.1 节中的一组要求，当 HAUC 使用 7.5ms isochronous间隔并且助听器不支持接收 7.5ms LC3 编解码器帧时，这些要求规定了链路层设置。预计这将是助听器具有最小 LC3 实现（因为不强制要求支持 7.5ms 编解码器帧）和initiator被迫使用7.5ms 间隔，因为它的其他外围设备的时间限制，无法容纳首选的 10ms 间隔。在这种情况下，调度程序应确保为 ISOAL 选择指定的参数，以避免 SDU 分段和帧丢失率的潜在增加。随着LE audio 的普及，预计Initiator 将移动到最佳的 10 毫秒传输间隔，因此这是一个短期修复。

所有 HAUC、HA 和 HAB 都必须支持 2M PHY。虽然它的使用不是强制性的，但强烈建议节省空中传输时间，从而延长电池寿命。

11.2 TMAP—Telephony and Media Audio Profile

与 HAP 一样，TMAP profile主要是一个附加要求列表，超出了 BAP 和 CAP 中规定的要求，以模拟 HFP 和 A2DP profile的用例。 TMAP 没有引入任何新的行为或特性，因此在 TMAP 中包含了一个最小的 TMAS 部分。

因为它将电话和媒体应用程序捆绑到一个文档中，所以 TMAP 感觉就像是一个 portmanteau profile，实施者可以广泛地选择他们支持的内容。这可能会导致一些奇怪的事情，因为它的许多功能都是可选的。理论上，根据您的选择，可以制作支持电话但不支持音乐的 TMAP 兼容设备，反之亦然。这是将这么多不同的用例捆绑在一起的逻辑结果。条形音箱或扬声器不支持电话是有道理的，但这意味着耳机也不需要支持电话。相反，由实施者选择合适的特征和角色，让市场达尔文主义来处理任何不吉利的选择。

为了防止任何意外，TMAP 的 TMAS 元素包括一个 TMAP 角色特征 [TMAP 4.7]，它公开了设备支持的特定角色。这允许Acceptor确定Initiator 支持的角色，这是某些用例所必需的。这将我们带到了角色。 TMAP 没有为 Commander 定义任何新的 Roles，而是为 Initiator 和 Acceptor 定义了三对 Roles。

11.2.1 电话角色—呼叫网关和呼叫终端

对于电话，TMAP 定义了呼叫网关 (CG) 和呼叫终端 (CT) 角色。呼叫网关是连接到电话网络的设备，例如电话、平板电脑或 PC，并且是Initiator 。呼叫终端通常是耳机，但也可以是分机扬声器或会议电话的麦克风。一些常见的配置如图 11.2 所示

支持 CG 和 CT 角色的设备必须支持 7.5ms 和 10ms 帧速率（来自 BAP 的 32_1 和 32_2）的 32 kHz 采样的更高编解码器设置，以及低延迟设置。这些对应的音频质量与 3GPP 为 5G 手机指定的超宽带 EVS 语音编解码器相同，确保从本地麦克风到远程耳机的质量不损失，反之亦然。

CG 必须支持 CCP server角色，但不强制要求任何超出 CCP 强制要求的功能。

11.2.2 媒体播放器角色——单播媒体发送者和单播媒体接收者

媒体播放器用例使用单播媒体发送器 (UMS) 和单播媒体接收器 (UMR) 角色。 Unicast Media Sender 是 Initiator，它是音频源，Unicast Media Receiver 是 Acceptor。典型配置如图 11.3 所示。

对于单播媒体，TMAP 提高了音频质量，要求单播媒体接收器支持所有六种 48kHz 采样编解码器配置，从 48_1 到 48_6。单播媒体源必须支持 48_2 编解码器设置和至少一种 48_4 或 48-6 设置。所有 TMAP 角色都必须支持 2M PHY，这几乎肯定是为这些配置找到足够的空中传输时间所必需的。尽管需要支持这些 QoS 配置，但由应用程序决定如何配置 ASE。它可以决定使用较低的值。对于 UMS，32 kHz 采样率仍然是可选的，尽管 Acceptor 不太可能不支持它们。用户不太可能听到 32 和 48kHz 之间的差异，因此设置的选择主要是营销决策。

TMAP 不要求支持«Unspecified»以外的任何Context类型。如果单播媒体接收器想要拒绝从呼叫网关建立流的任何尝试，它应该支持«铃声»，但将其设置为不可用。

TMAP 通过强制支持播放和暂停操作码来增加对媒体控制的要求。 UMS 还必须支持媒体控制点特性。

11.2.3 广播媒体角色——广播媒体发送者和广播媒体接收者

TMAP 中的最后两组角色是广播媒体发送者和广播媒体接收者角色。不出所料，这些都是为广播应用而设计的。在 TMAP 中，它们通常被设想为需要更高音频质量的个人应用程序，但也可用于公共广播应用程序，例如电影院。典型用例如图 11.4 所示。

TMAP 在 BAP 和 CAP 之上为广播角色添加了很少的要求。它要求支持更高质量的 QoS 设置，需要支持广播媒体接收器和 48_1 和 48_2 QoS 的 BAP 表 6.1（48_1_1 到 48_6_1 和 48_1_2 到 48_6_2）中定义的所有低延迟和高可靠性 48 kHz QoS 模式广播媒体发送器的配置。它还要求广播媒体发送器必须支持至少一种 48_3 或 48_5（7.5ms 帧）编解码器配置和 48_4 或 48_6（10ms 帧）编解码器配置之一。

TMAP 要求广播媒体接收器在低延迟和高可靠性 QoS 模式的呈现延迟范围内支持 20 毫秒的呈现延迟值。

TMAP 还增加了对广播音频配置的强制支持，要求广播接收器可以接受 BAP 表 4.24 中定义的任何广播音频配置。这些如表 11.1 所示。 BMS 要求与 BAP 相同。

11.3 Public Broadcast Profile

公共广播profile (PBP) 是一个简单但非常有趣的profile。它旨在支持音频共享用例，保证配置广播音频流，以便任何Acceptor都可以接收它。它包含一个新的 UUID——公共广播服务 UUID，它作为附加服务类型与基本音频公告一起添加。这意味着它出现在 Extended Advertisement 中，允许设备读取它而无需与 Periodic Advertising 序列同步，然后接收和解析 BASE。这减少了扫描仪的工作量，降低了其功耗。本质上，它充当过滤器，广播接收器或广播助手可以使用它来限制其扫描，从而减少识别广播接收器可以解码的广播源所需的功率和时间。

PBP 定义了三个角色——公共广播源 (PBS)、公共广播接收器 (PBK) 和公共广播助理 (PBA)。对 PBK 和 PBA 角色的唯一要求是它们能够识别和解释Extended Adv中的 PBP UUID。

如果关联 BIG 中包含的至少一个 BIS 已使用 BAP 中为广播接收器定义的强制 QoS 设置之一（即 16_2_1、16_2_2、 24_2_1 或 24_2_2。 BIG 可能包含以其他 QoS 设置编码的 BIS，但 PBP UUID 只能在具有这些强制设置的 BIS 处于活动状态时传输。

PBP 的原因是提醒LE audio 接收器注意可以普遍接收的广播音频流。

我们对LE audio spec的介绍到此结束。最后一章将介绍它们启用的一些新应用程序。