Articles

Discovering Auracast™ – the Public Broadcast Profile

Introducing Bluetooth® LE Audio

Bluetooth LE Audio, or simply LE Audio, is the next generation of Bluetooth audio and is built on Bluetooth Low Energy technology. It was designed from its inception to overcome some of the limitations of Classic Bluetooth Audio. LE Audio includes support for a greater range of topologies and use cases than is possible with Bluetooth Classic profiles like the Advanced Audio Distribution Profile (A2DP) and the Hands-Free Profile (HFP). Another objective was to enable interoperable audio solutions that support single point-to-point, multiple parallel point- to-point, and broadcast audio topologies. A common framework is used by all LE audio profiles, which reduces multi-profile and interoperability issues.

A key component of LE Audio is the Low Complexity Communication Codec (LC3) [15]. LC3 enables high-quality audio to be transmitted in far less bandwidth than the low complexity subband coding (SBC) codec used in classic Bluetooth profiles. LC3 is not discussed in detail in this document.

LE Audio builds on major updates to the Bluetooth Core Specification. Built on this foundation are many new profiles and services, defined in layers, that make up what is commonly called the Generic Audio Framework or GAF. Above GAF are the Application Profiles.

One of the key differences between LE Audio and classic Bluetooth audio is that LE Audio introduces broadcast audio to Bluetooth. With broadcast audio, audio is made available to receiving devices without the need to establish a connection or pair the devices. If the broadcast audio is unencrypted, it is available to an unlimited number of receivers. If the broadcast audio is encrypted, it is available to an unlimited number of receivers that have the encryption key. Users without the encryption key are made aware of the presence of the encrypted audio, and get information about the contents, but cannot listen to the audio itself.

Auracast™ broadcast audio, or simply Auracast™, builds on the broadcast features that LE Audio provides. It isn’t defined in a single spec, but rather, it is defined by the Bluetooth Public Broadcast Profile (PBP) [1] and the brand guidelines for Auracast™ Trademarks [11]. The Bluetooth Special Interest Group (SIG) [13] provides support for registering and identifying locations that support Auracast™ [12], as well as guidelines for deployment of Auracast™ at public locations [10]. This document explores Auracast™ and LE Audio, with particular emphasis on PBP.

Employing Auracast™ and PBP at a Public Location – a Hypothetical Example

To help explore how Auracast™, PBP and LE Audio work together to enable users to listen to broadcast audio in a public space, a hypothetical example is described here. It provides context for the in-depth technical details in the following sections and serves as a backstory for user scenarios used in this document. This example also provides insight into how Auracast™ can be deployed at a place of business.

A hypothetical gym is described that has seen the potential of this technology, foreseen the benefits to their members, and deployed it.

*Figure 1: “PBJ Gym” offering multiple TV screens for viewing.*

In our hypothetical example, the proprietors of the gym are Parker, Bradley, and Johnson, and they cleverly market their gym as the “PBJ Gym.” They have recognized the potential benefits of Auracast™ to their gym members and have provided Auracast™ broadcast audio.

PBJ Gym offers a large number of TVs that are visible to patrons from their exercise equipment. See Figure 1. Auracast™ offers them a way of enabling their customers to listen to the audio from one of six television programs. In addition, with premium membership customers have access to high-quality workout music.

Figure 2 presents how Auracast™ transmitters, described in the Auracast™ Simple Transmitter Best Practices Guide [9], were professionally installed by a third party to work with their existing TVs. An Auracast™ transmitter is a type of device that is used to take the audio output from a device and transmit it as broadcast audio. The installers also added two workout music programs that are available for premium members. This was a new feature intended to encourage members to step up to premium memberships, and serves as a way for PBJ Gym to generate additional revenue for their investment in Auracast™.

*Figure 2: Configuration of Auracast™ transmitters*

Six TVs, one for each of the six available TVs, was connected to a dedicated Auracast™ transmitter. For the two premium music programs, the installer configured a facility PC with custom software to drive two dedicated Auracast™ transmitters, one for each workout music program. In total, eight broadcast audio programs are available.

Audio Source	Description	Broadcast Name	Audio Configuration
TV 1	Internal	PBJ Gym TV 1	24 kHz Low Latency Stereo English
TV 2	Sports	PBJ Gym TV 2	24 kHz Low Latency Stereo English and Spanish
TV 3	Network	PBJ Gym TV 3	24 kHz Low Latency Stereo English and Spanish
TV 4	Network	PBJ Gym TV 4	24 kHz Low Latency Stereo English and Spanish
TV 5	Documentaries	PBJ Gym TV 5	16 kHz Low Latency Stereo English and Spanish
TV 6	Sports	PBJ Gym TV 6	24 kHz Low Latency Stereo English and Spanish
Music from PC	Workout	PBJ Gym Workout Music	48 kHz High Reliability Stereo, 24 kHz Low Latency Mono
Music from PC	Intense Workout	PBJ Gym High-Intensity Music	48 kHz High Reliability Stereo, 24 kHz Low Latency Mono

Table 1: Configuration of audio broadcasts

Table 1 gives a description of the eight programs and how they are configured for Auracast™. This information will drive user scenario examples later.

The installers installed and configured the Auracast™ transmitters in accordance with the Auracast™Transmitter Best Practices Guide [9] and per the Bluetooth guidelines for AAuracast™ public locations website [10]. They applied the Auracast™ logo shown in Figure 3 to all the entrances to the gym in accordance with the Public Location Brand Guide for Auracast™ Trademarks [11]. Once all the requirements to be a registered Auracast™ location were met, PBJ Gym was registered as an Auracast™ location at the Auracast™ Locations Registration website [12].

*Figure 3: Auracast™ logo on display at PBJ Gym*

LE Audio and the Public Broadcast Profile

PBP and LE Audio build on key features added to the Bluetooth Core Specification, which will be referred to as “Core” for brevity, in the rest of this document. PBP and LE Audio specifically rely on Core features beginning with Bluetooth Low Energy, adopted in v4.0. Table 2 identifies the Core features that are required by, or are recommended for use with, PBP.

Core Version	Feature	Description
v4.0	Legacy advertising	Allows advertiser devices to advertise up to 31- octet data packets to nearby devices on the primary advertising channels.
Addendum 2	Appearance Data Type	Allows a device to identify its appearance. Useful for displaying icons to a user that represents the device.
v5.0	LE 2M PHY	Provides a bit rate of 2 Mbps
v5.0	Extended advertising	Additional advertising that takes place on the secondary advertising channels.
v5.0	Periodic advertising	Advertising that repeats at highly regular intervals on the secondary advertising channels.
v5.1	Periodic Advertising Sync Transfer (PAST)	Allows a resource constrained device to allow another device to scan periodic advertisements on behalf of the constrained device.
v5.2	Isochronous channels	Provides a time critical, periodic transport particularly well suited for transferring audio. Supports both connected (unicast) and connectionless (broadcast) data transfer.

Table 2: Introduction of key Core features used by PBP.

The listed Core features may span both the Bluetooth Host and the Bluetooth Controller (defined in Section 2 of Core Vol 1, Part A [17]) and will be referred to in later sections that explore PBP in more depth. Figure 4 describes the majority of the Host layers that make up LE Audio, including the major components of GAF.

*Figure 4: Generic Audio Framework, top level profiles, and underlying Host layers – emphasis on the components that support Auracast™.*

Some Core Host components that are used by LE Audio are shown along the bottom row. The Common Audio Profile (CAP) [2] is the top layer in GAF and encapsulates the layers below it. Of particular interest to PBP and broadcast audio, CAP inherits and encapsulates broadcast roles and features from BAP. The row at the top is the Application Profiles. Shown in that row are the Telephony and Media Audio Profile (TMAP) [4], PBP and the Hearing Access Profile (HAP) [14].

Figure 4 breaks down the GAF layers under CAP into three categories: content control, rendering and capture, and stream control. There are a great many profiles and services defined under those three categories, not all of which are relevant to PBP. The components shown in shades of gray indicate LE Audio components not relevant to PBP. This includes all of the components associated with content control, and rendering and capture. Also shown in shades of gray are components dedicated only to unicast audio. HAP and TMAP are independent Application Profiles that are isolated from PBP and thus are also shown in gray. Future documents may define and explore these components in more detail.

The Three PBP Roles and their GAF Dependencies

PBP defines three distinct roles – the Public Broadcast Source (PBS), the Public Broadcast Assistant (PBA) and the Public Broadcast Sink (PBK).

Figure 5 describes the three PBP roles and their relationship to the corresponding CAP and BAP roles.

The PBS is built on broadcast features provided by the CAP Initiator and BAP Broadcast Source roles. CAP’s broadcast source behaviors build on and extend the BAP Broadcast Source role. CAP provides procedures such as Broadcast Audio Start, Broadcast Audio Stop and Broadcast Audio Update. These procedures abstract operations of the BAP Broadcast Source. A PBS may use the BAP Broadcast Audio Stream Metadata Update procedure to update metadata information contained in the Broadcast Audio Source Endpoint (BASE), such as language and Streaming_Audio_Contexts. The BASE is described in more detail in the Periodic Advertising section.

The PBK is built on the broadcast features provided by the CAP Acceptor and BAP Broadcast Sink roles. CAP’s broadcast sink behaviors build on and extend the BAP Broadcast Sink role. CAP provides procedures such as Broadcast Audio Reception Start, Broadcast Audio Reception Stop and Distribute Broadcast_Code to allow it to be commanded by a PBA, which is a CAP Commander. These procedures abstract operations of the BAP Broadcast Sink.

Earbuds and headphones are common PBK devices. They can delegate the scanning and selection of broadcasts to a PBA device, such as a smartphone.

The PBA is built on the features provided by the CAP Commander and BAP Broadcast Assistant roles, and arguably is the most complex of three PBP roles. See Figure 6 below.

As PBK devices, such as earbuds, often lack a convenient user interface and are battery powered. Therefore, scanning for broadcasts puts an additional burden on the limited battery of such devices. A PBA can act like a sort of remote control and scan assistant. The PBA scans for available broadcasts on behalf of the PBK. When the user chooses broadcast audio that the user wishes to listen to, the user selects the desired broadcast stream on the PBA’s user interface, and the PBA commands the PBK earbuds to listen to that audio source.

*Figure 6: PBA working with a PBS and a PBK*

A PBA, which is a CAP Commander, uses procedures provided by CAP, namely Broadcast Audio Reception Start, Broadcast Audio Reception Stop and Distribute Broadcast_Code to allow it to be command PBKs to receive broadcast audio, stop receiving broadcast audio or accept a Broadcast_Code to use with encrypted broadcast audio, respectively.

A smartphone is the most common example of a PBA. It locates the available PBS broadcast audio, and when a user chooses an audio program, it directs the user’s earbuds or headphones to tune to the selected broadcast audio.

The PBP Broadcast Source in-depth

When a user’s smartphone scans for Auracast™ broadcasts, it is scanning through advertisements sent out by Auracast™ transmitters, which are PBS devices.

PBP utilizes the Core features listed in Table 2 and the GAF components highlighted in Figure 4 to enable users to discover and listen to Auracast™ broadcast audio. BAP describes mandatory and optional data that can be provided in advertising. PBP mandates additional data beyond that specified in BAP, and recommends additional data be made available for the best user experience. This section explores Figure 7 to examine how a PBS advertises and broadcasts data to make the Auracast™ experience possible. In the following subsections, each layer shown in Figure 7 is explored in more detail, examining the data provided at each level, and user scenarios are given to help explain how this data enables and enhances a user’s experience.

In Figure 7 the left-hand text, with the horizontal lines acting as dividers, indicates the layer at which data is provided over-the-air. Each layer below has an immediate reliance on the layer just above it. As the Core specification was developed, additional layers were built upon previous ones, such that from top to bottom the layers follow a general chronological order. Legacy advertising was released with the introduction of Bluetooth Low Energy in v4.0, extended advertising and periodic advertising were released in v5.0, and isochronous streams were released in v5.2.

The vertical rectangles represent Protocol Data Units (PDUs) sent over-the-air at their respective layers. The arrows between the PDUs that pass between the layers identify how one layer points to the next layer. The right-most text identifies the key PDUs at the various layers and their contents. The elements in bold indicate data of particular interest for PBP.

*Figure 7: PBS advertising and streaming*

The topmost layer is the legacy advertising layer. The 2.4 GHz Bluetooth LE spectrum is divided evenly across 40 channels, centered 2 MHz apart. The channels numbered 37, 38 and 39 are considered the primary advertising channels, and in the original Core v4.0 specification, these were the only channels to allow advertising. The other channels are available for establishing and maintaining device-to-device connections.

Beginning with v5.0, channels 0 to 36 became available for advertising using extended and periodic advertising. These channels are thus now known as the secondary advertising channels, and advertising coexists on those channels with device-to-device connections. The primary advertising channels may be used to advertise an ADV_EXT_IND extended advertising PDU, containing a three-octet AuxPtr value. This value is used to locate and receive extended advertising PDUs on the secondary advertising channels. This is the next layer down, the extended advertising layer, in Figure 7. Note that this extended advertising can be transmitted on any of the three PHYs: the LE 1M PHY, the LE 2M PHY or the LE Coded PHY. Extended advertising consists of AUX_ADV_IND auxiliary packet PDUs, and may include auxiliary packet AUX_CHAIN_IND PDUs if the payload is too large to fit within a single AUX_ADV_IND PDU.

The Extended Headers of extended advertising PDUs may contain an 18-octet SyncInfo field, as described in Section 2.3.4 of Core Vol. 6, Part B [8]. The field may also be present in LL_PERIODIC_SYNC_IND or LL_PERIODIC_SYNC_WR_IND PDUs (not shown in Figure 7). The presence of this field indicates the presence of a periodic advertising train, the next layer down in Figure 7. The periodic advertising train consists of AUX_SYNC_IND PDUs, and may also include AUX_CHAIN_IND PDUs if the payload is too large to fit within a single AUX_SYNC_IND PDU. These PDUs are advertised on a periodic basis.

Within the extended header of periodic advertising PDUs an Additional Controller Advertising Data (ACAD) field may be present. This is intended to transmit information from an advertiser’s Controller to the recipient’s Controller. For purposes of broadcast audio, ACAD can contain the BIGInfo field. BIGInfo is 33 octets for an unencrypted BIG and 57 octets for an encrypted BIG. It contains all the information needed for a Controller to synchronize to a Broadcast Isochronous Group, or BIG, containing the Broadcast Isochronous Streams, or BISes, that then contain the audio data. The BIG is broadcast at a fixed time offset from the periodic advertising PDU that contains BIGInfo. Note that the periodic advertising interval, and the interval that the BIG and BISes are broadcast at, the isochronous interval or ISO_Interval, need not be identical. In practice, the periodic advertising interval is an integer multiple of the ISO_Interval. Thus, the offset between the periodic advertising PDU that contains BIGInfo (PADV in the following figure), the BIG Offset and the next BIG PDU remains fixed. See Figure 8.

*Figure 8: Periodic advertising and a BIS over time with a two-to-one interval ratio*

While it is permitted for the periodic advertising train to be disabled while the BIG continues to broadcast, this would be problematic in an Auracast™ environment, as it would remove the timing and information a Controller would use to synchronize to the BIG and its BISes, and ultimately the broadcast audio. Only receivers already synchronized to the BIG would be able to continue to receive the broadcast audio. If those receivers were to lose sync, they will be unable to synchronize again without the periodic advertising to re-establish the timing and BIGInfo to provide the needed information.

Appearance Value AD Type

In the Core specification, AdvData refers to various advertising data fields within legacy, extended and periodic advertising PDUs. PBP recommends that a PBS, when populating AdvData, include the Appearance Value Advertising Data (AD) Type. This type is described in Section 12.2 of the Core Vol 3, Part C [5] and Part A, Section 1.12 of the Core Specification Supplement [6]. The values of the Appearance Value AD Type are enumerated in Section 2.6 of the Bluetooth Assigned Numbers [7]. The Appearance Value can be used to identify an appropriate icon for a given Bluetooth device.

Appearance Value AD Type appears at the top of Figure 7 because the legacy advertising in the primary advertising channels present the first opportunity to add the Appearance Value to an AdvData field. However, PBP only specifies that it be added to AdvData, meaning it could be added to AdvData on the secondary advertising channels instead of, or in addition to, the legacy advertising.

While providing the Appearance Value AD Type is only a recommendation in PBP, reviewing a user’s experience can provide a clear example of why doing so is a best practice. Figure 9 presents a hypothetical user interface on a smartphone that allows selection of Auracast™ broadcasts available at the PBJ Gym.

*Figure 9: Hypothetical broadcast selection screen with appearance icons highlighted.*

When a user reviews the list of Auracast™ broadcasts on the smartphone, the user is presented with icons to help identify the type of broadcast audio. This is possible, at least in part, because the Auracast™ transmitters provide Appearance Values. For the TVs the Auracast™ transmitters provide an Appearance Value AD Type of 0x0A01 for “Television” as given in Bluetooth Assigned Numbers [7]. The workout audio broadcasts the gym provides have a distinctly different icon from the TV broadcast streams, setting them apart from the majority of the available broadcast audio. In our hypothetical gym example, the installers went with the recommended practice in Table 3.1 of the Auracast™ Transmitter Best Practices Guide [9] of setting the Appearance Value AD Type of 0x0885 for “Broadcasting Device”, as given in Bluetooth Assigned Numbers [7]. This does not readily translate to the music icon shown in Figure 9. However, with some additional information described later, the smartphone app was able to correctly deduce that the broadcast audio is music.

Because the Auracast™ transmitters are configured to provide Appearance Values to indicate the source of the broadcast audio, the end user has a better user experience.

Extended Advertising

Since a PBS is a BAP Broadcast Source, it supports Broadcast Audio Announcements in extended advertising, which provides the Broadcast_ID for the BIG associated with the broadcast stream(s), as described in Section 3.7.2.1 in BAP [3] and shown in Figure 10.

PBP provides key information when discovering Auracast™ broadcasts by defining the Public Broadcast Announcement, which a PBS can provide in extended advertising, specifically in the AdvData field of AUX_ADV_IND PDUs. This announcement, defined in Section 4 of PBP [1], indicates if Standard Quality Public Broadcast Audio is present, High Quality Public Broadcast Audio is present, and if the broadcast is encrypted. See Table 3.

Feature Bitfield	Bit	If 0b0 then	If 0b1 then
Encryption	0	The associated broadcast stream or streams are not encrypted.	The associated broadcast stream or streams are encrypted and a Broadcast_Code is required
Standard Quality Public Broadcast Audio	1	Standard Quality Public Broadcast Audio is not available for the associated broadcast stream or streams	Standard Quality Public Broadcast Audio is available for the associated broadcast stream or streams
High Quality Public Broadcast Audio	2	High Quality Public Broadcast Audio is not available for the associated broadcast stream or streams	High Quality Public Broadcast Audio is available for the associated broadcast stream or streams

Table 3: Bitfields of the Public Broadcast Announcement

When the Standard Quality Public Broadcast Audio bitfield indicates standard quality audio is available, the broadcast audio stream configuration will be 16 or 24 kHz settings as defined in Table 4, with the meanings of the set names defined in detail in Table 6.4 in BAP [3].

Broadcast Audio Stream Configuration Set Name	Description
16_2_1	16 kHz, 10 ms framing, 32 kbps, low latency
16_2_2	16 kHz, 10 ms framing, 32 kbps, high reliability
24_2_1	24 kHz, 10 ms framing, 48 kbps, low latency
24_2_2	24 kHz, 10 ms framing, 48 kbps, high reliability

Table 4: BAP broadcast Audio Stream configuration setting requirements for Standard Quality Public Broadcast Audio

When the High Quality Public Broadcast Audio bitfield indicates high-quality audio is available, the broadcast audio stream configuration will be one of the 48 kHz settings in Table 5, taken from Table 4.2 in PBP [1]. The meaning of the set names is defined in detail in Table 6.4 in BAP [3].

Broadcast Audio Stream Configuration Set Name	Description
48_1_1	48 kHz, 7.5 ms framing, 80 kbps, low latency
48_2_1	48 kHz, 10 ms framing, 80 kbps, low latency
48_3_1	48 kHz, 7.5 ms framing, 96 kbps, low latency
48_4_1	48 kHz, 10 ms framing, 96 kbps, low latency
48_5_1	48 kHz, 7.5 ms framing, 124.8 kbps, low latency
48_6_1	48 kHz, 10 ms framing, 124 kbps, low latency
48_1_2	48 kHz, 7.5 ms framing, 80 kbps, high reliability
48_2_2	48 kHz, 10 ms framing, 80 kbps, high reliability
48_3_2	48 kHz, 7.5 ms framing, 96 kbps, high reliability
48_4_2	48 kHz, 10 ms framing, 96 kbps, high reliability
48_5_2	48 kHz, 7.5 ms framing, 124.8 kbps, high reliability
48_6_2	48 kHz, 10 ms framing, 124 kbps, high reliability

Table 5: BAP broadcast Audio Stream configuration setting requirements for High Quality Public Broadcast Audio

In addition to the audio quality and encryption bitfields, the Public Broadcast Announcement also provides an opportunity for the PBS to provide additional metadata. No specific usage is currently defined or recommended for this field.

When transmitting the Public Broadcast Announcement, the PBS sends the Broadcast_Name AD Type value in the same extended advertising AUX_ADV_IND PDU. This value is a 4 to 32 character name describing the broadcast. It is in UTF-8 format and is defined in Section 5.1 of PBP [1].

Figure 11 presents the previous hypothetical user interface on the smartphone from Figure 9 that allows selection of Auracast™ broadcasts available at the PBJ Gym, but highlights the encryption icons and broadcast names.

*Figure 11: Hypothetical broadcast selection screen with encryption icons and broadcast names highlighted.*

The recommended Appearance Type of Broadcast Device is not very helpful alone for identifying the correct icon. However, a smart application can read the Public Broadcast Announcement in extended advertising and recognize that the broadcast audio contains high-quality audio. High-quality audio is not typically used for voice audio but is commonly used for music reproduction, and in the hypothetical broadcast selection user interface, the user interface correctly identifies the broadcast audio as music. Though it refers specifically to unicast roles, Section 3.5 of TMAP [4] highlights the distinction between voice and media codec capability settings.

Note that while the choice of a music icon works well for this hypothetical example, in practice, user interface developers may discover examples where the presence of high-quality audio does not always indicate music is present. Thus, a more generic icon may be presented, or the device may look for additional information available to help discern the best icon. The choice of icon is not as straightforward as when the Appearance Type is Television.

In the hypothetical user interface described in Figure 11, the value of the Broadcast_Name AD Type is read for each broadcast audio source, and presented to the end user in the selection screen, as highlighted. This description of the broadcast audio is a key component that enables the end user in their selection of the desired broadcast audio.

The appearance of the encryption icons next to the music programs indicates that those broadcast audio programs are encrypted and will require a Broadcast_Code encryption key to listen to them. This is known because the PBS set the Encryption feature bit in the Public Broadcast Announcement. How the Broadcast_Code is shared with the PBK to allow decryption is described in later sections.

Periodic Advertising

*Figure 12: PBS advertising and streaming, with extended advertising highlighted.*

When the Public Broadcast Announcement is present in extended advertising, the PBS transmits Basic Audio Announcements as defined in Section 3.7.2.2 in BAP [3]. Specifically, the Basic Audio Announcements are transmitted in the AdvData field of AUX_SYNC_IND and/or AUX_CHAIN_IND PDUs. This announcement provides the BASE data. The BASE provides a detailed breakdown of information that describes the broadcast audio streams that are available in a broadcast. For example, it can indicate if the audio is mono or stereo. It can also indicate if audio is available in different languages.

Figure 13 is similar to Figure 3.1 in BAP [3], but the data reflects what the information could look like for the broadcast audio described by the Broadcast_Name “PBJ Gym TV 2” which is dedicated to sports programming and supports both English and Spanish language audio. BIS and its relationship to a BIG is described in the next section. For purposes of understanding Figure 13, there are four BISes at level 3, each of which carries a single channel of audio.

*Figure 13: BASE describing bilingual TV broadcast audio.*

PBP recommends including Program_Info, which is Length-Type-Value (LTV) data described in Section 6.12.6.3 in Bluetooth Assigned Numbers [7]. It is the program’s title and/or a summary of the program’s content. Program_Info is provided at the subgroup level, level 2, in the BASE in the metadata fields, as shown in Figure 13.

As evident from Figure 13, BASE provides a great deal of technical detail that is needed to configure and render the broadcast audio. It also provides useful information that can aid a user in selecting the desired broadcast audio. Figure 14 presents a hypothetical broadcast selection screen. The user has chosen a desired a broadcast audio selection from a list in an initial screen, such as is seen in Figure 9 and Figure 11, and is then presented more details about that selection. If different audio streams are available, such as different language options, the user can select which language to listen to. If there is only a single broadcast audio selection, the next screen might simply provide information about that selection and give the user the option to proceed or go back to the main selection screen.

*Figure 14: Hypothetical select broadcast user interface.*

In this hypothetical example, a user has chosen the “PBJ Gym TV 2” broadcast, as they are interested in the world sports highlights playing on that sports program. As both English and Spanish language programming is available, the user will need to choose which they prefer. The smartphone has read the BASE and knows that both selections are in stereo, recognizing that at the level 3:BIS in the BASE, either selection provides audio streams for audio locations Front Left (FL) and Front Right (FR), which translates to stereo. The user interface chooses to indicate this by showing a headset icon. At level 2 in BASE, the metadata indicates that one set of stereo audio streams is in English, while the other set is in Spanish. It displays the language in the selection, and by reading the Program_Info data in the metadata at level 2, the interface is able to provide a title and/or summary of the broadcast audio. While in this example the descriptions are short for convenience, in practice they can be verbose, and a user interface must choose how to handle much longer text.

Note that while including the Program_Info field is only recommended by PBP and not required, it’s utility to a user is readily apparent.

The Broadcast Audio Streams

*Figure 15: PBS advertising and streaming, with broadcast audio streams highlighted.*

Bluetooth Core v5.2 introduced a key feature upon which LE Audio is built – isochronous streams. Isochronous streams, whether connected unicast streaming or connectionless broadcast streaming, provide robust transfer of data at precise intervals, with flushing mechanisms, well suited to supporting transport of audio data. While different in their approaches, both unicast and broadcast isochronous streams provide time diversity mechanisms that help improve their robustness. Exploring isochronous streams in more detail will be the subject of a future article.

PBP and Auracast™ rely on broadcast isochronous streams to broadcast audio to any receiving devices, as defined in the Specification of the Bluetooth System, Volume 6: Low Energy Controller [8]. Audio data is broadcast by a PBS and received by a PBK. The Core Link Layer defines the roles of Isochronous Broadcast and Synchronized receiver. The PBS is an Isochronous Broadcaster and the PBK is a Synchronized Receiver.

A BIG is a Broadcast Isochronous Group, while a BIS is a Broadcast Isochronous Stream. A BIG groups one or more BISes and identifies them as being related. Figure 16 demonstrates how the four BISes on the PBJ Gym TV 2 used as an example in Figure 13 are all grouped together into a single BIG. Though not specifically named in Figure 13, a BIG essentially corresponds to “Level 1 (Group)”. A BIS carries audio for a specific audio location in this example. In the case where no audio location is specified, the broadcast audio can essentially be considered mono.

*Figure 16: The four “PBJ Gym TV 2” BISes in a BIG*

The BIG has very specific meaning at the Core isochronous streams transport layer, but it also has specific application to PBP and Auracast™. While the hypothetical PBJ Gym example dedicates a single Auracast™ transmitter to each audio source for simplicity, it is possible, bandwidth permitting, for an Auracast™ transmitter to accept more than one audio source and transmit broadcast audio from the different sources. Each source would be in its own BIG, even if only a single channel of mono audio is contained in a single BIS. Each BIG would include all of the contents of the extended and periodic advertising described in the previous sections. So, for example, each BIG would have its own Public Broadcast Announcement, Broadcast_Name and BASE information.

The Appearance Value AD Type, however, is applied to a device. If an Auracast™ transmitter was transmitting broadcast audio for sources that all have the same Appearance Value, this might not be an issue. However, if the Auracast™ transmitter received audio from sources of different types, this could be problematic. In theory, the Appearance Value AD Type could be advertised in AdvData in extended and/or periodic advertising specifically associated with a given broadcast audio source, the definition from Core in Vol 3, Part C, Section 12.2 [5] reads “The Appearance characteristic defines the representation of the external appearance of the device.” Not all PBAs may interpret that the Appearance refers to an internal or external audio source as the specification defines Appearance in terms of the device.

The entire goal of Auracast™and PBP, in the end, is for the user’s listening device, such as headphones, a headset or earbuds, to receive and render the desired audio streams from the Auracast™ transmitters. Ultimately, a PBS sends audio using one or more BISes to one or more PBKs.

The PBP Broadcast Assistant in-depth

The majority of the PBP specification is dedicated to describing the operation of the PBS. Most of the functionality and features of the PBA are derived from its roles as a CAP Commander and a BAP Broadcast Assistant. PBP does state that a PBA may use the BAP Basic Audio Announcement discovery procedure defined in Section 6.4 in BAP [3] to discover Public Broadcast Announcements.

A PBA is typically a smartphone, tablet, or similar device. The PBA can be described as a kind of remote control for a user’s audio rendering device or devices. It that sense, it could be thought of as the user interface for one’s headphones or earbuds. While this document up to this point has focused primarily on what the PBS transmits, when describing the operation from the user perspective on the hypothetical user interfaces, that is a description of PBA behavior. A PBA may receive the Appearance Value AD Type from different broadcasts and provide an appropriate icon for each item in a list of broadcasts. A PBA can read the Public Broadcast Announcement and determine if each broadcast provides standard quality audio, high-quality audio, and if that audio is encrypted. It can read the broadcast name and display that to the user to aid in selecting the desired broadcast audio. From the BASE, a PBA can receive details including whether or not the audio is stereo or mono, and if different languages are available. By reading Program_Info, it can provide details about the programming available on a given broadcast.

Through the functionality available to a PBA as a CAP Commander and a BAP Broadcast Assistant, it could be described as serving three key functions:

It scans for broadcast audio on behalf of the PBK.
It commands the PBK to receive and render a broadcast audio when selected by the user.
It provides a Broadcast_Code to the PBK to allow it to decrypt encrypted audio.

As a Broadcast Assistant, a PBA scans for the Broadcast Audio Announcements from PBSes, which are Broadcast Sources, on behalf of a PBK. A PBK is a Scan Delegator that hosts the Broadcast Audio Scan Service (BASS) [16]. The PBA shares scan information by writing to the BASS Broadcast Receive State characteristic of the PBK.

When the user has selected broadcast audio they wish to listen to, the user commands the PBA to start the audio at their PBK device or devices. The PBA does so using the CAP Broadcast Audio Reception Start procedure. A PBK device, such as headphones, will follow the legacy, extended and periodic advertising as described in the PBS sections, and will synchronize to the broadcast audio. The PBA can stop the PBK from rendering the audio by using the CAP Broadcast Audio Reception Stop procedure. Figure 17 demonstrates a PBK receiving broadcast audio directly from a PBS.

*Figure 17: A PBK receives audio directly from a PBS*

The PBA may have a Broadcast Code encryption key for encrypted broadcast audio. When required, the PBA shares the Broadcast_Code with the PBK by using the CAP Distribute Broadcast_Code procedure.

The PBP Broadcast Sink in-depth

Most of the functionality and features of the PBK are derived from its roles as a CAP Acceptor and BAP Broadcast Sink. PBP states that the BAP Basic Audio Announcement discovery procedure defined in Section 6.4 in BAP [3] may be used to discover Public Broadcast Announcements.

As a Scan Delegator, the PBK hosts the BASS service, and a PBA can update scan status by writing to its BASS Broadcast Receive State characteristic.

A PBK supports the CAP Broadcast Audio Reception Start procedure which allows a PBA or other CAP Commander to command it receive broadcast audio. It supports the CAP Broadcast Audio Reception Stop procedure which allows a PBA or other CAP Commander to command it to stop receiving broadcast audio.

A PBK supports the CAP Distribute Broadcast_Code procedure to allow a PBA or other CAP Commander to provide a Broadcast_Code encryption key to allow it to decode encrypted broadcast audio.

Concluding Remarks

Auracast™ is defined by the PBP specification [1] and the brand guidelines for Auracast™ Trademarks [11]. This document explored the details of PBP and the LE Audio Generic Audio Framework, along with the Core features that make LE Audio and Auracast™ possible. It also used a hypothetical environment to explore user experiences, hypothetical user interfaces, and how PBP and LE Audio work to make those experiences possible. This document also gave insights into how an Auracast™ location could be set up. References that are useful for a facility wishing to support Auracast™ are provided. Future documents will explore other aspects of LE Audio in more depth.