Broadcast Audio Uniform Resource Identifier

Requirements in this specification are defined as "Mandatory" (M), "Optional" (O), "Excluded" (X), “Not Applicable” (N/A), or "Conditional" (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.

Each capability of this specification shall be supported in the specified manner. This specification may provide options for design flexibility, because, for example, some products do not implement every portion of the specification. For each implementation option that is supported, it shall be supported as specified.

The Basic Audio Profile (BAP) [1] and the Broadcast Audio Scan Service (BASS) [2] define how a Broadcast Assistant can discover and select broadcast streams from Bluetooth LE Audio Broadcast Sources. The Broadcast Assistant first scans to discover available Broadcast Sources within range. These are then presented by a user interface so that the user can decide which broadcast to listen to. After they make that choice, the Broadcast Assistant will write the information it discovered about the broadcast to its connected Broadcast Sinks.

Figure 2.1 shows one possible implementation, where a user selects one stream from among the four Broadcast Sources that their Broadcast Assistant has found.

Figure 2.1. An example of using a Broadcast Assistant on a smartphone to discover and select a broadcast stream

As the number of Broadcast Sources increases, the list of discovered devices will grow, following the trend that we have seen with Wi-Fi access points. The user selection task will become more complex, and it can become further complicated as Broadcast Sources begin to include multiple alternative streams, such as different languages, multiple codec configurations for different audio qualities, and specific Assisted Listening Streams (ALSs) that target users with hearing difficulties.

To address the problem mentioned in Section 2.1 and help users connect to a specific stream, OOB methods are particularly useful in developing new use cases. One way of using them is with QR codes. Users can use the camera on their smartphone to scan a QR code, capturing information to guide the Broadcast Assistant to select a specific stream.

Figure 2.2 shows how this can be implemented in a music app on a smartphone. A dynamically generated QR code lets Jon’s friends scan his phone screen, which then directs their earbuds to synchronize to the music that Jon is sharing from his phone.

Figure 2.2. Using a QR code to share music with friends

Figure 2.3 shows a different example, where static QR codes representing audio streams containing different screens and languages can be printed out and used in venues such as sports bars or cinemas. A user can scan the QR code corresponding to the stream they want to listen to, which could seamlessly connect their earbuds or hearing aids to the selected broadcast stream. These QR codes provide the specific information that their Broadcast Assistant needs to select the corresponding Broadcast Source and instruct its Broadcast Sinks to synchronize with the selected streams, simplifying the selection experience.

Figure 2.3. Examples of QR code signs for sports bars and cinemas

The Broadcast Audio URI represented by a QR code can also include the Broadcast_Code to decrypt the Audio Stream of a private broadcast. An example is when a user shares audio from their smartphone, where a dynamically generated QR code includes the Broadcast_Code for that session.

A Broadcast Assistant scans for the extended and periodic advertisements that are sent by every Broadcast Source. These identify the transmitter and provide information about the number of streams that it is transmitting (including their content) and where to find them. The Broadcast Assistant uses this information to allow a user to select an available Audio Stream and then instruct its Broadcast Sinks to synchronize to specific Broadcast Isochronous Streams (BISes) from the selected transmitter.

The Broadcast Audio URI can be used as an alternative method of providing complete or partial information about a broadcast, where a QR code is an example of its graphical representation. To facilitate the out-of-band method, there are two roles:

If all the information is static or if a QR code can be generated dynamically, then a QR code can convey enough information for a device that reads it to write an Add_Source or Modify_Source command to the BASS server in its Broadcast Sinks without the need to perform scanning. However, static QR codes cannot offer Periodic Advertising Synchronization Transfer (PAST) operation^[1], because that data is dynamic. (More details on the implications for Broadcast Assistants are provided in Section 5.4.)

Alternatively, a Broadcast Assistant can use the information contained within the QR code to jump to the specific advertising data for that Broadcast Source that it discovered from its scanning process. In this case, the information in the QR code would not replace the information gathered by the Broadcast Assistant’s scanning. Instead, it is used to reduce the selection choices from a potentially large number of available Broadcast Sources to relevant broadcasts contained in the QR Code. This compound method of scanning and reading a Broadcast Audio URI allows support for PAST.

QR codes that represent encrypted broadcasts may contain a code necessary to decrypt encrypted broadcasts without additional user intervention.

Figure 2.4 shows the process for a user in a sports bar that has three TVs showing football, golf, and hockey. The user’s Broadcast Assistant, which has already started scanning, discovered these three TVs. The user decides to use the QR scanner feature in their Broadcast Assistant to scan the printed QR code for the TV showing hockey. This tells the Broadcast Assistant to select the information it found for the “Hockey” TV and instructs the user’s headphones to synchronize to the broadcast streams from that TV.

This is a simplistic example to explain the process. The user application is likely to conceal the background scanning to provide a smoother user experience, but that is implementation specific.

Figure 2.4. Example of QR code usage in a sports bar

All of the data that is conveyed is already defined in the underlying Bluetooth LE Audio specifications, with the majority of elements being defined within BASS [2]. To differentiate the Broadcast Audio URI from any other Bluetooth URI usages, the “BLUETOOTH:” scheme prefix shall be followed by an identifier:data pair signifying that it is a Broadcast Audio URI, comprising a universally unique identifier (UUID) with the BASS-assigned UUID defined in the Bluetooth Assigned Numbers (AN) document [4] in the string form of “UUID:184F;”. This combination of the Bluetooth scheme identifier, BASS UUID, and subsequent data tuples is referred to as the Broadcast Audio URI and is common for all OOB methods.

Very few data elements need to be present in a Broadcast Audio URI to direct a Broadcast Assistant to select a specific Broadcast Source. These are listed in Table 3.1, which contains the details for the parameters that should be included after the BASS UUID. The formats identified in the “Format” column are defined in Table 3.2.

Each data element contains information that is used by a Broadcast Assistant to identify an entry in its internal database of scanned Broadcast Sources. Having identified it, the Broadcast Assistant should request an action on a Scan Delegator by adding or modifying an instance of one of the BASS Server’s Broadcast Receive State characteristics.

If a Broadcast Source has a Public Device Address, then the Public Device Address should be included, because it provides a unique identifier for each Broadcast Source. If the Broadcast Source has a Random Device Address, then the Random Device Address should only be included if the medium using the Broadcast Audio URI can represent it dynamically. Random addresses are usually changed every 15 minutes.

The Broadcast_ID should be present when the Broadcast Source is transmitting multiple BIGs, because the Broadcast_ID identifies a particular stream to be selected.

The Standard_Quality and High_Quality parameters in Table 3.1 are helpful to identify the presence of Auracast™ transmissions.

Stream metadata should be included when a specific BIS or Broadcast Audio Source Endpoint (BASE) subgroup is indicated by the Broadcast Audio URI. An example is where a particular language is selected from a Broadcast Source that is simultaneously broadcasting multiple languages. In this case, multiple QR codes can be displayed for the same Broadcast Source, each with an appropriately populated Broadcast Audio URI for a different language stream.

The purpose of the information contained in the Broadcast Audio URI is not necessarily to replace scanning by the Broadcast Assistant, but to simplify the task of selecting a stream by the user. Most Broadcast Assistants with the ability to scan a QR code are likely to allow a user to set selection policies, which are used to filter the displayed scanning information. The elements of a QR code should be limited to those parameters that identify the Broadcast Source among those that a Broadcast Assistant has found, allowing it to apply its preconfigured policies. Additional information, such as Stream Metadata and Stream Quality, should only be included where the intention is to request that the Broadcast Assistant uses these to override its policies.

A Broadcast Assistant may have enough knowledge about the user’s preference to select the correct Broadcast Source using just the Broadcast Name data. However, the Device Address and the Broadcast ID (if it is static) should also be included, because that information allows the correct stream to be selected in cases where multiple transmitters share the same Broadcast Name, or a transmitter is using multiple BIGs.

A GATT client can emulate the functionality of a Broadcast Assistant by using information contained in a Broadcast Audio URI to perform an Add Source or Modify Source operation on the BASS server of its Broadcast Sink. This is described in Section 3.8.

The following common rules are applied to the URI data formats used with the Broadcast Audio URI:

The rules specified in Table 3.2 shall be used to format Broadcast Audio URI data elements.

When a user instructs a Broadcast Assistant to read a Broadcast Audio URI, the Broadcast Assistant shall receive the complete text string and parse it in the following order:

After the Broadcast Assistant has decoded the information from reading the Broadcast Audio URI, the Broadcast Assistant may use the information it contains in different ways:

In some devices such as TVs and smartphones, an application may dynamically generate a QR code for a user to scan. In these cases, it may be advantageous to include additional data elements corresponding to other parameters used in the Add Source or Modify Source operations on the Broadcast Audio Scan Control Point characteristic. These are listed in Table 3.4.

All these data elements are optional for devices that support the URI encode or URI decode roles. Broadcast Assistants and GATT Clients that can read a Broadcast Audio URI should be able to parse and identify them.

The Broadcast Audio URI does not include an identifier:data pair for PA_Sync. A Broadcast Assistant that is scanning sets the value in its Broadcast_Audio_­Scan_Control_Point command to 0x01 if it supports PAST and 0x02 if it does not. A GATT Client, which does not support scanning, sets it to 0x02.

Normally, the Broadcast Assistant would assume that the action of receiving a Broadcast Audio URI means that it may instruct its Broadcast Sinks to synchronize to the streams. If the selected streams are not present, the Broadcast Assistant or Broadcast Sink should inform the user. How this is done is implementation specific.

A Broadcast Assistant or non-scanning GATT Client can use the data in a Broadcast URI to populate an Add Source or Modify Source operation to a Broadcast Audio Scan Control Point characteristic. Table 3.5 shows the elements of the Add Source operation from Section 3.1.1.4 in [2], indicating which elements come from a Broadcast Audio URI, such as a QR code, and which are generated locally by the Broadcast Assistant or GATT Client. Omitted leading zeroes need to be restored and decoded strings padded to meet BASS requirements. This table shows the minimum data that a GATT Client would use to perform these operations to successfully request a Broadcast Sink to synchronize to a Broadcast Source. If only the minimum information is provided, the Broadcast Sink or Broadcast Assistant would need to determine the missing elements by scanning for the specific Broadcast Source.

To support both Broadcast Assistants and GATT Clients, a Broadcast Audio URI should include the following elements:

The first example is the “Hockey” TV shown in Figure 2.4. This is a simple Broadcast Source that has a single BIG containing one subgroup comprising a single mono stream sampled at 24kHz. It is not encrypted, so there is no Broadcast Code. This TV has a static Broadcast_ID value, so the Broadcast Audio URI contains all the following information (based on Table 3.4 and Table 3.5) that the Broadcast Assistant requires to instruct its Broadcast Sinks to synchronize to the stream.

This results in a 91-character Broadcast Audio URI:

BLUETOOTH:UUID:184F;BN:SG9ja2V5;SQ:1;AT:0;AD:AABBCC001122;AS:1;BI:DE51E9;PI:FFFF;NS:1;BS:1;;

Note: The leading zeros are omitted from the Advertising_SID, Num_Subgroups, and BIS_Sync[0] data elements.

This string is represented by the QR code in Figure 4.1.

Figure 4.1. The QR code for the Hockey TV in the sports bar example

As there is a single mono stream, the Broadcast Assistant will instruct both right and left earbuds to synchronize to the same mono stream. The Broadcast Assistant also needs to determine the value to set the PA_Sync feature, based on whether it has enough information from its own scanning to support PAST.

The Broadcast Name in this example is only used locally by the Broadcast Assistant for its local display. A Broadcast Assistant could decide to write it to the Broadcast Audio Scan Control Point characteristic and hence the Broadcast Receive State characteristic instance by including it as content for the Broadcast_Name metadata LTV.

This example shows how a specific subgroup from a Broadcast Source can be selected using a QR code. It could be a transmitter in a cinema or a personal TV that is broadcasting stereo soundtracks in two languages: English and German. A simplified version of the BASE is shown in Figure 4.2.

Figure 4.2. Simplified BASE structure for a Broadcast Source transmitting two language streams in stereo

In this example, the resulting QR code from the Broadcast Audio URI must contain a Broadcast_Code, because the content is encrypted. Here, the assumption is made that the Broadcast_ID is not static, but changes on a session-by-session basis. Therefore, it is not useful to include it in a static QR code. This requires the Broadcast Assistant to scan to acquire this information. In this example, the primary purpose of the QR code is to automate the selection of the German language stream on a TV.

This results in a 102-character Broadcast Audio URI:

BLUETOOTH:UUID:184F;BN:Um9iaW7igJlzIFRW;AT:0;AD:AABBCC012345; BC:RmlsbUZsaWNzQTE=;SM:BARkZXUCBgE=;;

This is represented by the QR code in Figure 4.3.

Figure 4.3. QR code to select the German language stream

The Broadcast Assistant should use this information to select the streams in BIS Subgroup 2 of this BIG and instruct its Broadcast Sinks to synchronize to the appropriate BISes. The Broadcast Audio URI does not include the BIS_Sync information but leaves the task of selecting the appropriate BIS_Sync for each of its Broadcast Sinks to the Broadcast Assistant, based on its scanning and knowledge of its Broadcast Sinks' Published Audio Capabilities.

Where items of information are not available, as would be the case if the Broadcast Audio URI were read by a non-scanning GATT Client, its Broadcast Sink would need to scan to retrieve the missing information.

Broadcast Assistants and GATT Clients will usually read the PAC records of their paired Broadcast Sinks to determine their capabilities. This informs them of what the Broadcast Sinks support and provides a first level of selection policy. They can discard streams that they have discovered if their Broadcast Sinks are incapable of decoding or rendering them. Examples of these include:

Most fully featured BAU applications will allow users to configure additional polices, which they will use to filter the display of discovered Broadcast Sources, such as:

Locally configured policies allow a more relevant display of discovered streams, highlighting the options that are most likely to meet the user’s preferences.

Reading a Broadcast Audio URI should be considered as the user stating a preference for a specific stream. Because it is a user choice, this would normally override a locally preset preference, resulting in the Broadcast Assistant proceeding to write an operation to the Broadcast_Audio_Scan_Control_Point characteristic of its Broadcast Sinks, instructing them to synchronize to the chosen broadcast streams. A user interface may request that the user confirms this, and may also display alternative options, such as other languages or Audio Stream qualities, but that is implementation specific.

If the Broadcast Audio URI parameters do not contain enough information to complete an Add Source or a Modify Source operation, and do not correspond to a stream that the Broadcast Assistant has discovered, then the Broadcast Assistant should continue scanning to try to find the Broadcast Source. It may also read its Broadcast Sinks’ Broadcast Receive State characteristic instances to see if they contain the missing information. If it fails to obtain the necessary information, it should inform the user that the stream has not been found.

The information included in the Broadcast Audio URI may be static or dynamic. In some cases, such as a QR code generated on a mobile phone, the information may contain everything that a Broadcast Assistant requires to populate a Broadcast Audio Scan Control Point operation. In other cases, the Broadcast Assistant may need to use the information it has parsed in conjunction with its own scanning to populate the Broadcast Audio Scan Control Point operation.

QR codes and other URI implementations may make a deliberate decision about the level of information provided. For example, a QR code representing a Broadcast Source that is transmitting multiple different language streams may contain BIS_Sync information for a specific language, implying that the Broadcast Assistant should select that specific stream. This is shown in the example in Figure 4.3. Alternatively, the QR code could omit any language information, in which case the Broadcast Assistant should either select a pre-configured preferred language option or present the user with a choice of all available languages that it has discovered by its own scanning or has been notified by one of its Broadcast Sinks.

Broadcast Assistants need to be aware that URIs with differing amounts of information can lead to different choices being presented to users. The user experience of a Broadcast Assistant or GATT Client implementation should accommodate these differences.

Broadcast Assistants should be aware that the existence of an OOB Broadcast Audio URI does not mean that the associated Broadcast Source is transmitting or within range. A static QR code may refer to a Broadcast Source that has been moved, turned off, or is in a different location. For example, a different location could be a printed ticket with a QR code that only works in a specific place. For these reasons, devices that can perform scanning should check that the referenced Broadcast Source is available before instructing their Broadcast Sinks to synchronize to streams. When an intended Broadcast Source is not available, they should provide an appropriate indication to the user.