Bluetooth audio broadcast apparatus capable of facilitating communication between devices and associated methods

Abstract

A Bluetooth audio communication system includes multiple Bluetooth devices, each of which could act as a Broadcast Source and / or a Broadcast Sink. A Broadcast Source comprises a microphone or other audio recording / generation device, and an audio recording circuit. The Broadcast source is configured to process the recorded / generated audio data and generate a Bluetooth low energy (LE) audio broadcast source transmission comprising Bluetooth LE audio packets and metadata. The Bluetooth Broadcast Sink parses the Bluetooth LE audio packets to acquire a predetermined audio data, controls a first audio playback circuit to playback the predetermined audio data, and controls playing of the first audio playback according to the instructions and / or information. This helps facilitate half-duplex communications between devices in a group.

Description

Bluetooth Audio Broadcast Apparatus Capable of Facilitating Communication between Devices and Associated MethodsTECHNICAL FIELD

[0001] The invention relates to Bluetooth™ technologies, and more particularly to Bluetooth audio broadcasting systems adapted to facilitate half-duplex communication between devices.BACKGROUND

[0002] A duplex communication system is a point-to-point system composed of two or more connected devices that can communicate with one another in both directions.

[0003] In a half-duplex communication system, both parties can communicate with each other, but not simultaneously; the communication is one direction at a time. An example of a half-duplex device is a walkie-talkie with a two-way radio that has a push-to-talk button. When one user wants to speak to another person, they push this button, which turns on the transmitter and turns off the receiver, preventing them from hearing the remote person while talking. To listen to the other person, they release the button, which turns on the receiver and turns off the transmitter. In contrast, in a full-duplex system, both parties can communicate with each other simultaneously (e.g., in a conventional phone call).

[0004] Bluetooth LE Audio (BLE Audio) technology based on Bluetooth Core Specification Version 5.2 is a significant update to the previous technical specifications of audio transmission over the past twenty years of development of Bluetooth technologies. The main advantage of the Bluetooth LE Audio technology is that the Bluetooth LE Audio technology can transmit audio with higher quality while significantly reducing power consumption. In addition, the Bluetooth LE Audio technology also utilizes a new mechanism called Broadcast Isochronous Stream (BIS) to conduct audio broadcasting operations.

[0005] Bluetooth devices may include multi-component devices such as a pair of Bluetooth earphones, Bluetooth speakers, or the like. Bluetooth headphones / earbuds are extraordinarily popular, simple, and affordable way for users to enjoy music, perform phone calls and do voice command activation.

[0006] Prior Bluetooth versions, and even the new Bluetooth LE Audio standards based on Bluetooth Core Specification Version 5.2 or greater do not provide any mechanisms to support half-duplex communications between Bluetooth devices.SUMMARY

[0007] In accordance with the present disclosure, there is provided a device for enabling Bluetooth audio communication, comprising: a speaker; a memory, the memory configured to store one or more group identifiers; a receiver configured to receive Bluetooth low energy (LE) audio broadcast source transmission, the received audio broadcast source transmission comprising: one or more metadata packets; and one or more associated audio data packets containing an audio signal; and a controller configured to control the speaker based on the received broadcast source transmission, wherein, in response to receiving one or more associated metadata packets including a metadata group identifier, the controller is configured to enable playing of the audio signal through the speaker only when the metadata group identifier matches a said stored group identifier.

[0008] In the context of this invention, a device can act as a Bluetooth LE audio broadcast source (i.e., a transmitting device), or as a Bluetooth LE audio broadcast sink (i.e., a receiving device), or as both a Bluetooth LE audio broadcast source and sink (i.e., a device capable of transmitting and receiving Bluetooth LE audio broadcast source transmissions).

[0009] The group identifier may be or comprise a Programjnfo metadata field, as described in the Bluetooth Profile Specification, “Public Broadcast Profile” revision v1.0 i.e. A Public Broadcast Source transmission should include the Programjnfo length-type- value (LTV) structure metadata (defined in Bluetooth Assigned Numbers) to help users determine which broadcast Audio Stream to select.

[0010] The group identifier may be a custom metadata field (e.g., an LTV metadata field which is not the Programjnfo field and / or outside those defined in Bluetooth Assigned Numbers). Not using the Programjnfo field means that the Bluetooth LE audio broadcast source transmissions may be less identifiable by 3rdparty Bluetooth broadcast audio scanners, thereby helping the communications more private and / or secure.

[0011] In response to the received metadata comprising a priority level, the controller may be configured to enable playing of the received audio signal associated with the highest priority level in response to receiving multiple audio broadcast source transmissions from different Bluetooth LE audio broadcast sources at the same time.

[0012] The memory may be configured to store a member identifier, which uniquely identifies the device within a group of devices which store the same group identifier. The device may be configured, when acting as a Bluetooth LE audio broadcast source, to encode its member identifier into the metadata to allow the Bluetooth LE audio broadcast sinks to identify the source of the broadcast.

[0013] The device may be configured to decrypt and play the received audio data packets after, or in response to, determining that the metadata group identifier matches a said stored group identifier. An advantage of using the group identifier in this way may be that the device does not have to attempt to decrypt the audio data until it has identified that the Bluetooth LE audio broadcast source transmission is coming from within a particular group. This may be particularly important in scenarios where a device may store multiple group identifiers and associated encryption codes for decryption.

[0014] The controller may be configured to suppress playing of (e.g., not play) a received audio signal in response to receiving specified a said Bluetooth LE audio broadcast source transmission for which the associated metadata has ignore information identifying, or corresponding to, the receiving device.

[0015] The ignore command (e.g., the ignore information) may comprise a mask, wherein each member of a group is associated with a particular component of the mask, and wherein the value of each component is associated with that device either playing the received audio, or suppressing playing of the received audio. A mask may comprise a combination of numbers and / or letters. The mask may be an integer (e.g., a long or standard integer). For example, each bit field in the binary representation of the integer may correspond to the particular member of the group. The mask may also be a string. For example, each letter or number of the string may be the particular components of the mask.

[0016] In response to receiving a said Bluetooth LE audio broadcast source transmission for which the associated metadata does not include a said group identifier, the controller may be configured to enable playing of the received audio signal based on apredetermined criterion being satisfied. For example, the predetermined criterion may be when the name or Program Information (e.g., the defined PROGRAMJNFO field) of the broadcast matches a stored name or Program Information, and / or when the user confirms that they want to play the audio signal using a user interaction with the device). For example, if there are certain broadcasts that the user has decided that they want to hear automatically, they have the ability to store the name associated with that broadcast in the memory of their device. If a new broadcast audio source is within range, the user’s device may play it automatically, or notify the user, and they could decide whether or not to play the audio using a predetermined user interaction with the device.

[0017] In response to receiving a metadata packet in which the metadata includes an action command, the device may be configured to execute the action command. The action command may comprise an instruction to change the operating state of the device. The action command may comprise an instruction to turn off or enter a low-power mode. The action command may comprise an instruction to output one or more of: an audio output, a visual output, a tactile output, a stored audio, a tone pattern, and an algorithmically generated audio.

[0018] The action command may relate to any function of the device. The action command may facilitate remote control of the receiving device(s) using a transmitting Bluetooth LE audio broadcast source.

[0019] The action command may comprise an instruction for a device acting as a Broadcast Sink to decode and play the audio signal. This action command may be suppressed using ignore information. For two-way communication, in the absence of an action command within the metadata, the Broadcast Sink may be configured to play the audio signal by default.

[0020] The device may comprise a transmitter configured to transmit Bluetooth LE audio broadcast source transmissions, a said Bluetooth LE audio broadcast source transmission comprising one or more audio data packets containing an audio signal and one or more associated metadata packets. That is, the device may act as a Bluetooth LE audio broadcast source.

[0021] The controller may be configured to control the transmitter to encode at least one stored group identifier into the metadata of a said transmitted Bluetooth signal.

[0022] The controller may be configured to control the transmitter to encode at least ignore information into the metadata of a said transmitted Bluetooth LE audio broadcast source transmission.

[0023] The device may comprise a microphone, and wherein the device is configured to record audio for transmission via a Bluetooth LE audio broadcast source transmission in response to a user interaction with the device.

[0024] The device may be configured to enable half-duplex audio communication.

[0025] In accordance with the present disclosure, there is provided a system comprising multiple Bluetooth half-duplex audio devices, wherein each of the Bluetooth half-duplex audio devices store the same group identifier.

[0026] In accordance with the present disclosure, there is provided a method for playing Bluetooth half-duplex audio, the method comprising: storing one or more group identifiers in a memory; receiving a Bluetooth low energy (LE) audio broadcast source transmission, the broadcast source transmission comprising one or more Bluetooth LE audio data packets containing an audio signal and one or more associated metadata packets; controlling a speaker based on the received Bluetooth LE audio broadcast source transmission, wherein, when the associated metadata packets includes a metadata group identifier, the controller is configured to enable playing of the audio signal through the speaker only when the metadata group identifier matches a said stored group identifier.

[0027] The method may comprise: recording an audio signal; and transmitting Bluetooth LE audio broadcast source transmissions, a said transmitted broadcast source transmission comprising one or more audio data packets containing the recorded audio signal, and one or more associated metadata packets comprising a said stored group identifier.

[0028] In accordance with the present disclosure, there is provided a computer program comprising computer program code, the computer program code configured to, when executed on a device comprising a speaker and a receiver, enable the device to perform the following: store one or more group identifiers in a memory;receive a Bluetooth low energy (LE) audio broadcast source transmission, the received broadcast source transmission comprising: one or more metadata packets; and one or more associated audio data packets containing an audio signal; control a speaker based on the received Bluetooth source transmission; and enable playing of the audio signal through the speaker only when the metadata group identifier matches a said stored group identifier, in response to the associated metadata packets including a metadata group identifier.

[0029] In accordance with the present disclosure, there is provided a device comprising: a memory; a receiver configured to receive one or more Bluetooth low energy (LE) advertisement packets, the received one or more Bluetooth low energy LE advertisement packets including metadata having an action command; and wherein, in response to receiving the one or more Bluetooth low energy LE advertisement packets, the controller is configured to implement the action command.

[0030] The controller may be configured to suppress implementation of the action command in response to receiving metadata having ignore information identifying the device.

[0031] For example, receipt of a broadcast action command may be countermanded in some of the broadcast sink devices by ignore information. The action command and ignore information may be broadcast in the same Bluetooth low energy LE advertisement packets. The ignore information may identify a subset of sink devices so that some ignore the action commands while others implement the action command.

[0032] The device may be configured to transmit a Bluetooth LE audio broadcast source transmission, the transmitted broadcast source transmission comprising: one or more metadata packets comprising a metadata group identifier and an encrypted action command.

[0033] The device may be configured to transmit ignore information to direct the action command to a subset of devices within the group.

[0034] The device may be configured to facilitate communications as described above.

[0035] In accordance with the present disclosure, there is provided a device comprising: a memory;a user interface configured to generate an action command in response to a predetermined user interaction; a controller configured to create one or more Bluetooth low energy (LE) advertisement packets comprising metadata including the generated action command; and a transmitter configured to broadcast the one or more Bluetooth low energy (LE) advertisement packets.

[0036] In accordance with the present disclosure, there is provided a device comprising: a memory; a receiver configured to receive Bluetooth low energy (LE) advertisement packets, each received LE advertisement packet comprising metadata including status information; and wherein, in response to receiving one or more said advertisement packets, the controller is configured to store the status information.

[0037] In accordance with the present disclosure, there is provided a device comprising: a memory; one or more sensors configured to generate status information; a controller configured to create one or more Bluetooth low energy (LE) advertisement packets comprising metadata including the generated status information; and a transmitter configured to broadcast the one or more Bluetooth low energy (LE) advertisement packets.

[0038] The memory may store one or more group identifiers, and only store status information in response to receiving advertising packets with a metadata group identifier which matches a stored group identifier.

[0039] The device may be configured to only store status information for devices within a predetermined range (e.g., calculated using signal strength, and / or using GPS location).

[0040] The device may be configured to only store status information for devices having a predetermined member identifier.

[0041] The device may be configured to transmit one or more Bluetooth low energy (LE) advertisement packets, the Bluetooth LE advertisement packets comprising: one or more metadata packets comprising status information. The Bluetooth LE advertisement packetsmay comprise one or more of: a group identifier, a member identifier, an action command, and / or ignore information.

[0042] The status information may comprise one or more of: GPS location, speed, heading, heart rate (or any other health monitoring data), temperature, elevation, humidity, and battery level. It will be appreciated that this list is not exhaustive and that, in some embodiments, other status information may be transmitted.

[0043] In accordance with the present disclosure, there is provided a method comprising: receiving one or more Bluetooth low energy (LE) advertisement packets, the received one or more Bluetooth low energy LE advertisement packets including metadata having an action command; and implementing the action command in response to receiving the one or more Bluetooth low energy LE advertisement packets.

[0044] In accordance with the present disclosure, there is provided a method comprising: generating an action command in response to a predetermined user interaction a user interface; creating one or more Bluetooth low energy (LE) advertisement packets comprising metadata including the generated action command; and broadcasting the one or more Bluetooth low energy (LE) advertisement packets.

[0045] In accordance with the present disclosure, there is provided a method comprising: receiving Bluetooth low energy (LE) advertisement packets, each received LE advertisement packet comprising metadata including status information; and store the status information in response to receiving one or more said advertisement packets.

[0046] In accordance with the present disclosure, there is provided a method comprising: generate status information using one or more sensors; creating one or more Bluetooth low energy (LE) advertisement packets comprising metadata including the generated status information; and broadcasting the one or more Bluetooth low energy (LE) advertisement packets.

[0047] A device may be configured to transmit an action command. The device may be configured to transmit ignore information to direct the action command to a subset of devices within the group.

[0048] The device may be configured to facilitate communications as described above.

[0049] Each Group Identifier may be common to a respective group of devices.

[0050] A Group Identifier may be assigned with a predetermined duration setting, after which the Group Identifier is automatically deleted from a device. This may allow a device to be added to a group only for a predetermined period of time.

[0051] Metadata may be broadcast or transmitted within Bluetooth LE Broadcast Audio advertisements.

[0052] Devices may be configured to be compatible with the Bluetooth Core Specification Version 5.2 (which is hereby incorporated by reference in its entirety) and greater.

[0053] Devices may be configured to be compatible with the Bluetooth Public Broadcast Profile (PBP) revision v1.0 revised on July 5, 2022, (which is hereby incorporated by reference in its entirety) or later versions.

[0054] Devices may be configured to be compatible with the Bluetooth Basic Audio Profile (BAP) revision v1.0.1 revised on June 21 , 2022, (which is hereby incorporated by reference in its entirety) or later versions.

[0055] Metadata may be encoded using an LTV (length-type-value) communication protocol. Metadata may be encoded using a TLV (type-length-value) communication protocol. Types of metadata may include one or more of: Group Identifier (at least this one), Member Identifier, Ignore value, and Action command.

[0056] For half-duplex Bluetooth communications, a device may operate as an Isochronous Broadcast Source, which transmits broadcast audio and / or as an Isochronous Broadcast Sink, which receives broadcast audio. A Broadcast Isochronous Group (BIG) is created by an Isochronous Broadcast Source, and it can include one or more Broadcast Isochronous Streams (BISs). A BIS is a one-to-many data transportation stream. It uses the broadcast packet transportation mechanism without acknowledgment. Furthermore, a BIS may also be divided into one or more subevents. These subevents are the slots for broadcasting specific Broadcast Isochronous PDll which can be received and processed by unlimited Broadcast Sinks

[0057] The device may comprise a transmitter configured to broadcast Bluetooth LE audio broadcast source transmissions, the Bluetooth LE audio broadcast source transmissions comprising one or more Bluetooth LE audio data packets containing an audio signal and one or more associated metadata packets.

[0058] The receiving device may operate as a Bluetooth LE Audio Broadcast Sink. A receiving mode refers to various operation modes capable of receiving various Bluetooth advertising packets, various BIS protocol data units (PDlls), and / or various Broadcast Isochronous Group (BIG) protocol data units (BIG PDlls).

[0059] An encryption code may be used to encrypt data. An encryption code may be used to decrypt data. An encryption code may be a decryption code. An encryption code may be a broadcast code.

[0060] A transmitting or receiving device (e.g., a Bluetooth LE Audio Broadcast Source or a Bluetooth LE Audio Broadcast Sink) may be one or more of: a portable computing device, a laptop, a smartphone and a tablet.

[0061] A speaker may form part of a headphone.

[0062] A computer program may be stored on computer-readable media, such as on a non-transitory memory (e.g. CD, USB memory stick). According to the present disclosure there are also provided computer programs comprising computer program code for controlling a device to carry out the methods disclosed herein.

[0063] A memory may comprise computer program code.

[0064] A device may comprise one or more components acting in consort. A device may comprise a plurality of individual components configured to communicate with each other (e.g., a pair of wirelessly connected headphones). A device may comprise a user interface to allow the user to interact with the device. The user interface may comprise user interface elements such as one or more buttons, a touch screen, and / or a keyboard. A device may comprise one or more outputs. An output may comprise one or more of: an audio output (a speaker), and a visual output (e.g., a screen, a light).BRIEF DESCRIPTION OF THE DRAWINGS

[0065] In the Detailed Description section below, one or more embodiments of the present technology are described in relation to the attached figures. These embodiments are intended to provide a better understanding of the invention, how the invention may be put into practice, and to demonstrate some of the advantages of the invention. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of various embodiments of the invention. Similar reference numerals indicate similar components.Figure 1 a is a schematic view of a system comprising four embodiments of devices according to the present disclosures.Figure 1 b is a schematic view of the memory of one of the devices of figure 1a.Figure 2 is a flow chart showing how embodiments of communications devices can communicate using Bluetooth LE audio protocols.Figure 3 is a schematic view illustrating a use case in which three overlapping groups are created using different group identifiers.Figure 4 is a schematic view illustrating a use case in which users can selectively communicate with other users within a single group.DETAILED DESCRIPTIONIntroduction

[0066] It is well known that the Bluetooth technology does not specify how to enable halfduplex audio communication. However, a recent Bluetooth LE Audio standard (Bluetooth Core Specification Version 5.2 and greater), provides a new functionality called Broadcast Audio. This allows a device to broadcast audio to an unlimited number of Bluetooth receivers who are set up to listen to the broadcast audio. This uses a mechanism called Broadcast Isochronous Streams (BIS).

[0067] In the embodiments described below, the audio Broadcast Source may adopt the Bluetooth LE Audio technology specified by the Bluetooth Core Specification Version 5.2 or greater versions to broadcast various audio data in a way to facilitate half-duplex audio communications. In operations, the audio Broadcast Source may broadcast one or more Bluetooth LE audio packets containing audio data through a Broadcast Isochronous Stream (BIS) logical transport (hereinafter referred to as BIS logical transport). The mechanisms of transmitting and receiving this broadcast audio are defined in profile specification Basic Audio Profile (BAP). Within the BAP specification, Bluetooth advertising can attach metadata to the advertisements, and that specifies information on the organization of the broadcasted BIS stream(s).

[0068] In practice, the audio Broadcast Source may be realized with various suitable circuits or devices that support the Bluetooth communication protocol of the Bluetooth Core Specification Version 5.2 or a newer version, and that are capable of utilizing the Bluetooth LE Audio technology to broadcast the audio data. For example, the audioBroadcast Source may be realized with an audio broadcast system, a voice guidance system, a voice broadcasting system, a desktop computer, a laptop computer, a tablet computer, a mobile communication device (e.g., a mobile phone), a wearable device, a vehicular audio system, a Bluetooth smart speaker, or the like.

[0069] The Bluetooth LE Audio technology introduced by and described in the Bluetooth Core Specification Version 5.2 does not specify any profile on how to make use of the BIS audio framework to co-ordinate a half-duplex communication system amongst two or more devices.

[0070] In order to address this omission of the existing Bluetooth LE Audio technology of the Bluetooth Core Specification Version 5.2 in terms of facilitating half-duplex audio communications, the previously disclosed Bluetooth audio broadcasting capabilities are adapted to provide for these half-duplex audio functionalities.

[0071] The present technology is generally related to the BAP (Basic Audio Profile) Section 6 Broadcast audio streaming procedures. One aspect of the BAP (Section 6.5) is that it supports the Auracast™ feature in which a 3rdentity (e.g. smartphone app) can control a headphone to enable it to listen to a broadcast audio source transmission, by allowing 3rdentity (e.g., the smartphone app) to enable the device’s Broadcast Audio Sink to receive / play out a speaker. However, Auracast requires the 3rdentity, and does not support initiating a Broadcast Audio Source operation (e.g. mic to broadcast audio).

[0072] In a typical broadcast scenario, a transmitting device acts as a Broadcast Source, and each of one or more receiving devices acts as a Broadcast Sink. In preferred embodiments, a single device can act as both a Broadcast Source and a Broadcast Sink.

[0073] With profile BAP, a broadcast transmitting device can attach or associate metadata to the broadcast audio transmission packets, whether they be advertising or isochronous audio packet frames. As a Broadcast Source, the present technology adds custom metadata to enable our half-duplex audio communications using Broadcast Audio capabilities of Bluetooth 5.2 or greater.

[0074] In the present technology, the devices may always be in a Bluetooth LE scanning mode (e.g., when active or turned on), actively looking for broadcast audio as defined in BAP Section 6. This allows our devices to be in a mode where they are always receptive to receiving Bluetooth LE audio broadcasts.

[0075] In the present technology, when the transmitting device, in response to a user interaction, transmits broadcast audio, custom metadata is appended to the transmitted advertising AUX_ADV_IND packets associated with the broadcast audio stream. The metadata may comprise one or more of the following:• A unique group identification value GID (string, integer, or hash) that is intended to identify a unique private broadcast audio group that a device belongs to. Typically, this GID value is generated externally, and stored locally onto each device that belongs to a private broadcast group.• A unique member identification value MID (string, integer, or hash) is optionally attached that indicates the member identification of the device that has initiated the broadcast audio transmission. Typically, each device is assigned a unique MID for each device that is part of the group, i.e. one GID, many MID values.• a priority (PRIG) value as part of the transmitted metadata. This is used to support a priority to this transmitted broadcast audio. Broadcast Sinks can then use this priority to support a unique feature to override / suspend any present broadcast audio operations occurring on the Broadcast Sink, (user barge-in).• An ACTION code which specifies the action a Broadcast Sink will take upon receiving the broadcast audio stream. Normally, it would be an action to indicate to playback the audio on the device’s speaker, but it could specify other alternative actions.

[0076] An ignore (IGNORE) value as part of the transmitted metadata. This IGNORE value expresses to selected audio broadcast receivers that they should ignore this transmission. This is used to support a selective ACTION functionality, where by one or more users within a group would undertake the specified ACTION operation, rather than all users in a group. For example, if the ACTION was to render audio on the speaker, the receivers that are not marked for “ignore” would render the audio on the device speaker. This simplifies administration burdens by reducing the need to configure a new group with a new GID value. When our Broadcast Sink detects an incoming broadcast audio, the device seeks and extracts the custom metadata from the advertising AUX_ADV_IND packets associated with the broadcast audio stream. If the Broadcast Sink detects that there is custom metadata in the incoming broadcast, the Broadcast Sink attempts to parse it, and validate its content format according to the format we expect.

[0077] If the content format of the metadata conforms to predetermined requirements, the Broadcast Sink iterates through group broadcast record datasets locally stored on our device.

[0078] Some embodiments of the device may have one or more broadcast group records datasets stored on the device. Each record contains a GID, and optionally one or more of: MID, PRIG, IGNORE and ACTION values and a broadcast decryption value called ENCRYPTION_CODE. The Broadcast Sink iterates through the broadcast record groups to see if an incoming extracted GID matches the GID in one of our records. If there is a match, it will use the ENCRYPTION_CODE within this matched group broadcast record to decrypt the incoming audio stream.

[0079] In the preferred embodiment of our device, which can act as both a Broadcast Source and a Broadcast Sink, it can be seen that this Broadcast Sink can also reverse roles and initiate a broadcast audio transmission to other devices who have the same GID.

[0080] This functionality enables half-duplex voice communications via Bluetooth, using the fundamental building blocks of Bluetooth LE Audio broadcast capabilities. It is important to note that the presently disclosed GID methodology allows us to segregate a group of users participating in broadcast audio conversations from other groups of users who may be communicating via LE broadcast audio within Bluetooth range of the group’s user(s).

[0081] Various aspects of the invention will now be described with reference to the figures. For the purposes of illustration, components depicted in the figures are not necessarily drawn to scale. Instead, emphasis is placed on highlighting the various contributions of the components to the functionality of various aspects of the invention. A number of possible alternative features are introduced during the course of this description. It is to be understood that, according to the knowledge and judgment of persons skilled in the art, such alternative features may be substituted in various combinations to arrive at different embodiments of the present invention.Bluetooth Communication System

[0082] Figure 1a shows a simplified functional block diagram of a Bluetooth audio broadcasting system 100 according to a first embodiment of the present disclosure. The Bluetooth audio broadcasting system 100 comprises multiple Bluetooth member devices 110, 120, 130, 140, each capable of transmitting and receiving audio broadcasting data(i.e. capable of acting as both a Bluetooth LE audio broadcast source and as a Bluetooth LE audio broadcast sink).

[0083] It will be appreciated that, in other systems, there may be one or more devices which can transmit Bluetooth LE audio broadcast source transmissions, but not receive it (a dedicated Broadcast Source), and / or one or more devices which can receive Bluetooth LE audio broadcast source transmissions, but not transmit them (a dedicated Broadcast Sink).

[0084] Each of the multiple Bluetooth member devices 110, 120, 130, 140 in the Bluetooth audio broadcasting system 100 supports the Bluetooth LE technology specified by the Bluetooth Core Specification Version 5.2 or newer versions, and can transmit Bluetooth LE audio broadcast source transmissions, as well as receive and playback the Bluetooth LE audio broadcast source transmissions within radio range of the Broadcast Source. In practice, the Bluetooth audio broadcasting system 100 will comprise two or more Bluetooth member devices. For the convenience of description, only four exemplary Bluetooth member devices are illustrated in the embodiment of FIG. 1 , which respectively are a first Bluetooth member device 110, a second Bluetooth member device, 120, a third Bluetooth member device 130, and a fourth Bluetooth member device 140.

[0085] In practical applications, the aforementioned first Bluetooth member device 110, second Bluetooth member device 120, third Bluetooth member device 130, and fourth Bluetooth member device 140 may collectively form a half-duplex audio communication network.

[0086] In the embodiment of FIG. 1 , the first Bluetooth member device 110 comprises a first Bluetooth communication circuit 111 connected to a transceiver, a first audio playback circuit 112, a first audio playback circuit 113 connected to a speaker, a first audio recording circuit 115 connected to a microphone, and a first control circuit 114 connected to a memory 116.

[0087] Similarly, the second Bluetooth member device 120 comprises a second Bluetooth communication circuit 121 connected to a transceiver, a second audio playback circuit 122, a second audio playback circuit 123 connected to a speaker, a second audio recording circuit 115 connected to a microphone, and a second control circuit 124 connected to a memory 126.

[0088] In the first Bluetooth member device 110, the first Bluetooth communication circuit 111 is arranged to operably conduct Bluetooth communications via the transceiver to receive the advertising metadata packets and associated audio packets broadcasted by one of the other devices using the Bluetooth LE Audio technology.

[0089] The first control circuit 114 is coupled with the first Bluetooth communication circuit 111, the first audio processing circuit 112, and the memory 116 and arranged to operably parse the Bluetooth packets received by the first Bluetooth communication circuit 111 to acquire related information or commands and to operably control the operation of the first audio processing circuit 112.

[0090] As shown in figure 1b, in this embodiment, the memory of each device (in this case the memory 116 of the first device 110 is shown) stores a variety of information including a group Identifier (GID) which is common to members of a group to which the device belongs. Each of the members of that group stores the same Group Identifier, which is unique to the group. In this embodiment, the first device stores three recordsets, each recordset storing information to allow the device to process and play particular received Bluetooth LE audio broadcast source transmissions. In this case, the first device is a member of two communication groups, and so stored a communication recordset 116a,b for each of the two communication groups. Each communication recordset includes:• a Group Identifier (GID) unique to the group and common to the devices within the group;• a Member Identifier (MID) identifying the device within the group;• an encryption code (ENCRYPTION_CODE) which allows the device to decrypt messages sent within that group; and• an optional priority setting (PRIOR) which sets the priority of Bluetooth LE audio broadcast source transmissions.

[0091] It will be appreciated that recordsets may contain additional information, as will be described in greater detail below.

[0092] In this embodiment, the group identifiers, GID_a and GID_b, are custom metadata fields within the metadata distinct from the Programjnfo metadata field. This means that the device of a third party would not recognize the source of the transmission when, for example, it is looking for public broadcast transmissions.

[0093] It will be appreciated that, in other embodiments, the group identifier may be a Program nfo metadata field. This would allow communication to take place, but the Program information associated with the broadcast may be available to third parties, even if they may not be able to decrypt the broadcast without the associated encryption code used for decryption.

[0094] In this case, the device also contains a conventional broadcast recordset 116x. This allows a device to automatically play a conventional Bluetooth public audio broadcast by storing the name or program information of the broadcast (PROGRAMJNFO) and an associated encryption code used for decryption (ENCRYPTION_CODE). In some situations, a recordset (e.g., 116x) for a conventional broadcast may include an optional PRIOR_x field setting the priority of broadcasts received in association with the stored name or program information of the broadcast.

[0095] In this embodiment, in response to receiving a said Bluetooth LE audio broadcast source transmission for which the associated metadata includes a metadata group identifier (e.g. within the AUX_ADV_IND advertisement), the controller is configured to enable playing of the audio signal through the speaker only when the metadata group identifier matches a said stored group identifier (e.g., either GID_a or GID_b). If length of metadata is too long, it may be combined within a series of "chained" AUX_CHAIN_IND advertisements pinned to the original AUX_ADV_IND advertisement.

[0096] For example, the user of the second device 120 may wish to communicate with the rest of the group. In response to a specific user interaction (e.g., pressing a button or a voice command), the device activates the microphone, and the sound of the user’s voice is recorded by the second audio recording circuit 125. This is then processed by the second audio processing circuit to generate one or more audio packets. The one or more audio packets are transmitted in association with metadata containing a Group Identifier stored in memory 126. In this case, all four devices shown in figure 1a are in group GID_a, and so each of their memories store group identifier GID_a.

[0097] When the second device broadcasts a Bluetooth LE audio broadcast source transmission 191 comprising an audio packet in association with metadata listing a group identifier (e.g., GID_a), this will be received by the First Bluetooth Communication circuit 111 as it is within range of the transmission. The first controller will identify the group identifier Gl D_a within the metadata, and compare it with a list of one or more stored groupidentifiers in the stored memory. If there is a match (e.g., with Recordset 116a), the first control circuit will enable the first audio processing circuit 112 and the coupled first audio playback circuit 113 to process the received audio data (e.g., encoding or decoding the audio data, decrypting the audio data using associated encryption code used for decryption, ENCRYPTION_CODE_a, and / or conducting data format conversion) and to operably control the first audio playback circuit 113 to playback the audio data via the speaker.

[0098] It will be appreciated that the Audio Packets will typically be encrypted. The custom metadata (e.g., priority settings, member identifiers, action commands) may also be encrypted. The group identifier may or may not be encrypted. It will be appreciated that not encrypting the group identifier may allow devices to more quickly identify Bluetooth LE audio broadcast source transmissions from within their group.

[0099] The association between audio data packets and metadata packets within a Bluetooth LE audio broadcast source transmission may be defined in accordance with the Bluetooth Basic Audio Profile (BAP).

[0100] It will be appreciated that, in a second scenario, if the second device transmits a Bluetooth LE audio broadcast source transmission with metadata containing a group identifier which is not stored in the memory of the first device, the first control circuit 114 will not identify a match and will prevent playback of the associated audio data. This means that Bluetooth enabled Broadcast Sinks within the vicinity of the Broadcast Source, which are not members of the same group, will not hear the transmitted audio signal.

[0101] In a third scenario, if the second device transmits Bluetooth LE audio broadcast source transmission with metadata containing no group identifier, the first device may be configured to enable the first audio processing circuit 112 to process the audio data and enable playback via the speaker (e.g., in response to user confirmation via a predetermined user interaction with the device). This allows the devices to interact with conventional Bluetooth LE Broadcast signals. In some embodiments, if the broadcast name or program information is prestored as is shown for the first device 110 in figure 1a, automatic play may be enabled without a predetermined user interaction with the device to confirm playback.Method of Operation

[0102] The operations of the Bluetooth audio broadcasting system 100 will be further described below with reference to Figure 2. Figure 2 shows a simplified flowchart of a method for conducting half-duplex audio communications between a Broadcast Source and a Broadcast Sink by utilizing the Bluetooth LE Audio technology according to an embodiment of the present disclosure. It will be appreciated that a single device may be the Broadcast Source for one Bluetooth LE audio broadcast source transmission and be the Broadcast Sink for another Bluetooth LE audio broadcast source transmission.

[0103] In the flowchart of Figure 2, operations within a column under the name of a specific device are operations to be performed by the specific device. It will be appreciated that there may be multiple Broadcast Sinks within range of a Broadcast Source. Each may carry out the list of actions shown for the Broadcast Sink in figure 2. Each of the multiple Broadcast Sinks may have a different response based on information stored in their respective memories.

[0104] Regarding the Broadcast Source, the device first determines 251 whether it needs to transmit audio. Typically, audio that can be transmitted would include locally generated audio, or recorded using a microphone. In other embodiments, the audio may include audio from an external source, such as from an audio input port or a USB. For example, the user of the second device 120 of figure 1a may decide to communicate with their group, and initiate communication by performing a predetermined interaction with the device (e.g., pressing a button on the device or interacting with a user interface element on a touch screen). This moves the device into transmitting mode 252.

[0105] When in transmitting mode, the device generates 253 metadata comprising instructions (or other information). In this case, the device inserts a Group Identifier into the metadata from stored memory. This metadata is then broadcast using Bluetooth LE signals 254 as part of a Bluetooth LE audio broadcast source transmission.

[0106] The metadata may comprise a series of fields. In this embodiment, the metadata may comprise an encoding scheme for arranging the information in a format that can be understood by the Broadcast Sink. The encoding scheme may comprise an LTV (length- type-value) communication protocol. This encoding scheme allows some types of information to be present or omitted in different metadata transmissions, as the Broadcast Sink would be able to determine if a type of information is present or absent based onwhether the type is listed within the metadata. The type may indicate that the following information is a Group Identifier, and optionally a Member Identifier (e.g., for identifying the broadcast source and / or sink), an Ignore command, an Action code, and / or a Priority Level.

[0107] The device is also configured to generate 255 Bluetooth LE audio packets containing audio data which are then also broadcast in association with the metadata packets (the audio packets and metadata packets together forming the Bluetooth LE audio broadcast source transmission). In this example, the audio data is generated by recording audio using a microphone connected to the device.

[0108] In this embodiment, each Broadcast Sink is configured to continually scan 261 for Bluetooth LE audio broadcast source transmissions (e.g., as per BAP section 6). In broadcast advertising packets, it will seek appropriate custom metadata (e.g., while it is on and / or in active receiving mode).

[0109] In response to receiving 264 the metadata transmitted by the Broadcast Source, the Broadcast Sink is configured to determine 263 whether there is a Group Identifier present.

[0110] If there is no Group Identifier stored in the metadata, the Broadcast Sink is configured to treat the transmission as a conventional Bluetooth LE Broadcast Audio signal (e.g., as a public broadcast). For example, the device may be configured to determine 269 whether or not to play the received audio signal based on, for example, a predetermined rule stored on the device (e.g., if the name or program information of the broadcast is stored on the memory) and / or on a predetermined interaction by the user with the device. If the device determines that playing the audio signal is desired, the Broadcast Sink will receive 266 the corresponding Bluetooth LE audio packets, parse 267 the received Bluetooth LE audio packets to extract the audio data which is then played 268 (e.g. using a connected speaker) based on the device configuration. If playing is not desired, then the Broadcast Sink will return to scanning for metadata.

[0111] On the other hand, if the Broadcast Sink determines that there is a Group Identifier Present, the Broadcast Sink is configured to compare the metadata Group Identifier with one or more Group Identifiers stored in the memory of the Broadcast Sink.

[0112] If there is a match 264, i.e., one or more of the received metadata Group Identifiers matches a stored Group Identifier, the Broadcast Sink is then configured to receive 266the corresponding Bluetooth LE audio packets, parse 267 the received Bluetooth LE audio packets to extract the audio data which is then played 268 (e.g. using a connected speaker) based on the device configuration.

[0113] If there is a Group Identifier present, but no match 264 with the one or more Group Identifiers stored locally in the device’s memory, the Broadcast Sink is configured to ignore the broadcast Audio packets, and to continue to scan for Bluetooth LE audio broadcast source transmissions. This means that a Broadcast Sink receiving a broadcast from a group which it does not belong to, will not play the audio.

[0114] Regarding the scanning for metadata, it will be appreciated that the Broadcast Sink may continuously scan for metadata in received Broadcast Source transmissions, even while it is performing other tasks relating to received metadata. For example, embodiments may be configured to scan for metadata while playing audio data corresponding to received metadata. It will be appreciated that scanning for metadata may include scanning for Bluetooth LE advertising packets that comprise metadata according to the present disclosure.

[0115] Advantages of the present technology include that a broadcast system can be adapted to allow selective communication within a group. By using a common Group Identifier for members of a group, a signal broadcast can be selectively played by members of that group. However, while allowing restricted communication within the group, this system is still compatible with conventional Bluetooth LE audio broadcasting. For example, a Broadcast Source transmitting data without a Group Identifier can still be recognized and played by embodiments of Broadcast Sinks within range.

[0116] In some embodiments, to secure the communications within the group, each member of the group may store an encryption code in the memory of their devices. This encryption ENCRYPTION_CODE may be associated with a particular Group Identifier. When data is transmitted within the group, the metadata and audio data may be encrypted using the encryption ENCRYPTION_CODE. This prevents an unauthorized device from playing the audio data, even if they identify the Group Identifier. Generally, the encryption code is not transmitted using the Bluetooth LE signals. For example, each device may be provided with the encryption ENCRYPTION_CODE in advance (e.g., using a secure wireless connection, or using a wired connection to a computer). In some circumstances,the encryption code may be transmitted wirelessly once, e.g., upon adding a device to a group, but this may risk interception.Use Cases

[0117] As discussed above, typical two-way radios / walkie talkies do not allow you to isolate your voice communications from outside groups. But in many cases, users want their own private, isolated, and preferably encrypted communications kept separate from users outside of their group.

[0118] As described above, to support isolated voice communication groups, metadata is transmitted or broadcast in association with Broadcast Low Energy audio. This metadata includes a Group Identifier (GID) which is common to all devices within the group.

[0119] For LE Broadcast Audio used as per the present disclosure, LE Audios encryption capabilities are typically used. For LE Audio encryption, a unique encryption and / or encryption code used for decryption, ENCRYPTION_CODE, is typically used for each group. This ENCRYPTION_CODE is not placed in the metadata.

[0120] All devices that belong to a group have one or more group records that include a Group Identifier (GID) and possibly one or more of: the broadcast decryption ENCRYPTION_CODE value and other instructions or information as will be described below.

[0121] The above GID value is expected to be unique to a user group.Broadcast Across Multiple Groups

[0122] This use case allows broadcast audio communications across multiple groups.

[0123] There are several scenarios which may use this capability. For example, in the context of a heli-skiing tour group, there are many skiing clients, escorted by skiing guides. Figure 3 shows an example of how Group Identifiers facilitate directed communication within multiple overlapping groups.

[0124] In this example, there are two clients: a husband and wife. They already own Bluetooth headphones 341 , 351 according to the present disclosure, and they already have set up their headphones with their own unique group (GID, etc.). This group may be called HUSBANDWIFE. Each device within the HUSBANDWIFE group stores a Group Identifier, GID_HW in the memory.

[0125] In this use case, the skiing guides also have Bluetooth headphones 311 , 321 according to the present disclosure. They have their own group called HELI PARTY which is intended to allow all parties on the ski trip to communicate, both guides and clients. The group HELIPARTY is associated with the Group Identifier GID_HP, which is initially stored in the memory of the devices of the guides. Because HELIPARTY and HUSBANDWIFE groups are initially isolated, they cannot communicate with each other.

[0126] To allow this, a Bluetooth device according to the present disclosure are configured to belong to multiple group(s) simultaneously by storing multiple recordsets, each recordset containing a Group Identifier and an associated encryption code. It will be appreciated that a recordset may also include other information to enable other functionality. E.g., information identifying the member of the group (PRIG), a priority setting (PRIG) etc.

[0127] The husband and wife can add the HELIPARTY group by receiving and storing the Group Identifier GID_HP on the memory of their devices (via various means), and now their headphones can respond to and optionally initiate LE Audio Broadcasts on both the HUSBANDWIFE and HELIPARTY groups.

[0128] In this embodiment, the Group Identifier GID_HP recordset is stored on the husband and wife’s devices with a predetermined assigned predetermined duration (e.g., 2 days following the Group Identifier being stored, or until a certain predetermined time). After this duration has elapsed, the Group Identifier is deleted from the device. This optional feature means that the husband and wife are only part of the HELI PARTY group forthat predetermined duration (e.g., corresponding to their participation with the heliskiing company). If they are planning to remain in the area after their participation, they would automatically be removed from the HELIPARTY group, and so would not receive unwanted messages from guides who may then be working with other clients using the same group. It will be appreciated that, in other embodiments, one a Group Identifier is stored, it may persist until actively removed from the device.

[0129] In this use case, there is no need for the HELI PARTY group to administratively join the customer’s HUSBANDWIFE group.

[0130] For HUSBANDWIFE users, they have the option to configure a specific method on their device to selectively initiate a broadcast audio to the HELIPARTY group, instead of to solely their HUSBANDWIFE group. That is, each group may be associated with arespective user interaction with the device, such as voice commands (if the headphones have that capability). Or it could be via configuring one or more headphone buttons to selectively initiate communication with different groups (e.g., press one button for HUSBANDWIFE, press a different button for HELI PARTY). The headphone button could be physically local to their headphones, or it would be wireless relayed via a wireless “button” device mounted on their finger, or on a wrist strap, or it could be activated via smartphone app. It will be appreciated that other options are available to allow a user to interact with a device to selectively initiate communications with different groups.

[0131] Note that there are times where the skiing guides want to communicate amongst themselves, and not have their clients hear them (e.g., deciding the best route down). In this scenario, the skiing guide’s headphones could also belong to a second group called HELIGUIDES associated with Group Identifier, GID_HG. As only the guide devices 311 , 321 store this Group Identifier, GID_HG, when one guide broadcasts an audio stream in association with this Group Identifier, only the other guide’s device will play the audio, even when the Husband and Wife’s devices 341 , 351 are within broadcast range.

[0132] This gives them the capabilities to discretely talk amongst themselves, not to the HELI PARTY group. This is very useful for various privacy reasons. Today, it is common for these heli-skiing participants to all have two-way radio, where all participants hear each other’s communications. It is common policy for the clients to be told to only use the radio on a limited, restricted basis. This ensures that the whole group is not disturbed by a lot of general voice chatter amongst participants. But, by using the present technology, clients can freely chatter without restriction. For example, for HUSBANDWIFE group, this improves client safety, because they can communicate freely amongst themselves either for social reasons or for alerting each other to a safety issue local only to them (e.g., “look out for the big rock ahead ...”). They still also have a simple option to communicate with the wider HELI PARTY group.

[0133] It will be appreciated that other devices within Bluetooth LE audio range, and outside the groups listed, would not be bothered by communications within the groups described above.Priority Communications

[0134] In some cases, it may be helpful for one group’s transmissions to override the transmissions (or receptions) of another group.

[0135] With the heli-skiing tour group scenario described above in relation to Figure 3, HUSBANDWIFE may presently be engaged in a half-duplex (or maybe even full duplex) voice conversation via their Bluetooth connection. With conventional walkie talkies, there are no methods for anyone else to “barge-in” on that conversation. In the skiing guides scenario, the guides may want to make sure their voice communications always have priority over their client’s voice communications. This is extremely important if there is imminent danger, or if they simply want to interrupt their ongoing conversation and instruct their clients in some manner.

[0136] To facilitate this, a priority level may be encoded in the metadata within a PRIO field.

[0137] The Broadcast Sink can be configured such that, in response to the metadata comprising a priority level, the controller is configured to enable playing of the received audio signal associated with the highest priority level in response to receiving multiple associated Bluetooth LE audio data packets from different sources at the same time.

[0138] In the context of this use case, the HELIPARTY group would have been assigned a higher priority than the HUSBANDWIFE group.

[0139] When the husband and wife users are presently engaged on a HUSBANDWIFE broadcast, the headphone may simultaneously detect an incoming HELIPARTY broadcast. Their headphones would evaluate the PRIO priority in the incoming broadcast metadata, and recognize that the HELI PARTY broadcast is at a higher priority. It would then cease playing the ongoing HUSBANDWIFE broadcast, and they would start to listen to the HELI PARTY broadcast.

[0140] In this example, the guide’s devices are configured to encode metadata encoding a higher priority into all transmissions via the HELIPARTY group, such that communications from the guides using this Group will always take precedence over another group (or communications from the clients via the HELI PARTY group) based on their priority levels.

[0141] In other scenarios, the devices may allow a priority to be assigned to particular communications. For example, a group may have a default priority level assigned, but the user of a Broadcast Source may want to override other users’ communication in certain circumstances (e.g., in an emergency). In such cases, the user may elect to assign a higher priority to a particular communication (e.g., by using a particular user interactionwith the device). This higher priority would be encoded into the metadata for that communication alone, after which the priority from that Broadcast Source may be returned to the default. Other embodiments may assign priority levels to different devices so that a leader within the group may have a device which automatically transmits metadata indicating a higher priority than other members of the group.

[0142] It will be appreciated that transmissions without a priority level may be assigned a default priority level by the Broadcast Sink.Directed Communications

[0143] In the use cases, we have focused on broadcasting to all other members of a group. In some cases, it may be useful to initiate voice broadcast to only a subset of users in a group. In some cases, the subset might correspond to the device of a single user.

[0144] For example, a motorcycle instructor with a device 411 may be taking a group session with a group of student riders in a large parking lot, each rider having their own device 421 , 431 , 441 , 451. Currently, an instructor might use a megaphone to “yell” out instructions or guidance to their students. All students hear that communication. Sometimes due to the fact that they are wearing the helmet, and / or the fidelity of the megaphone, they do not hear the instructions well. Or they do not notice that the instruction is directed at them personally. It will be appreciated that this method causes strain on both the instructor and the students.

[0145] Using the present technology, the instructor has a Broadcast Source with a microphone (at least), and all the students have a Broadcast Sink with a speaker (at least). All devices belong to a single group (TRAINING) that is common to instructor and students. Each device within the TRAINING group has a Group Identifier GID_T stored on the memory of their devices.

[0146] In many situations, the instructor will initiate broadcast audio communications to everyone via the TRAINING group. This replicates the functionality of the megaphone in that they can communicate with all the students at the same time, but in this scenario, they don’t have to raise their voice, and they can talk at normal voice level and all students clearly hear their instructions.

[0147] In other situations, the instructor may only want to communicate with a subset of the group of student riders. It could be an individual rider, or a small group of riders.

[0148] In this embodiment, the instructor may have an app on his phone / watch / tablet, which shows an icon for all the members of the TRAINING group. Each member “icon” could have the name of the person, or even a picture of that person. It could even display the unique MID value for each rider. The instructor could select, for example, rider 2 and rider 3 out of a group of 4 on the app.

[0149] This would generate a “bitmask” IGNORE field which is then broadcast by the device in metadata as part of a Bluetooth LE audio broadcast source transmission. In this embodiment, the mask 492 comprises an integer with a digit associated with each Broadcast Sink within the group. In this case, the mask includes a digit associated with the Broadcast Source so that the same bit mask structure can be used by all devices within the group. The value of the digit determines whether the Broadcast Sink will ignore the audio transmission or play the audio transmission. In this embodiment, a 0 corresponds to playing the audio transmission, and a 1 corresponds to ignoring the audio transmission.

[0150] The mask would be broadcast within the metadata of a Bluetooth LE audio broadcast source transmission by the Broadcast Source 411 to all the Broadcast Sinks 421 , 431 , 441 , 451.

[0151] As shown in figure 4, all bitmask bit positions in the mask in the IGNORE field would be set to 1 for all riders, except for the riders 2 and 3. This means that the devices acting as Broadcast Sinks will all receive the metadata, but riders 1 and 4 will ignore it and not play the broadcast audio, whereas the devices of riders 2 and 3 will play the broadcast audio.

[0152] This IGNORE instruction allows the instructor to create subgroups dynamically and adaptively within the same single group TRAINING. This may reduce the need to administratively create unique isolated groups, which may be overly onerous.

[0153] In other situations, the riders may have devices which are also able to transmit audio data. For example, they may want to talk back also on the TRAINING group. By default, their broadcast voice communication would go to the instructor and all the other riders, since the IGNORE field bitmask defaults to all users. This may be undesirable in this use case. So, the motorcycle training company may pre-configure all the rider’s Broadcast Sink to use a default IGNORE field such that rider communications are directed only back to the instructor(s).

[0154] The usage of MID may be useful in other ways. An instructor may find it easier to reference a rider by a number, instead of their name. The app could show the MID number, and the rider could have a large numeric sticker with the MID number on their helmet, or a bib number attached to the rider in some manner. The instructor can then visually see the MID number clearly and use their app to quickly select the rider(s) via their MID number(s).Specified Action

[0155] In some scenarios, there is a desire for the ability to specify different actions in a Bluetooth LE audio broadcast source transmission. This capability is implemented via usage of the ACTION field within the transmitted metadata. It will be appreciated that this ACTION field will be used in response to determining that the device is within the group associated with a common Group Identifier. For this use case, it will be appreciated that associated audio data may or may not be required.

[0156] There are certain use cases where rather than rendering audio upon a broadcast audio reception, it may be desired that the Broadcast Sink undertake a different action. One example could be where audio is not transmitted, but the ACTION field could indicate playing a simple or complex tone to the recipient. This would be useful to garner the attention of the users, without the initiator on the Broadcast Source having to expend their voice. It could be a simple double-tone that garners the attention of the users.

[0157] This ACTION field would be part of the metadata in a LE Broadcast audio transmission. Attachment of metadata to LE Broadcast Audio advertisements is as described above.

[0158] Based on LE Audio methodologies, the metadata is “advertised” by already defined standard Bluetooth 5.x advertising standard mechanisms, i.e. This is accomplished in Bluetooth by extended (AUX_ADV_IND) and extended synchronized (AUX_SYNC_IND) advertising.

[0159] For this use case, this GID / MID / ACTION data could be simply attached to an extended advertising packet that is not associated with a LE Broadcast Audio advertisement.

[0160] It will be appreciated that extended and extended synchronized advertising is not a unique capability to support LE Broadcast Audio. Bluetooth devices are free to use this capability for other purposes.Status Advertising

[0161] In some embodiments, the device may be configured to advertise information periodically, either asynchronously or synchronously, or “on demand” or upon an “event”. The advertised information may include helpful information to other devices within the same group(s), or even to any Bluetooth advertisement listener.

[0162] Advertisements can have custom metadata attached to them, as is used for LE Audio Broadcast operations. But there may be use cases, where a device according to the present disclosure may periodically broadcast advertising data not associated in any manner with a LE Audio Broadcast operation.

[0163] This capability can be used for delivering information to other devices within a group, or even other conventional Bluetooth devices.

[0164] In some embodiments, a device may have access to GPS, accelerometer, gyroscope and / or any other sensor data. It may have access to this data via integrated circuits resident on the headphone, wired into a headphone or accessible via other wireless links to the headphone, including Bluetooth itself. This sensor data may be processed by the controller to create advertising packets containing status information based on this sensor data.

[0165] With this capability, the device may periodically advertise status information to other devices, and attach metadata as previously described. It will be appreciated that this status information may increase user awareness, either within the group, or to interested parties outside the group (e.g., to search and rescue personnel).

[0166] The advertisement packets containing the status information may also contain various combinations using the same GID, MID, ACTION, IGNORE, PRIO fields as used in our half-duplex LE Broadcast audio advertisements. In addition, it could attach further metadata that conveys a wide range of optional status information such as one or more of: GPS location, speed, heading, heart rate (or any other health monitoring data), temperature, elevation, humidity, and battery level.

[0167] Due to metadata length limitations, it likely could not convey large amounts of metadata in one advertisement, but it could cycle through different metadata on a rotating basis (e.g. in successive transmissions), or make use of longer length advertising techniques such as AUX_CHAIN_IND

[0168] Usually, this type of data would be advertised at a relatively slow rate, maybe every 15 or 30 seconds, to maximize battery life. But this time interval could be configurable, or it may auto-adjust based on certain events.

[0169] For example, upon a safety event (e.g. a serious fall, user is upside down, high impact, etc., as detected by sensors), the advertising device can increase this advertising to a much faster rate. (e.g. 100ms)

[0170] A much higher rate reduces the device’s battery life, but that is less important in this scenario. For many sports, a delay of 15-30 seconds could mean Broadcast Sinks become out of range within that timeframe. So, a more immediate advertising is warranted, and could be lifesaving.

[0171] This capability can be of extraordinary value. Consider the heli-skiing group. Heliskiing is associated with significant risks of injury and death, including becoming lost, falling, avalanches, and becoming stuck (e.g., in a tree well).

[0172] Bluetooth communication ranges are now quite significant (1 km+ and farther is possible). This opens up safety innovations for adventure groups, in a way that is very friendly and affordable.

[0173] In one scenario, the devices, according to the present disclosure, are always listening (scanning) for LE advertisements for our group, and it can also pick up our “informative group” advertisements from our group that are not associated with a broadcast audio operation.

[0174] This allows headphones to build awareness data of all other headphones belonging to their group within range. This data can remain local to the headphone, and all or a subset of this awareness data can be relayed to an external device such as a smartphone.

[0175] The sensors may have data that indicates to them that the safety event is over, and can restore the original slow-paced advertisement, allowing battery life to be maximized. This could be restored also by user actions. For example, the headphone could play an audio prompt asking user to press button(s) to “cancel” the safety event. This is helpful if they have a bad fall, but are otherwise fine, and there is no need to alert other users.

[0176] With this new capability, we can introduce a new field or type called EVENT in the advertised metadata. This can be useful here, since it can relay many event indicationssuch as fall, bad fall, very serious fall / impact, or even a “cancel” action. Upon receiving such an ACTION, a receiving headphone could initiate a tone alert, play an informative audio prompt, or something to grab the attention of the recipient.

[0177] Even without a serious safety event, this feature may be extraordinarily helpful. For example, a group of skiers may have lost sight of their colleague. If a user’s headphone device is communicating (via Bluetooth typically) to a user’s smartphone device, they could simply pull out their smartphone app, and see the location, speed, bearing, biometric data of anyone within their group. It would show recent data of any user within Bluetooth range but could have cached data of other users who are presently out of range. That way, one would at least know the last known location of a user.Hibernate Instructions

[0178] In some scenarios, it may be desirable to have the ability to put a device into a low-power “hibernate” state.

[0179] This topic may be particularly useful for devices used by Heli skiers and snowmobilers in the mountains. Many snowmobilers currently use “motorcycle” Bluetooth systems that provide them with full-duplex audio communication. The range of communication is adequate, albeit reduced in a forested environment as compared with the open road experienced by a motorcycle. It will also be appreciated that, in the mountains, avalanches are of a serious concern, and adventurers in the mountains are strongly advised to wear an avalanche beacon.

[0180] However, these “motorcycle” Bluetooth systems typically interfere with avalanche beacons. Therefore, if a user was unfortunately caught in an avalanche and was buried, users searching for the buried person may fail to detect the buried individual due to the strong Bluetooth RF signals generated by the Bluetooth radio in the “motorcycle” Bluetooth system.

[0181] For this reason, the usage of “motorcycle” Bluetooth systems in avalanche-prone areas is strongly discouraged. Even if this Bluetooth system was not actively transmitting, the local electronic noise generated by an electronic device can still interfere with an avalanche beacon that a user is wearing.

[0182] In the context of the present disclosure, if a device obtains sensor data corresponding to an avalanche burial event, the device can autonomously enter a hibernate, or even a full power-down state to ensure that the device would not interferewith an avalanche beacon. This capability would assuage the concerns of users who want a Bluetooth communication system, but are wary of operating in an avalanche area.

[0183] Typically, we would detect an avalanche burial event via sensor data such as accelerometer, and optional gyroscope data. For example, based on accelerometer data, the device can detect high level of motion across all x / y / z axes. For a burial event, this initial high-acceleration data would settle into virtually no movement on x / y / z axes. A predetermined period of time after such a sensor data profile, the device may be configured to automatically enter into the hibernate or power-down state, well before any users have initiated a beacon search.

[0184] In addition, some embodiments may be configured to use the ACTION command described above to control a device to deactivate itself. This would allow searchers to deactivate a user’s device in order to facilitate a beacon search.Encrypted and Unencrypted Communication

[0185] Generally, embodiments of the present disclosure may send encrypted metadata, which can only be decrypted if the receiving device has the correct encryption code used for decryption. It will be appreciated that this is important for privacy purposes. In some embodiments, the Group Identifier itself is encrypted (e.g., in cases where the Group Identifier is not a Program nfo LTV metadata field as defined in the PBP specification). In situations where the Group Identifier is a Programjnfo LTV metadata field as defined in the PBP specification, the Group Identifier may not be transmitted in an encrypted format.

[0186] However, there may be some scenarios where the data is transmitted which is non-encrypted. For example, in the case of a serious safety event (e.g., when a user is lost or incapacitated) there may be difficulty in users who are part of the same GID to find that user.

[0187] In such scenarios, this would involve calling in other parties, or even search-and- rescue teams, to help find that user. Due to the longer-range distances possible with the newer Bluetooth implementations, transmitting an unencrypted advertisement could be beneficial in allowing any user in the vicinity to find the person in difficulty.

[0188] For example, searching parties could use some Bluetooth 5.x device to help scan for a status advertisement, that is periodically advertising. But they may not know of or have access to the distressed user’s GID / CODE information. Hence their devices coulddetect the distressed user’s Bluetooth 5.x advertisements but would not be able to decrypt the status metadata information.

[0189] Therefore, there may be advantages to allowing such status advertisement transmissions in an unencrypted format.

[0190] On the distressed user’s device, it has the capability to transmit metadata in unencrypted format. We would call this a “search recovery” mode. The transmitted metadata may comprise sensor information (e.g., location information, health status information, motion information). When transmitting unencrypted data, it would transmit all or a subset of the metadata normally transmitted. Obviously, GPS location is the most important piece of data. The user’s device could enter “search recovery” mode:• Based on unique safety events detected on the distressed user’s device, e.g. impact events, no motion for a long time, no user cancel operation, etc.• Based on a distressed user intentionally putting their device in “search recovery” mode (e.g. using a particular user interaction with the device, such as a button press sequence, setting via smartphone app, etc.).• Transmitting an ACTION command to instruct the receiving device to enter a “search recovery” mode. It will be appreciated that this ACTION command may be associated with a Group Identifier and an IGNORE field to allow selective activation of the “search recovery” mode.

[0191] In a preferred implementation, the distressed user’s device may rotate transmitting status metadata on its GID group, followed by an unencrypted transmission. This would allow GID group members to still have the opportunity to locate their group member, via the previous methods described.

[0192] In scenarios whereby the user is lost, but their device is not in “search recovery” mode, it will be appreciated that search operations may be impaired for those who do not have the GID / CODE information. There are various methods to overcome this:• group users could share GID / CODE information with external search parties. That would solve this problem, but may not always be practical.• the distressed user’s device could respond to special unencrypted advertising data broadcast from a searching party’s Bluetooth 5.x device. This method may be insecure and could be abused by bad actors, i.e. a malicious actor tracking a user’s someone’s location. But for some users, this risk is warranted. So embodimentsmay have an administrative option to enable this feature. This could optionally be enabled on a time-limited or geographical basis. The geographical basis may be the most useful and practical, e.g. via smartphone app, they could indicate that a geo-fence area where this feature would be enabled. Let’s call this feature mode “search party unencrypted enable” (SPUE).

[0193] If SPUE is enabled, an external “searching” party’s Bluetooth 5.x device could put specified metadata on its extended advertising in unencrypted format. If the distress user’s device detects this special SPUE metadata, it would force the device to enter “search recovery” mode.

[0194] The above method could still be a security concern for some users. Lastly, embodiments may have a specific hidden ENCRYPTION_CODE / metadata complex sequence to “unlock” a device to allow a device to enter “search recovery” mode. This could be an administrative option that may be more acceptable to groups with the highest security concerns. For example, a group of military soldiers.

[0195] Although the present invention has been described and illustrated with respect to preferred embodiments and preferred uses thereof, it is not to be so limited since modifications and changes can be made therein which are within the full, intended scope of the invention as understood by those skilled in the art.

Claims

CLAIMS1. A device for enabling Bluetooth audio communication, comprising: a speaker; a memory, the memory configured to store one or more group identifiers; a receiver configured to receive Bluetooth low energy (LE) audio broadcast source transmission, the received broadcast source transmission comprising: one or more metadata packets; and one or more associated audio data packets containing an audio signal; and a controller configured to control the speaker based on the received broadcast source transmission, wherein, in response to receiving one or more said metadata packets including a metadata group identifier, the controller is configured to enable playing of the audio signal through the speaker only when the metadata group identifier matches a said stored group identifier.

2. The device according to claim 1 , wherein, in response to the received metadata comprising a priority level, the controller is configured to enable playing of the received audio signal associated with the highest priority level in response to receiving multiple broadcast source transmissions from different Bluetooth LE audio broadcast sources at the same time.

3. The device according to any one of claims 1-2, wherein the memory is configured to store a member identifier, which uniquely identifies the device within a group of Bluetooth half-duplex audio devices which store the same group identifier.

4. The device according to any one of claims 1-3, wherein the device is configured to decrypt and play the received audio data packets in response to determining that the metadata group identifier matches a said stored group identifier.

5. The device according to any one of claims 1-4, wherein the controller is configured to suppress playing of a received audio signal in response to receiving specified a said Bluetooth LE audio data packet for which the associated metadata has ignore information identifying the device.

6. The device according to any one of claims 1-5, wherein the ignore command comprises a mask, wherein each member of the group is associated with a particularcomponent of the mask, and wherein the value of each component is associated with that device either playing the received audio, or supressing playing of the received audio.

7. The device according to any one of claims 1-6, wherein, in response to receiving a said Bluetooth LE audio data packet which does not include a said group identifier, the controller is configured to enable playing of the received Bluetooth LE audio in response to a predetermined criterion being satisfied.

8. The device according to any one of claims 1-7, wherein, in response to receiving a packet in which the metadata includes an action command, the device is configured to implement that action command.

9. The device of claim 8, wherein the action command comprises an instruction to change the operating state of the device.

10. The device of claim 9, wherein, in response to receiving an instruction to change the operating state of the device, the device is configured to turn off or enter a low-power mode.

11. The device according to any one of claims 8-10, wherein the action command comprises an instruction to output one or more of: an audio output, a visual output, a tactile output, a stored audio, a tone pattern, an algorithmically generated audio.

12. The device according to any one of claims 1-11, wherein the device comprises a transmitter configured to transmit Bluetooth LE audio broadcast source transmissions, each broadcast source transmission comprising one or more audio data packets containing an audio signal and one or more associated metadata packets.

13. The device according to claim 12, wherein the controller is configured to control the transmitter to encode at least one stored group identifier into the metadata of a said transmitted Bluetooth LE audio broadcast source transmission.

14. The device according to any one of claims 12-13, wherein the controller is configured to control the transmitter to encode ignore information into the metadata of a said transmitted Bluetooth LE audio broadcast source transmission.

15. The device according to any one of claims 12-14, wherein the device comprises a microphone, and wherein the device is configured to record audio for transmission via Bluetooth audio LE in response a user interaction with the device.

16. The device according to any one of claims 1-15, wherein the device is configured to enable half-duplex audio communication.

17. A system comprising multiple Bluetooth half-duplex audio devices, wherein each of the Bluetooth half-duplex audio devices store the same group identifier.

18. A method for playing Bluetooth half-duplex audio, the method comprising: storing one or more group identifiers in a memory; receiving a Bluetooth low energy (LE) audio broadcast source transmission, the received broadcast source transmission comprising: one or more metadata packets; and one or more associated audio data packets containing an audio signal; controlling a speaker based on the received broadcast source transmission, wherein, when the one or more metadata packets includes a metadata group identifier, the controller is configured to enable playing of the audio signal through the speaker only when the metadata group identifier matches a said stored group identifier.

19. The method according to claim 18, wherein the method comprises: recording an audio signal; and transmitting Bluetooth LE audio broadcast source transmissions, the transmitted broadcast source transmissions comprising one or more Bluetooth LE audio data packets containing the recorded audio signal, and one or more metadata packets comprising a said stored group identifier.

20. A computer program comprising computer program code, the computer program code configured to, when executed on a device comprising a speaker and a receiver, enable the device to perform the following: store one or more group identifiers in a memory; receive a Bluetooth low energy (LE) audio broadcast source transmission, the received broadcast source transmission comprising: one or more metadata packets; and one or more associated audio data packets containing an audio signal; control a speaker based on the received Bluetooth source transmission, enable playing of the audio signal through the speaker only when the metadata group identifier matches a said stored group identifier, in response to the one or more metadata packets including a metadata group identifier.

21. A device, comprising: a memory;a receiver configured to receive Bluetooth low energy (LE) advertisement packets, the received Bluetooth LE advertisement packets comprising metadata including an action command; and wherein, in response to receiving one or more said advertisement packets, the controller is configured to implement the action command.

22. The device according to claim 21, wherein the controller is configured to suppress implementation of the action command in response to the Bluetooth LE advertisement packets comprising metadata having ignore information identifying the device.

23. A device, comprising: a memory; a receiver configured to receive Bluetooth low energy (LE) advertisement packets, each received LE advertisement packet comprising metadata including status information; and wherein, in response to receiving one or more said advertisement packets, the controller is configured to store the status information in the memory.

Images