LE Audio核心来啦，一文让你彻底了解BAP广播(Broadcast)概念低功耗蓝牙音频Auracast-171主机测评

在无线音频的世界里，一场静默却深刻的革命正在进行。

它，就是LE Audio。

这不仅仅是一次技术迭代，而是从底层重新定义声音如何被创造、传输和体验的范式转移。其复杂性令人敬畏——它并非单一技术，而是一套精密的生态系统：全新的LC3编解码器以超凡效率重塑音质与功耗的平衡，多重串流音频让真无线立体声达到前所未有的稳定与同步，而音频广播功能则打破了“一对一”连接的百年窠臼，让声音如电台般自由播撒。

然而，正是这种复杂性，构成了我们必须深入学习它的不可辩驳的理由。未来的声音图景将由它绘制：从下一代真无线耳机、无障碍助听设备到公共场所的沉浸式音频导览、多语言广播，乃至元宇宙中清晰无缝的语音交互。不了解LE Audio，将意味着在即将到来的音频浪潮中失去对话的基石。

这不仅仅关乎技术本身，更关乎我们如何连接彼此，如何感知世界。让我们共同开启这段探索之旅，揭开LE Audio的复杂面纱，看清它为何必将成为未来数年里，每一个科技从业者、音频爱好者乃至普通用户都无法忽视的关键命题。

接下来的系列文章，我们将逐步拆解这座精妙的技术大厦。

同时我也录制了一系列的Le audio视频，有兴趣的可以咨询，我会带领你们入门Le audio！翻过大山，眼下皆是风景！！！

——————————————————————————————————————————————

视频链接：https://item.taobao.com/item.htm?id=1001969040805&mi_id=000032T4qZX9WZoRwX6YbxlNUaZOfOI6XoxDx0jxsfnwlEc&spm=a21xtw.29178619.0.0

———————————————————————————————————————————

一. 概念

整个BLE广播除了协议外，还有HCI的周期广播的补充，周期广播可以参照以下链接：

https://blog.csdn.net/XiaoXiaoPengBo/article/details/157580815?spm=1001.2014.3001.5501

1. 概念

BAP以及PACS/ASCS/BASS算是整个Le audio中的核心中的核心，在整个le audio的架构如下：

2. BAP角色介绍

另外，我们来介绍下BAP的角色，通过介绍BAP的角色来深化下PACS的概念

BAP定义了六种角色:

单播服务器(Unicast Server), 这个是gatt server端
单播客户端(Unicast Client)，这个是gatt client端
广播源(Broadcast Source)，这个对于gatt没有要求
广播接收器(Broadcast Sink)，这个是gatt sever端
广播助手(Broadcast Assistant),这个是gatt client端
扫描委托器(Scan Delegator)，这个是gatt server端

a. 单播角色

单播音频使用两种BAP角色：单播服务器和单播客户端。

ⅰ. 单播服务器(Unicast Server)

单播服务器发送广播(BLE advertisements)，以便单播客户端发现单播服务器并与之建立连接。单播服务器对外发布属性，供单播客户端发现其支持的音频能力。单播服务器对外发布属性，供单播客户端发现、配置和控制由单播服务器发布的音频流端点。单播服务器对外发布其当前传输或接收单播音频流的可用性状态。单播服务器接受建立包含一个或多个同步连接的同步组，用于传输单播音频流。单播服务器可以终止同步连接。

ⅱ. 单播客户端(Unicast Client)

单播客户端通过扫描广播来发现单播服务器，并与之建立连接。单播客户端发现单播服务器传输或接收单播音频流的可用性。单播客户端发现并使用单播服务器发布的属性，以确定单播服务器的音频能力及支持的音频角色。单播客户端发现用于配置和控制单播服务器所发布的音频流端点的属性。单播客户端配置并建立一个或多个同步组，每个组可包含一个或多个用于传输单播音频流的同步连接。单播客户端可以终止同步连接。

b. 广播角色

广播音频使用四种BAP角色：广播源、广播接收器、广播助手和扫描委托器。

ⅰ. 广播源(Broadcast Source)

广播源配置并建立一个或多个同步广播组，每个组包含一个或多个用于传输广播音频流的同步广播流。广播源发送描述广播音频流配置的数据。广播源发送使设备能够发现和接收广播音频流的数据。

ⅱ. 广播接收器(Broadcast Sink)

广播接收器发现描述广播音频流配置的数据。广播接收器发现并接收广播音频流。广播接收器对外发布其音频能力。

ⅲ. 广播助手(Broadcast Assistant)

广播助手发现广播接收器的音频能力。广播助手发现使设备能够发现和接收广播音频流的数据。广播助手发现描述广播音频流配置的数据。广播助手连接至扫描委托器，并将代表扫描委托器扫描到的数据（包括解密加密广播音频流所必需的广播代码）传输给扫描委托器。广播助手扫描寻求协助的扫描委托器。广播助手请求扫描委托器发现描述广播音频流的数据，并可请求与广播接收器同处一地的扫描委托器接收广播音频流。

ⅳ. 扫描委托器(Scan Delegator)

扫描委托器寻找广播助手设备，代表其执行扫描任务。扫描委托器接收广播助手代表其扫描并传输的数据，包括解密加密广播音频流所必需的广播代码。

我们来看看广播的各个角色的关系

二. 协议支持要求

1. Broadcast Source support requirements

a. 音频配置

b. Audio announcements

在通过AUX_ADV_IND PDU的AdvData字段传输公共广播通告(Public Broadcast Announcements)时， PBS也必须通过AUX_SYNC_IND和/或AUX_CHAIN_IND PDU的AdvData字段传输基本音频通告(Basic Audio Announcements)。

ⅰ. Public Broadcast Announcements

其中Public Broadcast Announcements格式定义如下：

其中Broadcast Audio Announcement Service UUID为：

对于每个广播同步组（BIG），广播源应根据随机数生成要求生成一个广播标识符（Broadcast_ID）。该广播标识符在广播同步组的整个生命周期内不得更改。

我们来看下一个btsnoop

ⅱ. Basic Audio Announcements

BASE结构及其包含的参数具有三个数值层级：

第1级：组级。BIG代表组级别。
第2级：子组级。子组是BIG中存在的一个或多个广播等时流（BIS）的集合。
第3级：BIS级。

其中定义格式如下：

其中Basic Audio Announcement Service UUID为：

我们来举一个例子，虚拟结构如下：

BASE结构的一个逻辑示例如图所示。在图的示例中，广播源是一台电视机，它传输包含四个广播等时流（BIS）的广播同步组（BIG），每个BIS代表不同的语言和音频定位。该结构包含两个子组，每个子组各有两个BIS。

单线边框框表示第1级参数，双线边框框表示第2级参数，三线边框框表示第3级参数。

子组[0]包含两个BIS：BIS_索引[0]（BIS_index 0x01）和BIS_索引[1]（BIS_index 0x02），分别代表子组[0]的媒体内容、西班牙语、左前（FL）和右前（FR）声道。

子组[1]包含两个BIS：BIS_索引[0]（BIS_index 0x03）和BIS_索引[1]（BIS_index 0x04），分别代表子组[1]的媒体内容、英语、左前（FL）和右前（FR）声道。

第2级的编解码器标识（Codec_ID）和编解码器特定配置参数值（采样频率、帧时长、每编解码器帧字节数适用于其定义的相应子组及其包含的各个BIS。

第2级的元数据参数值（流式音频上下文[2]、语言[2]）适用于其定义的相应子组及其包含的各个BIS。

第3级的编解码器特定配置参数值（音频声道分配）适用于其定义的具体BIS_index值，且需叠加第2级已定义的编解码器特定配置参数值共同生效。

对应的格式如下：

三. LC3 codec集成

1. Generic Audio LTV介绍

a. Codec_Specific_Capabilities LTV Structures

这个就是特定的Codec的音频能力，其中LTV模型比较常见，就是length-type-valve哈·

Codec的音频能力包含以下几个方面：

支持的采样率
支持的帧间隔
支持的音频通道个数
支撑的每帧字节数
支持的每个SDU的帧数

这个非常好理解，就是想通信，肯定要协商参数吧？但是你不告知对方你支持哪些参数，怎么协商呢？所以这个就是告知对端支持哪些能力，这个类似于传统蓝牙AVDTP SEP(stream end point)的capability

支持的采样率

支持的帧间隔

支持的音频通道个数

支撑的每帧字节数

支持的每个SDU的帧数

b. Codec_Specific_Configuration LTV structures

采样率

帧间隔

音频通道分配

每帧字节

SDU中的帧

c. Metadata LTV structures

这个就是元数据，其中LTV模型比较常见，就是length-type-valve哈·

metadata包含以下几个方面：

首选音频场景(Preferred_Audio_Contexts)
流媒体音频场景(Streaming_Audio_Contexts)
程序场景(Program_Info)
语言(Language)
CCID列表(CCID_List)
家长分级(Parental_Rating)
程序场景URI(Program_Info_URI)
扩展的Metadata(Extended_Metadata)
厂商自定义(Vendor_Specific)
音频活动状态(Audio_Active_State)
广播音频即时渲染标志(Broadcast_Audio_Immediate_Rendering_Flag)
辅助收听流(Assisted_Listening_Stream)
广播名称(Broadcast_Name)

首选音频场景(Preferred_Audio_Contexts)

有两个byte,其中场景有如下定义

Value 值	Label 标签	Description 描述
0x0000	Prohibited 禁止	Prohibited 禁止
0x0001	Unspecified 未指定	Identifies audio where the use case context does not match any other defined value, or where the context is unknown or cannot be determined. 标识不匹配任何其他定义值、或上下文未知或无法确定的用例场景的音频。
0x0002	Conversational 通话	Conversation between humans, for example, in telephony or video calls, including traditional cellular as well as VoIP and Push-to-Talk. 人与人之间的对话，例如在电话或视频通话中，包括传统蜂窝网络以及VoIP和对讲。
0x0004	Media 媒体	Media, for example, music playback, radio, podcast or movie soundtrack, or tv audio. 媒体音频，例如音乐播放、广播、播客、电影原声或电视音频。
0x0008	Game 游戏	Audio associated with video gaming, for example gaming media; gaming effects; music and in-game voice chat between participants; or a mix of all the above. 与电子游戏相关的音频，例如游戏媒体、游戏音效、参与者之间的游戏内语音聊天，或以上所有内容的混合。
0x0010	Instructional 教学	Instructional audio, for example, in navigation, announcements, or user guidance. 教学音频，例如用于导航、公告或用户引导的音频。
0x0020	Voice Assistants 语音助手	Man-machine communication, for example, with voice recognition or virtual assistants. 人机通信，例如与语音识别或虚拟助手的交互。
0x0040	Live 现场	Live audio, for example, from a microphone where audio is perceived both through a direct acoustic path and through an LE Audio Stream. 现场音频，例如来自麦克风的音频，该音频既通过直接声学路径也通过LE音频流被感知。
0x0080	Sound Effects 音效	Sound effects including keyboard and touch feedback; menu and user interface sounds; and other system sounds. 音效，包括键盘和触摸反馈音、菜单和用户界面音效以及其他系统声音。
0x0100	Notifications 通知	Notification and reminder sounds; attention-seeking audio, for example, in beeps signaling the arrival of a message. 通知和提醒音；用于引起注意的音频，例如表示消息到达的提示音。
0x0200	Ringtone 铃声	Alerts the user to an incoming call, for example, an incoming telephony or video call, including traditional cellular as well as VoIP and Push-to-Talk. 提醒用户有来电的音频，例如来电的电话或视频呼叫，包括传统蜂窝网络以及VoIP和对讲。
0x0400	Alerts 警报	Alarms and timers; immediate alerts, for example, in a critical battery alarm, timer expiry or alarm clock, toaster, cooker, kettle, microwave, etc. 闹钟和定时器；即时警报，例如在电池电量严重不足警报、计时器到期、闹钟、烤面包机、炊具、水壶、微波炉等中。
0x0800	Emergency Alarm 紧急警报	Emergency sounds, for example, fire alarms or other urgent alerts. 紧急声响，例如火警或其他紧急警报。

流媒体音频场景(Streaming_Audio_Contexts)

其中场景如上，我们已经介绍过了

程序场景(Program_Info)

语言(Language)

3个byte的语言码，标准参考ISO 639-3, 比较长，我们不贴了，自己可以去网上查看下

CCID列表(CCID_List)

家长分级(Parental_Rating)

（用于标识媒体内容（如电影、游戏、电视节目）是否适合特定年龄段观众观看的内容分级或评级标签

程序场景URI(Program_Info_URI)

扩展的Metadata(Extended_Metadata)

厂商自定义(Vendor_Specific)

音频活动状态(Audio_Active_State)

广播音频即时渲染标志(Broadcast_Audio_Immediate_Rendering_Flag)

这个术语用于指示接收到的广播音频数据是否应被立即播放/渲染，而无需等待缓冲区填充或额外的同步处理。

辅助收听流(Assisted_Listening_Stream)

此术语特指为听力辅助设备（如助听器）优化传输的音频流，旨在帮助有听力障碍的用户更清晰地收听音频内容。

广播名称(Broadcast_Name)

2. LC3广播播场景

广播的场景一共有三种，广播源位于曲线的左侧，而广播接收器位于曲线的右侧

a. Audio configuration 12

传输方向	BIS数量	音频流数量	音频通道数量	广播接收端设备数量
单向	1	1	1	无限多个

广播接收端产品形态举例: 单声道耳机

b. Audio configuration 13

传输方向	BIS数量	音频流数量	音频通道数量*	广播接收端设备数量
单向	2	2	1	无限多个

广播接收端产品形态举例: TWS耳机

*两个BIS, 每个BIS支持一个音频通道。

c. Audio configuration 14

传输方向	BIS数量	音频流数量	音频通道数量	广播接收端设备数量
单向	1	1	2	无限多个

广播接收端产品形态举例: 立体声耳机

四. Broadcast audio streaming procedures

广播音频流传输涉及一个广播源(Broadcast Source)、零个或多个广播接收器(Broadcast Sinks)、广播助手(Broadcast Assistants)及扫描代理(Scan Delegators)。

本节中广播源对各流程的支持要求定义于表

Procedure 流程	Requirement 要求
Broadcast Audio Stream state management 广播音频流状态管理	M
Broadcast Audio Stream configuration 广播音频流配置	M
Broadcast Audio Stream reconfiguration 广播音频流重新配置	O
Broadcast Audio Stream establishment 广播音频流建立	M
Broadcast Audio Stream Metadata update 广播音频流元数据更新	O
Broadcast Audio Stream disable 广播音频流禁用	M
Broadcast Audio Stream release 广播音频流释放	M

1. Broadcast Audio Streams and advertising PDUs

广播音频流由广播源发送，并利用BIG内的BIS进行传输。在发送广播音频流时，广播源还会发送扩展广播协议数据单元（EA PDUs）和周期广播协议数据单元（PA PDUs）。图展示了广播源所发送的不同数据包的示例示意图。

2. Broadcast Audio Stream state management

广播音频流的控制通过广播音频流状态机及其在广播源上的状态转换来描述。

广播音频流状态机允许广播源以单向无连接的方式与零个或多个广播接收器及/或零个或多个广播助手进行通信。广播音频流由广播源发送。状态机如下：

状态 (State)	描述 (Description)
空闲 (Idle)	未传输任何广播音频流。
已配置 (Configured)	广播源已使用特定于实现的信息或由更高层规范提供的信息，为其控制器配置了广播音频流。广播源传输包含“广播音频通告”）的扩展广播（EA），该通告将周期性广播（PA）与广播音频流关联起来。广播源传输包含“基本音频通告”的周期性广播（PA）。该周期性广播（PA）不得携带设备同步到BIG及其相应BIS所需的BIGInfo数据。当广播音频流状态机处于“已配置”状态时，不得在BIG中发送任何音频数据包。
流传输 (Streaming)	广播音频流已在广播源上建立。广播源传输包含“广播音频通告”的扩展广播（EA），该通告将周期性广播（PA）与广播音频流关联起来，并包含Broadcast_ID，该ID有助于未使用过滤接受列表的设备确定指向目标BIG的PA所对应的EA。不要求连续传输EA。广播源传输包含“基本音频通告”的周期性广播（PA）。不要求连续传输PA。当传输PA时，该PA必须携带同步到BIG及其BIS以及接收广播音频流所需的BIGInfo数据。广播源可以在BIG内的控制分组中传输控制参数

状态机的流转如下：

3. Broadcast Audio Stream configuration

下表展示了本配置文件为广播源（广播音频流的编码与发送）和广播接收器（广播音频流的接收与解码）定义的强制性广播音频流配置支持设置。广播源和广播接收器可支持实现或更高层规范定义的任何其他广播音频流配置设置。

LL层推荐配置如下：

下图是展示一个Broadcast Source Configuring一个广播音频流的图示

a. Broadcast Audio Stream reconfiguration

当广播音频流处于"已配置"状态时，广播源可随时重新配置该广播音频流。

在重新配置广播音频流时,广播源可根据本配置文件或更高层规范的定义,为元数据参数写入任意LTV结构。

广播源可在广播音频流的元数据参数中包含Streaming_Audio_Contexts LTV结构，以告知广播接收器：该广播音频流适用于在Streaming_Audio_Contexts值中任何设置为0b1的位所对应的上下文类型值所描述的使用场景。

广播源应根据Audio announcements 所述，使用代表新配置的参数更新BASE配置。

b. Broadcast Audio Stream establishment

广播源应通过建立广播音频流来启动或恢复广播音频流传输，从而使广播音频流从已配置状态转换到流传输状态。

为建立广播音频流，广播源应首先进入广播等时广播模式。随后进入参考文献[1]第3卷C部分第9.6.1节定义的广播等时可同步模式，并在周期性广播的AUX_SYNC_IND协议数据单元的扩展头字段ACAD域中传输广播音频流同步信息（BIGInfo）。

若音频数据路径尚未建立，广播源应通过设置音频数据路径（最终完成广播音频流的建立。

下图图展示了广播源建立广播音频流的示例流程。

c. Broadcast Audio Stream disable

d. Broadcast Audio Stream release

4. Basic Audio Announcement discovery

基本音频通告（内含广播音频流参数）由广播源发送，并应通过使用观察过程，由广播接收器和/或广播助手发现以下内容：

包含服务数据AD数据类型的EA（扩展广播）。此AD数据类型包含基本音频通告服务UUID和广播ID，以及任何附加服务数据。
同步信息数据，用于实现与承载广播音频流的定期广播的同步。

该定期广播包含服务数据AD数据类型，其中含有基本音频通告服务UUID和BASE配置。该定期广播还可能在AUX_SYNC_IND PDU的扩展报头字段的ACAD字段中包含同步信息（BIGInfo），用以实现对广播音频流的同步。

广播接收器或广播助手应使用定期广播同步建立过程来同步到该定期广播。

图展示了广播接收器或广播助手发现基本音频通告的一个示例。

5. Broadcast Assistant procedures

本节描述了广播助手如何发现与扫描委托器共置的广播接收器的音频能力，以及广播助手如何启动与扫描委托器进行的广播音频扫描控制点[6]操作。

扫描委托器可以是一个独立设备，也可以与广播接收器共置。
广播助手可以是一个独立设备，也可以与广播源共置。

广播接收器能够扫描扩展广播，并能够同步到由广播源发送的定期广播和广播等时流。对于电池容量有限的设备而言，扫描扩展广播可能消耗其电池电量预算的很大一部分。

扫描委托器可以请求广播助手代表扫描委托器扫描扩展广播。这有助于减少扫描委托器自身扫描的需求，从而降低扫描委托器的功耗；此过程称为远程广播扫描。

扫描委托器可以从广播助手接收描述广播等时流的信息，包括解密加密广播等时流所需的密钥（称为广播码）。

扫描委托器可以从广播助手接收同步信息数据的传输；此过程称为扫描卸载，它使用[1]第3卷C部分第9.5.4节中定义的定期广播同步传输过程。

在扫描卸载过程中，扫描委托器通过 LL_PERIODIC_SYNC_IND PDU 接收同步信息数据。LL_PERIODIC_SYNC_IND PDU。扫描委托器可以使用该同步信息数据来同步到某个定期广播，并发现描述广播音频流的任何BASE配置，或发现该定期广播中承载的BIGInfo数据。这使得与扫描委托器共置的广播接收器随后能够同步到承载该广播音频流的广播等时流。

当广播助手与广播源共置时，可以利用广播音频扫描服务来传递以下信息：

由该共置广播源发送的广播音频流信息；
由其他广播源发送的广播音频流信息。

广播助手可以通过向广播音频扫描控制点特征写入[6]中定义的值，来请求扫描委托器添加、更新或移除关于广播音频流的信息。

广播助手可以通过以下方式确定扫描委托器知晓哪些广播音频流：

读取广播接收状态特征值；或
接收广播接收状态特征值的通知。

本节所述流程对广播助手的支持要求在表中定义。

a. Audio Capability Discovery

发现Sink PAC特性可告知广播助手，与扫描委托器共置的广播接收器能够接收并使用表3.17中定义为"强制要求"的设置来解码音频数据。

广播助手可读取Sink PAC特性的值，以发现与扫描委托器共置的广播接收器所支持的、未定义为"强制要求"的音频能力设置（例如，由更高层规范定义的音频能力，或由具体实现定义的供应商特定音频能力）。

广播助手可读取Sink Audio Locations特性的值,以确定与扫描委托器共置的广播接收器所支持的音频位置

b. Solicitation requests

征询请求由扫描委托器使用扩展广播协议数据单元发送。

为发现来自扫描委托器的征询请求，广播助手可以扫描包含广告数据的扩展广播，该广告数据内含有服务数据AD数据类型以及广播音频扫描服务UUID。

图中的示例展示了一个扫描委托器正在征询广播助手。在此示例中，该扫描委托器实现了一个共置的广播接收器。

广播助手可通过执行第Audio Capability Discovery的流程，或通过接收广播接收器公开的Sink PAC特性通知，来确定与扫描委托器共置的广播接收器是否能够解码由广播等时流承载的广播音频流。

广播助手可通过执行Audio Capability Discovery的流程，或通过接收Sink Audio Locations特性通知并将其值与广播源发送的BASE中可能存在的音频通道分配TV结构进行比较，来确定与扫描委托器共置的广播接收器是否能够在指定位置呈现广播音频流。

图中的示例展示了广播助手根据图6.9示例确定与扫描委托器共置的广播接收器的音频能力。请注意，在图示例中，空中接口交换的协议数据单元已进行压缩，以便概括流程及其结果。

c. Remote broadcast scanning

广播助手可启动远程扫描已启动操作，以告知扫描委托器其正在代表扫描委托器扫描广播音频流。

广播助手可启动远程扫描已停止操作，以告知扫描委托器其已停止代表扫描委托器扫描广播音频流。

图中的示例展示了图6.10示例中的广播助手，正通知扫描委托器其正在代表扫描委托器扫描广播音频流。当扫描委托器知晓有广播助手代表其进行扫描时，可选择调整自身的扫描行为；若其原本已在扫描，也可能选择继续自行扫描。具体行为由实现方式决定。

下图中的示例展示了上图示例中的广播助手发现了来自不同设备的两个独立广播源。本例中的广播助手首先发现了扩展广播，随后发现了定期广播，其中包括包含元数据的BASE配置。其中一个广播源的元数据包含Streaming_Audio_Contexts LTV结构，且其"媒体"位的值被设置为0b1。

d. Adding broadcast sources

广播助手可以启动添加源操作。

广播助手应通过读取或接收扫描委托器公开的所有广播接收状态特征值的通知，来确定扫描委托器当前已知的源列表。

如果启动该操作将导致扫描委托器公开的任何广播接收状态特征中Source_Address_Type、Source_Adv_SID 和 Broadcast_ID 字段的组合值出现重复，则广播助手不得启动添加源操作。

如果广播助手尚未确定与扫描委托器共置的广播接收器能够解码该广播源传输的至少一个广播音频流，则广播助手不应启动添加源操作。

启动添加源操作时，广播助手应写入 Advertising_Address_Type、Advertiser_Address、Advertising_SID、Broadcast_ID、PA_Sync、PA_Interval 和 Num_Subgroups 参数的值。如果在启动添加源操作时，广播助手为 Num_Subgroups 参数写入了非零值，则它还必须为每个子组写入 BIS_Sync[i]、Metadata_Length[i] 和 Metadata[i] 参数的值。

当写入 Metadata_Length[i] 和 Metadata[i] 参数值时，广播助手需确定在启动添加源操作时要包含哪些元数据。

添加源操作中的数组参数代表描述 BIG的 BASE 中的子组。

如果广播助手与广播源共置：

如果广播源传输的 ADV_EXT_IND PDU 中的 AdvA 字段包含一个随机私有地址，则广播助手在启动添加源操作时，应将 Advertiser_Address 参数写入该广播源传输的随机私有地址。

如果广播助手不与广播源共置：

如果广播助手从其蓝牙控制器接收到 LE_Extended_Advertising_Report_Event，且其 Address_Type = 0x02 或 0x03，则广播助手应使用 LE_Read_Peer_RPA 命令或其他方法来检索该广播源的随机私有地址。

- 如果广播助手检索到了广播源的随机私有地址，则在启动添加源操作时，应将 Advertiser_Address 参数写入该检索到的随机私有地址。
- 如果广播助手未能检索到广播源的随机私有地址，则应写入全零的 Advertiser_Address。

如果广播助手未收到 Address_Type = 0x02 或 0x03 的 LE_Extended_Advertising_Report_Event，则在启动添加源操作时，广播助手应将 Advertising_Address 参数写入广播源传输的 ADV_EXT_IND PDU 中 AdvA 字段的值。

广播助手不得为超过一个子组的任何 BIS_Sync 参数的 BIS_index 值写入 0b1，除非广播助手为所有这些子组的 BIS_Sync 参数都写入了 0xFFFFFFFF（无偏好）。

图中的示例展示了广播助手向扫描委托器启动添加源操作。