Patent Description:
Aspects and implementations of the present disclosure are generally directed to systems and methods for broadcasting and receiving wireless data streams, e.g., broadcasting and receiving wireless data streams between wireless devices.

Speaker systems, for example, wireless multi-speaker systems typically attempt to receive each successive wireless packet at each device of the system simultaneously. For example, a central device may send wireless data intended for all peripheral devices. Each peripheral device is responsible for receiving each packet of data and potentially rendering the data into acoustic energy. However, the quality of these systems suffers when one or more of the peripheral devices begins to start to miss or drop packets of data. For example, one peripheral device may be positioned far away from the central device or may experience interference leading to a significant amount of dropped packets. With enough dropped packets, the effected peripheral device may significantly hinder the function of the system, and/or significantly effect the user's enjoyment of the system.

<CIT>, <CIT>, <CIT> and <CIT> disclose prior art systems involving wireless data streams.

The present disclosure provides more robust systems and methods for broadcasting wireless data that utilize one or more retransmission schemes to increase the packet reception within a given wireless system. In some examples, one or more devices of the system are configured to listen for an initial data packet from a source device. Should one or more devices successfully receive the initial data packet, each device that received the packet can unconditionally retransmit, via their own respective broadcast stream, a retransmitted copy of the payload of the initial packet such that any device that failed to receive the initial packet payload has an opportunity to receive it during the respective retransmissions. Similarly, each device of the system can send acknowledgements to the other devices of the system that indicate whether they received the initial packet. Should one or more of the devices successfully receive the initial data packet, the devices can conditionally retransmit, via their own respective broadcast stream, a retransmitted copy of the payload of the initial data packet only when one or more devices indicates they have failed to receive it.

The present invention relates to methods and a system according to the independent claims. Advantageous embodiments are set forth in the dependent claims.

These and other aspects of the various embodiments will be apparent from and elucidated with reference to the embodiment(s) described hereinafter.

Also, the drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the various embodiments.

The term "wearable audio device", as used in this application, in addition to including its ordinary meaning or its meaning known to those skilled in the art, is intended to mean a device that fits around, on, in, or near an ear (including open-ear audio devices worn on the head or shoulders of a user) and that radiates acoustic energy into or towards the ear. Wearable audio devices are sometimes referred to as headphones, earphones, earpieces, headsets, earbuds or sport headphones, and can be wired or wireless. A wearable audio device includes an acoustic driver to transduce audio signals to acoustic energy. The acoustic driver can be housed in an earcup. While some of the figures and descriptions following can show a single wearable audio device, having a pair of earcups (each including an acoustic driver) it should be appreciated that a wearable audio device can be a single stand-alone unit having only one earcup. Each earcup of the wearable audio device can be connected mechanically to another earcup or headphone, for example by a headband and/or by leads that conduct audio signals to an acoustic driver in the ear cup or headphone. A wearable audio device can include components for wirelessly receiving audio signals. A wearable audio device can include components of an active noise reduction (ANR) system. Wearable audio devices can also include other functionality such as a microphone so that they can function as a headset. While <FIG> shows an example of an in-the-ear headphone form factor, in other examples the wearable audio device can be an on-ear, around-ear, behind-ear, over-the-ear or near-ear headset, or can be an audio eyeglasses form factor headset. In some examples, the wearable audio device can be an open-ear device that includes an acoustic driver to radiate acoustic energy towards the ear while leaving the ear open to its environment and surroundings.

The term "connected isochronous stream" as used herein, in addition to including its ordinary meaning or its meaning known to those skilled in the art, is intended to refer to an isochronous data stream which utilizes a preestablished, point-to-point communication link over LE Audio between, e.g., a source device (which may also be known as a central or master device) and an audio device or a plurality of audio devices (which may also be known as a peripheral or slave device(s)). In other words, a connected isochronous stream can provide an isochronous audio stream which utilizes at least one established reliable communication channel and/or at least one acknowledged communication channel between the source device and any respective audio devices.

The term "broadcast isochronous stream" as used herein, in addition to including its ordinary meaning or its meaning known to those skilled in the art, is intended to refer to an isochronous data stream which does not require a preestablished communications link to be established between the source device sending data and the audio device receiving data and does not require acknowledgements or negative acknowledgements to be sent or received.

The following description should be read in view of <FIG>. <FIG> is a schematic view of system <NUM> according to the present disclosure. System <NUM> includes a plurality of devices, e.g., at least one source device <NUM> and a plurality of wireless devices 104A-104F (collectively referred to as "plurality of devices <NUM>", "wireless devices <NUM>," or "devices <NUM>"). In the example shown in <FIG>, source device <NUM> is illustrated as a tablet; however, it should be appreciated that the at least one source device <NUM> can be selected from at least one of: a smartphone, a smarthub, media hub, a stereo hub, a soundbar a headphone case, or any device capable of sending or broadcasting wireless data, e.g., wireless data <NUM> (discussed below) to each of the wireless devices <NUM>. In some examples, more than one source device <NUM> may be provided.

Each of the plurality of devices <NUM> is intended to be a device capable of receiving wireless data from source device <NUM>, and in some examples, utilizing the wireless data to generate audible acoustic energy within the environment surrounding each device, e.g., to generate sound via at least one speaker, e.g., speakers <NUM> (discussed below). As illustrated in <FIG>, in some examples, plurality of devices <NUM> are the respective components of a <NUM> surround-sound system, e.g., a <NUM> Dolby Digital Surround-Sound System. In the example illustrated, devices 104A-104C are front-left, front-center, and front-right speaker assemblies, respectively. Additionally, devices 104D-104E are left-rear or left-surround and right-rear or right-surround speaker assemblies, respectively, and device 104F is a subwoofer speaker assembly. It should be appreciated that plurality of devices <NUM> can also include wearable audio devices such as wireless headphones, truly wireless headphones, wireless hearing aids, portable speakers, paired speakers or paired portable speakers, as well as a wired or wireless charging case configured to matingly engage with and charge one or more wearable audio devices.

As illustrated schematically in <FIG>, each device of plurality of devices <NUM> and each source device <NUM> can each include internal circuitry, e.g., circuitry <NUM>. Circuitry <NUM> includes a processor <NUM> and a memory <NUM> configured to execute and store, respectively, a plurality of non-transitory computer-readable instructions <NUM>, to perform the various functions of source devices <NUM> and plurality of devices <NUM> as will be described herein. Circuitry <NUM> also includes a communications module <NUM> configured to send and/or receive wireless data, e.g., data relating to at least one of the plurality of wireless data streams discussed below, e.g., BIS stream <NUM>. To that end, each communications module <NUM> can include at least one radio or antenna, e.g., radio <NUM> capable of sending and receiving wireless data. In some examples, each communications module <NUM> can include, in addition to at least one radio (e.g., radio <NUM>), some form of automated gain control (AGC), a modulator and/or demodulator, and potentially a discrete processor for bit-processing that are electrically connected to processor <NUM> and memory <NUM> to aid in sending and/or receiving wireless data. As will be discussed below, circuitry <NUM> of each device <NUM> can also include at least one speaker, i.e., speaker <NUM>, which is, e.g., a loudspeaker or acoustic transducer, that is electrically connected to processor <NUM> and memory <NUM> and configured to electromechanically convert an electrical signal into audible acoustic energy within the environment surrounding each device, e.g., an audio playback. In some examples, the electrical signal and the audible acoustic energy are associated with the data included in the plurality of wireless data streams (discussed below). Furthermore, and although not illustrated, circuitry <NUM> can include one or more clocks or time-keeping circuits configured to keep independent time during operation of system <NUM>. As one example, each device <NUM> can synchronize its own internal clock with the internal clock of source device <NUM> continuously or periodically such that all devices within system <NUM> can avoid drift between each independent clock and synchronize the receipt, transmission, and retransmission of packets <NUM> (discussed below). In other words, all devices within system <NUM> can share time information from their respective clocks and can synchronize each of their clocks to a single, shared, time domain such that the sending and receiving of the packets <NUM> discussed below, can be synchronized and drift between each device clock can be minimized and/or eliminated.

Each device of system <NUM>, i.e., each source device <NUM> and each device of plurality of devices <NUM> may use their respective communication modules to send and/or receive wireless data streams between and among each device, e.g., wireless data stream <NUM> and wireless retransmission data streams 148A-148C (discussed below). For example, source device <NUM> can be configured to generate, broadcast, or otherwise wirelessly transmit a wireless data stream <NUM>. Wireless data stream <NUM> can use various wireless data protocols or methods of transmission e.g., Bluetooth Protocols, Bluetooth Classic Protocols, Bluetooth Low-Energy Protocols, LE Audio protocols, Asynchronous Connection-Oriented logical transport (ACL) protocols, Radio Frequency (RF) communication protocols, WiFi protocols, Near-Field Magnetic Inductance (NFMI) communications, LE Asynchronous Connection (LE ACL) logical transport protocols, or any other method of transmission of wireless data suitable for sending and/or receiving audio and voice data streams. In one example, as will be discussed below in detail, wireless data stream <NUM> is an isochronous data stream, e.g., a broadcast isochronous stream.

As illustrated in <FIG>, wireless data stream <NUM> (hereinafter referred to as "data stream <NUM>" or "BIS stream <NUM>") transmits or broadcasts wireless data <NUM> within or during one or more of a plurality of broadcast isochronous stream intervals 124A-124B. As data stream <NUM> is an isochronous data stream, each broadcast isochronous stream interval has a fixed duration set by the device broadcasting data stream <NUM>. Thus, broadcast isochronous stream intervals 124A-124B cover time intervals of equal duration, where second broadcast isochronous stream interval 124B comes sequentially in time (illustrated by arrow T in <FIG>) after first broadcast isochronous stream interval 124A. Within each broadcast isochronous stream (BIS) interval, there are a plurality of subevents. For example, first BIS interval 124A can include subevents 126A-126B and second BIS interval 124B can includes subevents 126C-126D. It should be appreciated that more than two BIS intervals can be utilized, e.g., three, four, five, six, etc., and the quantity and duration of each subevent is dependent on the BIS intervals established by the broadcasting device. Each subevent corresponds to a time period within which one or more devices (e.g., source device <NUM> or devices <NUM>) can transmit or receive wireless data <NUM> via one or more data packets 128A-128D (collectively referred to as "data packets <NUM>" or referred to in the singular as "data packet <NUM>"). It should be appreciated that the term "subevent," in addition to its ordinary meaning to those skilled in the art, can also include events sent prior to sending the one or more data packets, e.g., the BIS stream can include pretransmission events or time windows as well as separate events or time windows for repeatedly sending or retransmitting the payload <NUM> (discussed below). As shown in <FIG> each data packet <NUM> includes a preamble <NUM>, an access address <NUM>, a header <NUM>, and a payload <NUM>. Preamble <NUM> is the first portion of the packet structure that is transmitted and can include data in the form of one or more bits (e.g., "<NUM>" or "<NUM>") in a pattern which signifies to a receiving device the start of a packet to be transferred/received. Access address <NUM> is the second portion of the packet structure that is transmitted and can include data in the form of one or more bits (in some examples <NUM> bits are used) to identify the data communication and associate the communication with one or more devices, e.g., the access address <NUM> can be specific to the device intended to receive the communication. Header <NUM> can include various fields related to the data packet, e.g., header <NUM> can include a field for the logical transport address (LT_ADDR), a field for packet type, a field for flow control (FLOW), a field for automatic repeat request number (ARQN), a field for sequence number (SEQN), and a field for header error check (HEC). Payload <NUM> includes the wireless data <NUM> to be transferred from one device to the other. For example, in some examples, payload <NUM> can include audio data <NUM> associated with one or more media files, e.g., media files stored on or sent from source device <NUM>. In some examples, audio data <NUM> can include data related to multiple channels of a multichannel audio signal, e.g., multiple channels related to each device in a <NUM>. surround sound system. Additionally, audio data <NUM> can include data related to a stereo audio signal <NUM> including a left channel signal <NUM> and a right channel signal <NUM> to be rendered by one or more devices <NUM>, for example, at a front-left speaker assembly (e.g., device 104A) and a front-right speaker (e.g., device 104C), respectively. In the event that the payloads <NUM> of the data packets <NUM> include audio data <NUM>, it should be appreciated that wireless data stream <NUM> and wireless retransmission data streams 148A-148C (discussed below) can utilize one or more LE audio protocols, as discussed above, and can also utilize the LC3 audio codec for compression of audio data <NUM> for transmission of the data. For example, the LC3 audio codec can be used in example embodiments where devices <NUM> are configured as a <NUM> surround sound system.

In operation, source device <NUM> is intended to broadcast or otherwise transmit a wireless data stream, e.g., BIS stream <NUM>, such that each device <NUM> can receive and use the wireless data <NUM> within the payloads <NUM> of data packets <NUM>, for example, to generate audible acoustic energy or sound. Ideally, each device <NUM> successfully receives the payloads <NUM>; however, various factors can lead one or more devices <NUM> to lose, drop, miss, or otherwise fail to receive one or more packets <NUM> of BIS stream <NUM>. As will be discussed below, in the situations where one or more data packets <NUM> are not successfully received by one or more devices <NUM> from the source device <NUM> in BIS stream <NUM>, one or more retransmission plans or retransmission schemes <NUM> may be employed, e.g., where one or more devices <NUM> that successfully received a particular data packet <NUM> is configured to produce, broadcast, or transmit a wireless retransmission data stream 148A-148C (discussed below) such that a device <NUM> that did not receive the packet from the BIS stream <NUM> can nevertheless receive it from the one or more of the wireless retransmission data streams 148A-148C.

The following description should be read in view of <FIG>. In these figures, schematic notation is used to illustrate sequential and simultaneous or overlapping events. As illustrated by rectangular boxes, each radio (e.g., each radio <NUM>) of each device <NUM>, is either configured or tuned to transmit data (denoted by Tx) or configured or tuned to receive data (denoted by Rx) with respect to each subevent. Thus, each rectangular box shown corresponds to a time window along time T within which a given device can transmit or receive a data packet <NUM>. It should be appreciated that time is represented schematically from left to right in the figures, e.g., two rectangular boxes horizontally adjacent to each other denote two time windows arranged sequentially, i.e., where the left-most window exists prior to the right-most window in time. It should therefore be appreciated that any rectangular boxes or other notation oriented vertically with respect to one another, are intended to be overlapping in time, for example, two boxes depicted vertically, i.e., one directly above the other, is intended to denote two time windows that occur simultaneously. Additionally, for clarity, it should be appreciated that data packets <NUM> will be denoted in numerical values signifying particular packets, duplicate packets, or retransmitted packets. For example, during first subevent 126A of first BIS interval 124A of BIS stream <NUM>, source device <NUM> is configured to transmit a packet <NUM> (denoting the first packet of the first BIS interval 124A) and during second subevent 126B of first BIS interval 124A of BIS stream <NUM>, source device <NUM> is configured to transmit packet <NUM> where packet <NUM> contains a payload <NUM> that is a copy or duplicate of the payload <NUM> of packet <NUM>. Thus the notation <NUM> refers to the first attempt to transmit a packet with the first payload and the notation <NUM> indicates the second attempt to send a packet with the first payload. As will be discussed below, any retransmitted packets (also referred to as "other data packets"), e.g., packets transmitted in retransmission wireless data streams 148A-148C (discussed below) carry a three digit notation, e.g., <NUM>. <NUM>, and <NUM>. The notation <NUM>. <NUM> indicates the first attempted retransmission of the first payload while <NUM>. <NUM> indicates a second or different attempt to retransmit the first payload.

<FIG> illustrates retransmission scheme <NUM> where retransmission scheme <NUM> is an unconditional retransmission scheme. As shown, system <NUM> can include a source device, e.g., source device <NUM> (illustrated schematically as a tablet) and a plurality of wireless devices, e.g., devices 104A-104C (depicted schematically as speakers). As shown, it should be appreciated that the present description is not limited to three devices, and can include N number of devices (shown by a vertical ellipsis and corresponding device 104N). As schematically set forth in <FIG>, source device <NUM> is configured to produce a BIS stream <NUM> which includes at least two subevents 126A-126B during a first BIS interval 124A and at least two subevents 126C-126D during a second BIS interval 124B. As illustrated, source device <NUM> makes two sequential attempts to transmit the first packet of wireless data <NUM> to all devices <NUM> over the first and second subevents 126A-126B (indicated by packets <NUM> and <NUM>). During the first time window (schematic rectangular box) corresponding with the transmission of packet <NUM> by source device <NUM>, the radios <NUM> of each device 104A-104N are configured or tuned to receive packet <NUM>. As illustrated in <FIG>, in some examples, one or more devices <NUM> can fail to successfully receive packet <NUM> during the first time window (denoted by "Rx <NUM>"). In this example, although devices 104A and 104B may successfully receive the first packet <NUM> (denoted as "Rx <NUM>"), device 104C may not successfully receive packet <NUM> from BIS stream <NUM> transmitted by source device <NUM> (denoted by "Failed Rx"). The failure to receive packet <NUM> can be caused by a number of factors, for example, excessive radio interference, excessive distance between device 104C and source device <NUM>, high signal-to-noise ratio at device 104C, one or more physical barriers between device 104C and source device <NUM>, etc. In this scenario, as depicted, system <NUM> can utilize an unconditional retransmission scheme <NUM>. In the unconditional retransmission scheme <NUM>, each device <NUM> that successfully receives packet <NUM> is configured to retransmit, via its own retransmission data stream <NUM>, a retransmitted packet (denoted by the second transmission windows "Tx <NUM>. <NUM>"-"Tx <NUM>. <NUM>"), where the retransmitted packet has an identical payload to packet <NUM> and/or packet <NUM>. For example, with reference to <FIG>, once system <NUM> and/or devices 104A-104B determine that they have successfully received packet <NUM>, devices 104A-104B retune or reconfigure their respective radios <NUM> to transmit and/or broadcast, via their own retransmission data stream, e.g., wireless retransmission data streams 148A-148B, respectively, during a retransmission interval <NUM>. Similarly to data stream <NUM> transmitted from source device <NUM>, each retransmission data stream 148A-148B is intended to be an isochronous data stream, e.g., a broadcast isochronous data stream. Due to the temporal overlapping between the retransmitted packets and the duplicate packets sent by source device <NUM>, it should be appreciated that, to avoid collisions and interference, BIS stream <NUM> and each retransmission data stream <NUM> can be transmitted using a unique frequency or a unique channel, e.g., one of the <NUM>, <NUM> wide channels provided for Bluetooth LE transmissions. For example, source device <NUM> can broadcast BIS stream <NUM> at a first transmission frequency F1 while device 104A can retransmit at a second transmission frequency F2 different than the first transmission frequency F1. Similarly, each successive device <NUM> can retransmit, when necessary using different transmission frequencies. Therefore, as devices 104A and 104B successfully received packet <NUM> during first subevent 126A, during second subevent 126B devices 104A and 104B are configured to retransmit a packet with an identical payload <NUM>, i.e., packet <NUM>. <NUM> and <NUM>. <NUM>, respectively, via separate broadcast isochronous streams (i.e., retransmission data streams 148A and 148B, respectively), at different frequencies, i.e., at second transmission frequency F2 and third transmission frequency F3, respectively, while device 104C simultaneously remains tuned to receive the duplicate packet <NUM> from source device <NUM> or one or more of the retransmitted packets, i.e., <NUM>. <NUM> or <NUM>. <NUM>, from devices 104A and 104B, respectively. In the unconditional retransmission scheme <NUM>, all devices are configured to retransmit a successfully received payload <NUM> regardless of whether any device 104A-104N has failed to receive a packet and thus the retransmission by each device is unconditional. It should be appreciated that although illustrated in <FIG> as overlapping with duplicate packet <NUM> from source device <NUM>, any retransmitted packets, e.g., <NUM>. <NUM> or <NUM>. <NUM> can be sent coincident with, overlapping with, or after any subevent <NUM> of the BIS stream <NUM>, should the transmission scheme allows for it.

One advantage to the unconditional retransmission scheme <NUM> described above is that one or more devices <NUM>, e.g., device 104C may be positioned far away from source device <NUM>, or positioned such that there is a large physical barrier between source device <NUM> and device 104C. In this scenario, it is likely that device 104C will not receive the first or the second attempted packet from source device <NUM>, e.g., packets <NUM> or <NUM>. Simultaneously, devices 104A and/or 104B may be positioned such that no such interference or obstruction exists between them and source device <NUM>, and no such interference or obstruction exists between devices 104A-104B and device 104C. By broadcasting a separate retransmission data stream <NUM> from one or more of the devices 104A-104B, there is a much higher likelihood that device 104C will successfully receive the intended payload from the other devices <NUM> rather than relying on duplicate transmissions from source device <NUM> alone. Thus, more robust broadcast schemes can be employed.

In one example, illustrated in <FIG> and <FIG>, the unconditional retransmission scheme <NUM> described above can be modified such that the second time windows of each retransmission data stream <NUM> are temporally offset or shifted with respect to the second time windows associated with the other retransmission data streams <NUM>. For example, rather than generating retransmission data streams 148A-148B using devices 104A and 104B in an overlapping time interval (as illustrated in <FIG>), a time offset <NUM> can be employed between all devices <NUM> such that the second time window for device 104B is shifted with respect to the second time window for device 104A, and the second time window for device 104C is shifted with respect to the second time window of device 104B, etc. Time offset <NUM> can be a predetermined time offset or a dynamic offset and can be selected from within the range of <NUM> - <NUM>, for example, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM>. By temporally shifting the reception windows of each device <NUM> with respect to each other, this allows the device that has failed to receive the payload <NUM> of packet <NUM> (e.g., device 104C) to be able to sequentially listen (tune for reception) for a duplicate packet from source device <NUM> (e.g., packet <NUM>), and sequentially listen for a retransmitted packet from each device <NUM> that produces a retransmission data stream <NUM> (e.g., retransmitted packets <NUM>. <NUM> and <NUM>. <NUM> from devices 104A and 104B, respectively) where the duplicate packets and the retransmitted packets do not completely overlap in time. By shifting each reception window, the device listening for a duplicate or retransmitted packet (e.g., device 104C) can listen first for the duplicate packet <NUM> sent from the source device <NUM> by tuning its radio to listen for the frequency or channel used by source device <NUM>. If device 104C (by failing to receive/read the preamble of duplicate packet <NUM>) determines that it will likely fail to receive duplicate packet <NUM>, device 104C can retune to listen in on a different frequency or channel corresponding with the next sequential opportunity, e.g., the time shifted retransmission of packet <NUM>. <NUM> by device 104A to attempt to receive the missing payload. Similarly, during the time shifted retransmission of packet <NUM>. <NUM> by device 104A, should device 104C determine (by e.g., failing to receive/read the preamble of retransmitted packet <NUM>. <NUM>) that it will likely fail to receive retransmitted packet <NUM>. <NUM>, device 104C can retune to listen in on a different frequency or channel corresponding with the next sequential opportunity, e.g., the time shifted retransmission of packet <NUM>. <NUM> by device 104B. By shifting the second time windows of each device, device 104C can maximize the chances of successfully receiving the missing payload by focusing on one particular duplicate packet or retransmission packet communication at a time and skipping to the next frequency or channel associated with the next opportunity for retransmission should device 104C determine that it is unlikely that it will receive the missing payload from a particular device <NUM>.

<FIG> illustrates a schematic view of the second time windows of the retransmission wireless data streams 148A and 148B with time offset <NUM>. As shown, the time offset <NUM> is large enough to allow device 104C (shown in <FIG>) to listen for and read/receive the preamble <NUM>, the access address <NUM> and/or potentially the header <NUM> prior to deciding to retune for a different opportunity, e.g., prior to listening for the retransmission from device 104B (e.g., packet <NUM>. <NUM> shown in <FIG>). Additionally, there may be an additional amount of time for processing (illustrated by arrow P). By utilizing the foregoing example retransmission scheme <NUM> in a <NUM> surround sound system, for example, where one device <NUM> fails to receive a packet but the other five devices successfully receive the packet, the device that failed to receive the packet originally will have six sequential opportunities to receive a duplicate or retransmission packet, e.g., one opportunity from source device <NUM>, and five sequential opportunities from the other devices <NUM> that successfully receive the packets during the first subevent 126A. In some examples, one or more algorithms <NUM> can be executed on one or more devices of system <NUM> to determine which devices <NUM> the device that missed the packet (e.g., device 104C) should listen in on to maximize its chances of receiving a duplicate or retransmitted packet. For example, the one or more algorithms <NUM> employed on device 104C can determine the highest average received signal strength indicated (RSSI) signal strength between device 104C and each retransmission data stream <NUM> and/or BIS stream <NUM>. In addition to or in the alternative to determining RSSI value for a given broadcast, the one or more algorithms <NUM> can track the number of missed packets for each device <NUM> to determine which devices <NUM> have the highest rate of successful receptions of the during each subevent. For example, the one or more algorithms <NUM> may determine that device 104C frequently misses receiving the first data packet <NUM> during first subevent 126A. As will be discussed below with respect to <FIG>, the combination of these two analyses can allow the system to establish device pairs, friend pairs, or a predetermined retransmission relationship between devices that routinely or frequently miss or drop packets and devices that routinely receive packets. This relationship can be enhanced by a given friend pair or device pair including at least one device that routinely receives packet <NUM>, for example, with a device that routinely misses packet <NUM> where there is a strong or high RSSI value between the two devices of the pair. Thus, the retransmission scheme <NUM> described above can be further enhanced by analysing the packet transmission information of each device and establishing friend pairs or device pairs to increase the efficiency of retransmission.

In one example, illustrated in <FIG>, the unconditional retransmission scheme <NUM> described above can further be modified such that each successive retransmission data stream <NUM> can include different specific payloads to allow for retransmission of payloads from multiple previous subevents to be retransmitted during a single retransmission interval <NUM>. For example, as shown in <FIG>, during retransmission interval <NUM> each device 104A-104C can retransmit, in its own retransmission data stream 148A-148C, respectively, a different specific retransmission packet during retransmission interval <NUM>. As shown, device 104A can retransmit packet <NUM>. <NUM>, device 104B can retransmit packet <NUM>. <NUM>, device 104C can retransmit packet <NUM>. This pattern can be extended to include every device 104A-104N illustrated by retransmitted packet <NUM>. <NUM> associated with device 104N. This differentiated unconditional retransmission scheme <NUM> can also carry over to the next BIS interval, i.e., second BIS interval 124B where each device 104A-104N can continue to retransmit different, specific, packets during their respective retransmissions. The differentiate packet retransmissions of each retransmission data stream <NUM> can be based on data obtained prior to runtime of the system <NUM>, e.g., it may be known that devices 104A and 104B are arranged close to source device <NUM> and therefore retransmission data streams 148A and 148B can consistently provide retransmitted packets for other devices within system <NUM> rather than the same retransmitted packets. Alternatively, this analysis could occur dynamically, i.e., during runtime of system <NUM> based on packet receive/loss rates or RSSI value as discussed above.

In addition to the low complexity operation discussed above, further advantages of the unconditional retransmission scheme <NUM> include that the transmission order of each device <NUM> can be pre-programmed, i.e., arranged prior to runtime. Also, the foregoing systems and retransmission scheme <NUM> will function equally well if one or more devices are missing, disconnect, or lose power. The additional advantages afforded by the differentiated unconditional retransmission schemes describe above include the additional control of selective reception of which packets are in need of retransmission. Additionally, the system is less sensitive to bursts of periodic noise as the retransmissions are available over a longer total period of time. Moreover, the increased control of which packets are retransmitted allows for selective reception of different packets or packet fragments that may complete or fill in gaps in fragmented or incomplete audio frames.

In addition to the implementations of the unconditional retransmission schemes <NUM> discussed above, one extension of these concepts allows a device <NUM> that routinely fails to receive packets during subevents 126A-126B, for example, to sacrifice its own ability to receive the next packet from source device <NUM> during a second BIS interval in favor of receiving a retransmission of the previous packet during the second BIS interval. For example, as illustrated in <FIG>, should the free air time between the end of the first BIS interval 124A and the beginning of second BIS interval 124B be small, e.g., smaller than a retransmission time window, device 104A (which successfully received either first packet <NUM> or the duplicate of first packet <NUM> (as shown) can decide to retransmit the packet (as packet <NUM>. <NUM>) during and overlapping with the subevent 126C of the second BIS interval 124B. Thus, should device 104B recognize that its connection with source device <NUM> is poor or unreliable, device 104B can decide to prioritize receipt of a retransmission from a more reliable device, i.e., device 104A, and sacrifice its ability to receive packet <NUM> from source device <NUM> in the next subevent.

In the alternative to (or in addition to) the unconditional retransmission schemes discussed above, retransmission scheme <NUM> can be conditional, e.g., where each particular device <NUM> is configured to generate or transmit a retransmission data stream <NUM> only when one or more devices <NUM> have failed to acknowledge receipt of a packet from source device <NUM>, i.e., from BIS stream <NUM>. As shown in <FIG>, each device 104A-104N is configured to acknowledge, via an acknowledgement <NUM>, that it has successfully received the packet <NUM> and/or the payload <NUM> for each packet transmitted in BIS stream <NUM> from source device <NUM>. Acknowledgements <NUM> can take the form of a separate packet of data or a burst of energy, e.g., a burst of radio waves that can be received by the other devices of system <NUM>. If one or more devices 104A-104N fails to acknowledge receipt of the first payload (either from packet <NUM> or duplicate <NUM>) or provides an acknowledgement <NUM> that indicates that it failed to successfully receive the first payload, then any device that successfully received the first payload during first BIS interval 124B and receives the second payload from the next subevent 126C of second BIS interval 124B will retransmit the missing packet via a retransmission data stream <NUM>. For example, as illustrated in <FIG>, devices 104A and 104B successfully receive the first payload during the first subevent 126A shown by acknowledgements <NUM>. However, device 104C can fail to acknowledge receipt of packets <NUM> and <NUM> during the first and second subevents 126A-126B or acknowledge the failure to receive packets <NUM> and <NUM> (shown as a rectangular box with cross-hatchings in <FIG>). By providing this acknowledgement <NUM> that device 104C is missing the first payload, devices 104A and 104B will know that device 104C is missing a payload that they had previously received. Either or both of devices 104A and 104B that successfully receive the second payload from packet <NUM> during subevent 126C of second BIS interval 124B can then utilize their second time window (corresponding to subevent 126D) to provide a retransmission data stream 148A to broadcast the first payload in an attempt to allow device 104C to receive the first payload during the second BIS interval 124B. As shown in <FIG> only device 104B successfully receives packet <NUM> and packet <NUM> during the first BIS interval 124B and during subevent 126C, respectively. Thus, during subevent 126D, only device 104B will provide a retransmission data stream, i.e., retransmission data stream 148B which will include retransmission packet <NUM>. It should be appreciated that, although failing to receive packets from BIS stream <NUM>, device 104C can listen for acknowledgements from the other devices <NUM> and tune its radio <NUM> to the frequency or channel that the retransmitting device utilizes, for example, to the frequency or channel that device 104B uses to retransmit. Additionally, although able to receive packet <NUM> during subevent 126A, there is no guarantee that device 104A will receive the second payload/second packet <NUM> (or duplicate <NUM>). As shown, device 104A can miss, drop, or lose the second packets and provide an acknowledgement <NUM> informing the other devices <NUM> that it failed to receive the second packet in subevents 126C and 126D. Thus, during the next BIS interval (not shown) a device that successfully received the second payload and successfully receives the third payload during the first subevent of the next BIS interval can retransmit the missing packet.

It should be appreciated that the conditional retransmission scheme discussed and illustrated herein can also benefit from the differentiated retransmission and/or sacrifice retransmission modifications discussed above with respect to the unconditional retransmission scheme described and illustrated with respect to <FIG>. For example, with respect to <FIG>, during second BIS interval 124B the retransmitted packets shown, e.g., packet <NUM>. <NUM> retransmitted by device 104B and retransmitted packet <NUM>. <NUM> could take the form of different packets rather than as retransmitted copies of the same payload. Similarly, one or more devices <NUM> could sacrifice their ability to receive the next packet during the next subevent in favor of receiving a retransmitted packet by one or more of the other devices <NUM> as discussed above. Additionally, the one or more algorithms <NUM> may determine that a particular device <NUM> frequently misses packets from BIS stream <NUM> while a different device <NUM> routinely receives packets from BIS stream <NUM>. The one or more algorithms <NUM> can establish device pairs or friend pairs between these devices, e.g., to inform the sacrifice retransmission modifications discussed above.

As illustrated in <FIG> and <FIG>, in the conditional retransmission schemes discussed herein, a device that fails to receive a packet can call for help or send a help request <NUM> to the other devices <NUM> (or source device <NUM>) of system <NUM> such that those devices can provide the missing packet during the next retransmission event. As shown in <FIG>, device 104A-104C can be configured to acknowledge, via one or more acknowledgments <NUM>, that they successfully received a particular sent packet or whether they failed to receive a particular sent packet. Rather than waiting until after the second subevent 126B to send the acknowledgment during the free air time illustrated, devices 104A-104C may successfully receive the first packet/payload during the first subevent 126A. Thus, acknowledgements <NUM> can be sent during second subevent 126B. As shown, should any device <NUM> determine that it has failed to receive packet <NUM>, and can determine that it will likely not receive the duplicate packet <NUM> (by recognizing that it failed to receive the preamble of packet <NUM>), that device can send an acknowledgement <NUM> that includes a request for help <NUM>, i.e., a request indicating that a particular device failed to receive the first packet during the first subevent 126A and second subevent 126B. Upon receiving such a request, any device that successfully received packet <NUM> during the first subevent 126A can begin retransmitting during or proximate to the second subevent 126B. As illustrated in <FIG>, during the first subevent 126A, at least devices 104A and 104B successfully receive packet <NUM> (denoted by "Rx <NUM>"), while device 104C fails to receive packet <NUM> and knows that it will fail to receive packet <NUM> (due to failure to read or receive the preamble <NUM> of duplicate packet <NUM>). During the second subevent 126B, device 104A can acknowledge, via an acknowledgment <NUM>, that it successfully received packet <NUM> during first subevent 126A, while device 104C can acknowledge, via an acknowledgement <NUM>, that it failed to receive packet <NUM> during the first subevent 126A and will fail to receive duplicate packet <NUM> during second subevent 126B. As shown schematically, device 104B, that successfully received packet <NUM> during subevent 126A, can listen for requests <NUM> for help (shown schematically by a box denoted with "Help") from any devices <NUM> that signal that they failed to receive packet <NUM>. During that help time window, device 104B will recognize that device 104C failed to receive packets <NUM> and <NUM>. Thus, during subevent 126B, and after the help time window ends, device 104B can immediately begin retransmitting a retransmission packet (denoted as <NUM>. <NUM>) so that device 104C, that called for help, can have a new opportunity to receive the first payload. Devices <NUM> that have previously been paired, i.e., as device pairs or friend pairs, can listen for requests or calls for help from their paired device.

As shown in <FIG>, one of more devices <NUM> can communicate with source device <NUM> via a separate connection or broadcast that is outside of the normal Bluetooth band used for the broadcast isochronous streams discussed herein. For example, device 104A can be a soundbar or other device <NUM> that is configured to receive one or more packets <NUM> via a separate connection, e.g., a direct cable connection such as an HDMI cable connection or via a wired or wireless communication that is outside of the Bluetooth broadcast band such as Wi-Fi. As device 104A can received packets <NUM> from source device <NUM> via this direct wired transmission, device 104A can receive packets <NUM> with a high reliability. Thus, during operation, device 104A can listen for requests <NUM> for help from the other devices <NUM>, e.g., devices 104B-104N. As shown in <FIG>, if device 104D provides an acknowledgement <NUM> that includes a request for help <NUM> during the second subevent 126B that indicates device 104D failed to receive packet <NUM> and has failed to read the preamble <NUM> of duplicate packet <NUM>, then both device 104A and device 104C can listen for the help request (denoted by rectangular boxes labelled "Help")and retransmit the payload from the missing packet in a retransmission event. For example, should all devices except device 104D acknowledge receipt of packet <NUM> during first subevent <NUM>, then devices 104A and 104C can begin retransmission of a retransmission packet having the missing payload in the regular Bluetooth broadcast band or channel used for the broadcast isochronous streams discussed herein, such that device 104D can receive a retransmission packet from either device 104A (denoted as <NUM>. <NUM>) or device 104C (denoted as <NUM>. <NUM>) during the second subevent 126B.

For the conditional retransmission schemes discussed above, retransmission scheme <NUM> can utilize a block acknowledgements <NUM> to share retransmission data and/or retransmission plans between the devices of system <NUM>. For example, as shown in <FIG>, in examples where acknowledgement <NUM> is a packet rather than a burst of radio energy, the structure of the acknowledgement packet can take the form of a block acknowledgement <NUM>. In the structure illustrated, payload <NUM> can be a bitfield where each bit represents reception of a specific packet and whether it was successfully received or whether the packet reception failed. As illustrated in <FIG>, payload <NUM> can include a header 134A with device specific information such as rankings or device order (e.g., the order of delayed transmissions discussed above), as well as separate portions of the bitfield dedicated to indicating successful receipt or failure to receive each packet since the beginning of the stream, or for a predetermined number of previous packet attempts. <FIG> illustrates that N number of packets may have been sent since the beginning of a particular stream, e.g., BIS stream <NUM>. The first field (farthest to the right in <FIG> denoted as "PKTn") is devoted to recording whether packet N (the latest packet in time) was received or not. Moving to the left of the first field, the second field (denoted as "PKTn-<NUM>") is devoted to recording whether the packet broadcast immediately prior to packet N was received, i.e., packet N-<NUM>. To the left of the second field is the third field (denoted as "PKTn-<NUM>") which is devoted to recording whether the packet b broadcast immediately prior to packet N-<NUM> was received, i.e., packet N-<NUM>. This pattern can continue through N-X number of packets, where N-X represents the total number of packets sent in BIS stream <NUM> and/or a predetermined number of packets. It should be appreciated that the structure of the block acknowledgement <NUM> may include and track reception of packets by one or more of the devices <NUM> of system <NUM>. For example, each block acknowledgment <NUM> can include within its bitfield a history of packet failures and successful receipts of all packets for each device <NUM> of the system.

<FIG> illustrates a retransmission plan, e.g., retransmission plan <NUM>, that incorporates the block acknowledgements <NUM> for each device <NUM> as well as the order and content of retransmissions needed. As shown, one or more device <NUM> could share within a given retransmission or within a given acknowledgement <NUM>, the block acknowledgement information of one or more device <NUM>. Should it be determined from the block acknowledgment <NUM> that, for example, one or more device missed or failed to receive the first and second payloads (e.g., the payloads associated with packets <NUM> and <NUM>), the retransmission plan can include instructions to all devices <NUM> that a retransmission packet is needed for the first payload and the second payload. Retransmission plan <NUM> may include the order of retransmission of these payloads and/or which device or devices <NUM> will be responsible for the retransmission of a given packet/payload. As illustrated in <FIG>, it can be determined from block acknowledgement <NUM> that one or more devices <NUM> within system <NUM> is missing the first and second payload, and retransmission plan <NUM> can include that the second payload (denoted by the box with a "<NUM>") will be sent prior to the retransmission of the first payload (denoted by the box with a "<NUM>"). It should be appreciated that when sending acknowledgements <NUM> and generating block acknowledgement <NUM>, each device can layer or add on data related to their previous acknowledgements and failed/received packets to generate the cumulative block acknowledgment data discussed above.

In one example, the cumulative sharing of the data associated with block acknowledgement <NUM> or the data associated with retransmission plan <NUM> can be optimally distributed among the devices <NUM> of system <NUM> such that total sharing air time is minimized. Since each device can receive the block acknowledgement data from another device <NUM> within system <NUM> and layer or add on to the data from the previous device <NUM>, the air time needed to share all information with all devices can be minimized. As illustrated in <FIG>, six devices 104A-104F can be provided. Here, in a first operation, device 104A shares its acknowledgement and retransmission plans <NUM> with device 104C and device 104C shares the acknowledgement and retransmission plans <NUM> for devices 104A and 104C with device 104E (illustrated by dotted lines in <FIG>). Simultaneously, device 104B shares its acknowledgement and retransmission plans <NUM> with device 104D and device 104D shares the acknowledgement and retransmission plans <NUM> for devices 104B and 104D with device 104F (also illustrated by dotted lines in <FIG>). By the end of the first operation device 104E is responsible for a single cumulative acknowledgement and retransmission plan <NUM> for devices 104A, 104C, and 104E (as they have all been layered on top of each other). Similarly, by the end of the first operation, device 104F is responsible for a single cumulative acknowledgement and retransmission plan <NUM> for devices 104B, 104D, and 104F. In the next operation (illustrated by solid grey lines in <FIG>), device 104E shares the cumulative acknowledgement and retransmission plan <NUM> for devices 104A, 104C, and 104E with devices 104B, 104D, and 104F. Additionally, during a third operation (illustrated by solid black lines in <FIG>) device 104F shares the cumulative acknowledgement and retransmission plan <NUM> for devices 104B, 104D, and 104F with devices 104A, 104C, and 104E. Thus, by the end of the third operation all devices 104E and 104F are aware of the retransmission plans for the entire collection of devices 104A-104F. It should be appreciated that the layering plan sharing schemes discussed above can utilize a circular retransmission order, e.g., where each device layers onto the previous device plan before saring to the next until the last device is responsible for a single cumulative plan, or could use a tree pattern where only certain devices are responsible for cumulative plans for certain other devices.

In some examples, the retransmission schemes <NUM> discussed above, can be utilized to send stereo audio data <NUM> to a pair of wireless headphones, e.g., truly wireless earbuds. For example as illustrated in <FIG>, source device <NUM> can be a tablet or smartphone, while device 104A can be a wireless charging case configured to matingly engage with and charge devices 104B and 104C (not shown) which can be the right and left earbuds of a pair of truly wireless earbuds associated with the charging case 104A. Here, source device <NUM> is configured to broadcast, e.g., via BIS stream <NUM>, audio data <NUM> associated with stereo audio signals, i.e. a left channel stereo signal <NUM> and a right channel stereo signal <NUM> (denoted by L and R in <FIG>. Similarly to the notation above, the left and right stereo signal packets are sent sequent and thus L <NUM> denotes the first attempt to send the first left-channel-specific payload while R <NUM> denotes the first attempt to send the first right-channel-specific payload. Thus, as illustrated, source device <NUM> is configured to broadcast via BIS stream <NUM>, eight sequential attempts (four for the left and four for the right channel audio) at sending the first payload, i.e., through packets L <NUM>-L <NUM> and R <NUM>-R <NUM>. This would give the stereo pair of truly wireless headphones, e.g., devices 104B and 104C (not shown), four opportunities to receive the first payload for each headphone. To increase the robustness of this configuration, the charging case, shown as first device 104A can listen for the first left-channel-specific payload and the first right-channel-specific payload and act as an unconditional retransmitter for both payloads. As shown, during the first two subevents (where source device <NUM> transmits packets L <NUM> and R <NUM>) case device 104A can listen for and receive the first and second stereo payloads associated with the left and right channel stereo signals. Then, unconditionally, during subsequent subevents, case 104A can provide (in an alternating pattern) duplicate copies of packets L <NUM> and R <NUM> in overlapping events, i.e., overlapping in time, with respect to the duplicate transmissions of source device <NUM>. In some examples, the overlapping events of the case 104A can transmit the opposite payload than the source device <NUM> is transmitting during the same subevent. For example, as shown in <FIG>, the first retransmission from case 104A overlaps in time with the first duplicate transmission from source device <NUM>; however, the first duplicate transmission from source <NUM> is a left-channel-specific payload (i.e., packet L <NUM>) while the first retransmission from case <NUM> is a right-channel-specific payload (i.e., packet R <NUM>). This overlapping allows both earbuds to tune their respective radios <NUM> to listen for duplicate packets during overlapping time intervals. In some examples, this allows case 104A to retransmit even when source device <NUM> is not transmitting or experiences some transmission error. As shown, source device <NUM> may experience a failure to transmit duplicate packets L <NUM> and R <NUM> (shown by grey boxes in <FIG>). In this example, since case 104A is sending retransmitted duplicate packets for the left and right channels in overlapping events, this example affords the left and right headphones an additional opportunity to receive a dropped packet from case 104A rather than source device <NUM>. It should also be appreciated that in the example described above, where devices <NUM> include a truly wireless headphones and a case configured to matingly engage with and charge the headphones, the retransmission by case 104A can utilize a broadcast isochronous stream or a connected isochronous stream that had previously been established between each headphone and the case.

It should be appreciated that system <NUM>, can utilize the foregoing unconditional retransmission schemes (illustrated and described with respect to <FIG>) and the foregoing condition retransmission schemes (illustrated and described with respect to at least <FIG>), to adaptively switch to the retransmission scheme that maximizes the system's efficiency. For example, system <NUM> can begin utilizing the condition retransmissions schemes discussed above. In the event that a significant number of devices <NUM> are dropping, missing, or otherwise failing to successfully receive packets, system <NUM> may adaptively revert, fallback, or switch from a conditional retransmission scheme to the unconditional retransmission schemes discussed herein, such that any device that successfully receives a given packet or given payload unconditionally retransmits that payload to any device that still needs it.

<FIG> illustrates a flow chart corresponding to method <NUM> according to the present disclosure. As shown, method <NUM> is read from the perspective of device 104A. As such, method <NUM> can include, for example: receiving, at a first device 104A, the payload <NUM> of a first data packet <NUM> sent from a source device <NUM> via a broadcast isochronous stream <NUM> (Step <NUM>); transmitting the payload <NUM> from the first device 104A to a second device (104B,104C), via a data stream (148A)(Step <NUM>); and listening for a retransmitted data packet (e.g., packet <NUM>. <NUM>) over a second transmission frequency F2 different than the first transmission frequency F1 related to the payload <NUM> received by the first device 104A. In some implementations, the clock used for sending retransmission from the first device 104A is synchronized to the clock of the source device <NUM> to ensure that the retransmissions do not drift into the stream from the source device <NUM> (such as the stream from the source device <NUM> to a second device (e.g., 104B)).

<FIG> illustrates a flow chart corresponding to method <NUM> according to the present disclosure. As shown, Method is read from the perspective of device 104C. As such, method <NUM> can include, for example: receiving at a first device 104A a first data packet <NUM> of a broadcast isochronous stream <NUM> from a source device <NUM>, the first data packet <NUM> having a payload <NUM> (Step <NUM>); listening for, at a second device 104C, the first data packet <NUM> of the broadcast isochronous stream <NUM> from the source device <NUM> (Step <NUM>); and listening for, at the second device 104C, a retransmitted data packet (e.g., packet <NUM>. <NUM>) from the first device 104A sent via a data stream 148A, after not receiving the first data packet <NUM> from the source device <NUM>, the retransmitted data packet having the payload (Step <NUM>). In some examples, listening for the retransmitted data packet includes listening over a second transmission frequency F2 different than the first transmission frequency F1 related to the payload <NUM> received by the first device 104A.

As can be understood based on this disclosure, the techniques described herein can be used to extend the transmission range of broadcast isochronous streams used by, e.g., LE Audio (Bluetooth <NUM> and higher). For instance, in some implementations, a first device (e.g., first device 104A) within the transmission range of a source device (e.g., source device <NUM>) transmitting the broadcast isochronous stream is configured to receive the broadcast isochronous stream and retransmit it to a second device (e.g., second device 104B) that is outside the transmission range of the source device. In some such implementations, the first and second devices may be audio devices configured to output audio via one or more speakers based on the broadcast isochronous stream. In such implementation, audio playback at the first device may be controlled and/or delayed to ensure audio synchronization at, where such controlling and/or delaying of playback of the audio data could be included in the original broadcast isochronous stream (e.g., such that the source device is controlling/delaying the playback) or it could be later appended to the stream data (e.g., provided by the first device when retransmitting the stream, such that the first device is controlling/delaying the playback). However, in other implementations, the first and/or second device need not include capabilities of outputting audio from the broadcast isochronous stream, as they may merely be devices that retransmit the stream and/or use the data in some other manner (e.g., interpreting the broadcast isochronous stream to provide visual outputs of the stream, such as to provide audio data to text data transcription of speech in the stream). Further, once the second device receives the retransmitted broadcast isochronous stream from the first audio device, it could again retransmit the broadcast isochronous stream, and so forth. Thus, the techniques variously described herein can be used to establish an LE Audio broadcast mesh network, whether or not devices receiving retransmitted data packets are within the transmission range of the original source device. In other words, the techniques described herein can be applied whether the device receiving retransmitted data packets (e.g., the second device of <FIG> and <FIG>) is within the transmission range of the source device (i.e., the device providing the original broadcast isochronous stream) or whether the device receiving retransmitted data packets is outside the transmission range of the source device.

The above-described examples of the described subject matter can be implemented in any of numerous ways. For example, some aspects may be implemented using hardware, software or a combination thereof. When any aspect is implemented at least in part in software, the software code can be executed on any suitable processor or collection of processors, whether provided in a single device or computer or distributed among multiple devices/computers.

The present disclosure may be implemented as a system, a method, and/or a computer program product at any possible technical detail level of integration.

Computer readable program instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages. In some examples, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to examples of the disclosure.

The computer readable program instructions may be provided to a processor of a, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various examples of the present disclosure.

Claim 1:
A method (<NUM>) of retransmitting a payload of a data packet in a system (<NUM>) including a source device (<NUM>) and a plurality of devices (<NUM>), each of the plurality of devices being capable of receiving wireless data broadcasted from the source device, using a wireless data protocol, the method comprising:
listening, at a first device (104A) of the plurality of devices and at a second device (104C) of the plurality of devices, for a data packet from the source device (<NUM>) via a broadcast isochronous stream (<NUM>);
receiving (<NUM>), at the first device (104A), a payload (<NUM>) of the data packet (<NUM>) broadcasted from the source device via the broadcast isochronous stream (<NUM>); and
after not receiving the data packet from the source device at the second device, transmitting (<NUM>) the payload from the first device to the second device (104C) of the plurality of devices, wherein the transmitting of the payload from the first device to the second device uses a different frequency or channel relative to a frequency or channel used for receiving the payload from the source device.