7.1.6 Available Bluetooth Low Energy Audio Contexts
The receiver uses the “Available_Audio_Contexts” characteristic to inform the initiator that certain specific context types claimed to be supported in the “Supported_Audio_Contexts” characteristic are currently unavailable. This may sound contradictory, but the existence of this characteristic is to indicate what the receiver is currently willing to support. This choice is dynamic. The specific implementation may determine whether to take a call while watching TV, or vice versa. When the initiator wants to start the audio stream establishment process, the context type of the audio stream that the initiator wants to set must be shown as available in the “Available_Audio_Contexts” characteristic.
Unlike the static “Supported_Audio_Contexts” values, the receiver can update its “Available_Audio_Contexts” values at any time and notify the connected initiator upon updating.
The purpose of the “Available_Audio_Contexts” is to guide the initiator or application in determining when and whether to accept new usage scenarios by providing them with tools, thus facilitating switching between multiple usage scenarios. This is a significant improvement over classic audio, where the audio source (usually a smartphone) makes decisions without peripheral device input.
To illustrate this, Figure 7.1 shows a typical setting of the “Supported_Audio_Contexts” and “Available_Audio_Contexts” characteristics.
In this example, the receiver supports the “Unspecified” (which is required to be supported) context type, as well as context types such as “Emergency Alarm”, “Ringtone”, “Conversation”, “Guidance”, and “Media”. All these context types are shown as available. If the initiator wants to use any of the above context types to start an audio stream, the receiver should accept it. It is not allowed for both “Unsupported” and “Available” states to exist simultaneously.
If the initiator wants to set up an audio stream for transmitting key tones, and key tones belong to the “Sound Effects” context type, it can do so. This is because the “Available_Audio_Contexts” bitmap shows that “Unspecified” is available. As long as “Unspecified” is shown as available in the receiver, the initiator can map the unavailable context type it wants to use to “Unspecified” in its “Streaming Audio Context” metadata attributes. In this case, the receiver must accept that audio stream.
This is a complex new feature that may not be supported by first-generation products, but as Bluetooth Low Energy audio technology evolves, we expect it to become increasingly important in enhancing user experience.
Figure 7.2 illustrates the role of setting context type bits in the “Supported_Audio_Contexts” characteristic. In this example, the context types “Emergency Alarm” and “Ringtone” are supported but are currently not marked as available in the “Available_Audio_Contexts” characteristic. This means that if the initiator attempts to establish an audio stream related to these context types, it will be rejected by the receiver because they are explicitly set as unavailable.
If these bits were not initially set as “Supported”, the initiator could have mapped them to the “Unspecified” context type. However, this is not allowed in this case because they are set as “Supported” but “Unavailable”. Nevertheless, the initiator can still remap audio streams related to “Alerts”, “Notifications”, or any other unsupported audio context to the “Unspecified” context type, which the receiver should accept.
Finally, Figure 7.3 shows an example where “Unspecified” is marked as unavailable (remember that “Unspecified” must always be supported). Setting “Unspecified” as unavailable prevents the initiator from mapping any other unavailable context types to “Unspecified”, so in this case, the receiver is only available for audio streams associated with “Guidance”, “Media”, or “Conversation”.
Table 7.8 illustrates this situation from the perspective of how the initiator interprets these settings. In fact, the receiver can set three options:
a) Allow the initiator to continue establishing the audio stream;
b) Prohibit the initiator from starting the audio stream;
c) Indicate indifference, allowing the initiator to try.
The last column maps the use case options from the previous list.
Although the “Supported_Audio_Contexts” characteristic is valid for all clients, the receiver may expose different values of its “Available_Audio_Contexts” characteristic to different clients. This allows the receiver to decide what different initiators can do, such as controlling which devices can stream media to it based on each client, or establishing audio streams for phone calls. For example, when a user has two smartphones, the receiver can leverage this to prioritize incoming calls.
How this is managed depends on the specific implementation, and it is up to the receiver to manage the different namespaces required to implement this operation. In practical implementations, it provides the receiver with a method to set connection policies based on use case settings, which is something classic Bluetooth audio profiles cannot achieve. Since the “Available_Audio_Contexts” LTV may change dynamically, it is most likely used during codec configuration states, which we will discuss below.