Robust retransmission topology using error correction

Abstract

Methods and systems for improving robustness of wireless communications. The provided methods and systems transmit data packets over one or more synchronization streams, and one or more supplemental data packets over the same time interval. The one or more supplemental data packets are used to reconstruct and / or enhance at least a portion of one or more of the plurality of data packets that have been transmitted. Alternatively, the one or more supplemental data packets are used to create and / or enhance at least a portion of one or more of the plurality of data packets to be received during a next synchronization interval. The methods and systems described herein enable increased robustness by allowing better retransmission of correctly received packets.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. non-provisional patent application No. 18 / 184,417, filed March 15, 2023, entitled "Robust Retransmission Topologies Using Error Correction," which is a continuation-in-part of U.S. non-provisional patent application No. 17 / 366,613, filed July 2, 2021, entitled "Robust Retransmission Topologies Using Error Correction," the entire disclosure of which is incorporated herein by reference. Background Technology

[0003] Various aspects and specific embodiments of this disclosure generally relate to systems and methods for transmitting and receiving wireless data streams (e.g., transmitting and receiving wireless data streams between wireless devices).

[0004] Wireless systems, such as wireless multi-speaker systems, wireless headphones or headsets, or any system including broadcasting and receiving devices, typically transmit and receive streams of data packets within a wireless connection between the devices in the system. Wireless devices may experience losses in the wireless connection, such as packet loss, failed transmissions, and failed retransmissions, when the connection is at the edge of its link budget or in the presence of interference. For example, if the wireless devices in a system move away from each other, increasing the distance between the source and sink devices, there will be moments when the distance between the devices will lead to increased packet loss. Similarly, in situations where the devices in a system suffer from other forms of environmental interference, such as the presence of multiple other wireless communications nearby or objects between the devices that may reduce signal strength (e.g., a user's body or a wall), the link budget will be strained and will eventually experience quality degradation. Summary of the Invention

[0005] The present disclosure provides methods and systems for improving the robustness of wireless communications. The methods and systems provided transmit data packets on a first synchronization stream and one or more supplemental data packets on the same time interval. The one or more supplemental data packets are used to reconstruct and / or enhance at least a portion of one or more of the plurality of data packets that have been transmitted. Alternatively, the one or more supplemental data packets are used to create and / or enhance at least a portion of one or more of the plurality of data packets that will be received during the next synchronization interval. The methods and systems described herein achieve increased robustness by allowing better retransmission of correctly received packets.

[0006] The present disclosure includes broadcasting audio data on a first synchronization stream while also broadcasting a separate data stream that includes error correction codes for the audio stream. The configurations described herein allow each sink device to utilize correctly received packets from the audio stream in conjunction with the error correction codes to calculate missing audio data. Alternatively, the separate data stream can include additional audio data to enhance the quality of the data that has been received. For example, a sink device can utilize a correctly received packet or at least a portion of a correctly received packet (e.g., one or more frames of audio data) to calculate a missing portion of a packet or an entire missing packet.

[0007] The present systems and methods can utilize hard or soft block codes and can calculate error correction codes based on separate left and right channel audio streams or multi-channel audio streams. Further, the error correction codes can be transmitted prior to transmission of one or more packets used to calculate a given error correction code packet or can be transmitted just after transmission of any such packets (e.g., pre- or post-transmission). Additionally, the concepts described herein can be extended to non-broadcast scenarios, such as when utilizing a connected synchronization stream.

[0008] Generally, in one aspect, a source device is provided. The source device includes at least one processor configured to execute instructions configured to transmit, to at least one sink device, at least one data packet transmitted using a first frequency at a first time using a synchronization stream group including one or more synchronization streams.

[0009] The source device is further configured to transmit, via the synchronization stream group, one or more supplemental data packets. The one or more supplemental data packets to the at least one sink device are time-shifted relative to the at least one data packet and / or at a second frequency different from the first frequency. The one or more supplemental data packets are used to reconstruct and / or enhance at least a portion of the at least one data packet.

[0010] According to an example, the at least one data packet is created, reconstructed, and / or enhanced according to error correction encoding supplemental data provided by the source device to the sink device.

[0011] According to an example, the one or more supplemental data packets are error correction coded packets comprising the error correction coded supplemental data.

[0012] According to an example, each data packet of the at least one data packet comprises a header. The header comprises error correction code information and / or packet identification information.

[0013] According to an example, each supplemental data packet of the one or more supplemental data packets comprises a header, wherein the header comprises error correction code information and / or packet identification information.

[0014] According to an example, the error correction coded supplemental data is related to a first data packet transmitted within a first synchronization interval of the one or more synchronization intervals and a second data packet transmitted during a second synchronization interval of the one or more synchronization intervals.

[0015] According to an example, the error correction coded supplemental data is related to a first supplemental data packet transmitted within a first synchronization interval of the one or more synchronization intervals and a second supplemental data packet transmitted during a second synchronization interval of the one or more synchronization intervals.

[0016] According to an example, the error correction code is related to a first data packet transmitted within a first synchronization interval of the one or more synchronization intervals and a second supplemental data packet transmitted during a second synchronization interval of the one or more synchronization intervals.

[0017] According to an example, each data packet of the at least one data packet comprises one or more audio frames of encoded audio data. The one or more supplemental data packets are used to reconstruct at least one of the one or more audio frames.

[0018] According to an example, the at least one data packet is usable, when received by the sink device, to create a portion of audio to be played by the sink device.

[0019] According to an example, one of the one or more synchronization streams of the synchronization stream is a broadcast synchronization stream or a connected synchronization stream.

[0020] According to an example, the one of the one or more synchronization streams is a connected synchronization stream. Further to this example, the source device is further configured to confirm successful recovery of one or more of the at least one data packet based on the one or more supplemental data packets.

[0021] Generally, in another aspect, a method for improving wireless communication is provided. The method includes transmitting at least one data packet sent at a first time using a first frequency using a set of synchronization streams comprising one or more synchronization streams.

[0022] The method further includes transmitting one or more supplemental data packets via the synchronization stream group, the one or more supplemental data packets being time-shifted relative to the at least one data packet and / or at a second frequency different from the first frequency. The one or more supplemental data packets are used to reconstruct and / or enhance at least a portion of the at least one data packet.

[0023] According to an example, the at least one data packet is created, reconstructed, and / or enhanced from error correction encoded supplemental or enhancement data.

[0024] According to an example, the method further includes the one or more supplemental data packets including the error correction encoded supplemental or enhancement data.

[0025] According to an example, each data packet of the at least one data packet includes a header, wherein the header includes supplemental data type information and / or packet identification information.

[0026] According to an example, wherein each supplemental data packet of the one or more supplemental data packets includes a header, wherein the header includes supplemental data type information and / or packet identification information.

[0027] According to an example, the at least one data packet, when received by an audio device, is usable to create a portion of audio to be played by the audio device.

[0028] According to an example, one synchronization stream of the one or more synchronization streams is a broadcast synchronization stream or a connected synchronization stream.

[0029] According to an example, the one synchronization stream of the one or more synchronization streams is a connected synchronization stream. Further to this example, the method further includes confirming successful recovery of the at least one data packet based on the one or more supplemental data packets.

[0030] These and other aspects of various embodiments will become apparent from the embodiments described herein below, and will be supported by the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0031] In the drawings, like reference numerals refer to same parts throughout different views. Also, the drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of various embodiments.

[0032] Figure 1 is a schematic diagram of a system according to the present disclosure.

[0033] Figure 2 is a schematic diagram of components of a source device according to the present disclosure.

[0034] Figure 3is a schematic diagram of components of a sink device according to the present disclosure.

[0035] Figure 4A is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0036] Figure 4B is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0037] Figure 5 is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0038] Figure 6 is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0039] Figure 7 is a schematic illustration of a logical stack including schematic interfaces according to the present disclosure.

[0040] Figure 8 illustrates steps of a method according to the present disclosure.

[0041] Figure 9A is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0042] Figure 9B is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0043] Figure 10 is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0044] Figure 11A is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0045] Figure 11B is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0046] Figure 12 is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0047] Figure 13 is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0048] Figure 14 is a schematic illustration of a wireless broadcast topology according to the present disclosure.

[0049] Figure 15 illustrates steps of a method according to the present disclosure. DETAILED DESCRIPTION

[0050] The present disclosure provides methods and systems for improving the robustness of wireless communications. The methods and systems provided transmit data packets on a first synchronization stream and one or more supplemental data packets on the same time interval. The one or more supplemental data packets are used to reconstruct and / or enhance at least a portion of one or more of the plurality of data packets that have already been transmitted. Alternatively, the one or more supplemental data packets are used to create and / or enhance at least a portion of one or more of the plurality of data packets that will be received during the next synchronization interval. The methods and systems described herein allow for increased robustness by allowing for better retransmission of correctly received packets, and the methods set forth herein work with any Bluetooth broadcaster host without modification.

[0051] The term "wearable audio device" as used in this disclosure, in addition to including its ordinary meaning or meanings known to those skilled in the art, is intended to mean a device that fits around, on, in, or near an ear, including an open-ear audio device that is worn on a user's head or shoulders, and that radiates acoustic energy into or toward an ear. Wearable audio devices are sometimes referred to as headphones, earpieces, earphones, earbuds, earphones, or sports earphones, and can be wired or wireless. Wearable audio devices include an acoustic driver for converting audio signals into acoustic energy. The acoustic driver can be housed in an ear cup. While some of the following figures and descriptions can show a single wearable audio device with a pair of ear cups, each including an acoustic driver, it should be understood that a wearable audio device can be a single independent unit with only one ear cup. Each ear cup of a wearable audio device can be mechanically connected to the other ear cup or earphone, for example, by a headband and / or by leads that conduct audio signals to the acoustic drivers in the ear cups or earphones. Wearable audio devices can include components for wirelessly receiving audio signals. Wearable audio devices can include components of an active noise reduction (ANR) system. Wearable audio devices can also include other functionality, such as microphones, so that the wearable device can be used as a headset. While Figure 1 Examples of in-ear earphone form factors, eyeglass form factors, and over-ear headphones are shown, but in other examples, the wearable audio device can be an on-ear, around-ear, behind-the-ear, or near-ear earphone. In some examples, the wearable audio device can be an open-ear device that includes an acoustic driver to radiate acoustic energy toward an ear while leaving the ear open to its outer and surrounding environment.

[0052] The term "connection synchronized stream", as used herein, is intended to mean, in addition to its ordinary meaning or meanings known to those skilled in the art, a synchronized data stream that utilizes a pre-established point-to-point communication link over LE Audio between, for example, a source device (which can also be referred to as a central device or master device) and an audio device or multiple audio devices (which can also be referred to as peripheral devices or slave devices). In other words, a connection synchronized stream can provide a synchronized audio stream between the source device and any respective audio device utilizing at least one established reliable communication channel and / or at least one acknowledged communication channel.

[0053] The term "broadcast synchronized stream", as used herein, is intended to mean, in addition to its ordinary meaning or meanings known to those skilled in the art, a synchronized data stream that does not require a pre-established communication link between a source device sending data and an audio device receiving data and does not require sending or receiving an acknowledgement or negative acknowledgement.

[0054] Reference should be made to Figures 1 to 15 the following description. Figure 1 is a schematic diagram of components of a system 100 in accordance with the present disclosure. In some examples, the system 100 includes a source device 102 and at least one sink device 104. Additionally, in some examples as Figure 1 described in FIG. 1, the system 100 includes multiple sink devices 104A-104C (collectively, "sink devices 104" or "multiple sink devices 104"). The source device 102 is intended to be a device capable of establishing a wireless connection (e.g., wireless connection 132 (discussed below)) with at least one sink device 104. Although illustrated as a smartphone, it should be appreciated that the source device 102 can be selected from at least one of a tablet computer, a smart hub, a media center, a stereo center, a soundbar, a headphone enclosure, or any device capable of sending or broadcasting wireless data (discussed below) to at least one sink device 104. Further, although illustrated as a pair of true wireless earbuds 104A, a glasses form factor device 104B, and an over-ear form factor headphone 104C, it should be appreciated that the sink devices 104 can be selected from at least one of a smartphone, a tablet computer, a smart hub, a media center, a stereo center, a soundbar, a headphone enclosure, or any device capable of receiving wireless data (discussed below) from the source device 102. In some examples, each sink device 104 is intended to be a device capable of reproducing audible sound energy (e.g., reproducing audio data) based on wireless data received from the source device 102. In some examples, as will be discussed below, the source device 102 is configured to send one or more supplemental packets 140 (discussed below) to each sink device 104, which can include error correction codes and / or additional codes to recover and / or enhance the audio data, before reproducing the audio data.

[0055] AsFigure 2 As illustrated in FIG. 1, source device 102 includes source controller 106, which includes source processor 108 and source memory 110 that respectively execute and store a plurality of non-transitory computer-readable source instructions 112 to perform various functions of source device 102 as will be described herein. Source controller 106 also includes source communication module 114 that is configured to transmit and / or receive wireless data, e.g., data related to at least one of a plurality of wireless data streams discussed below (e.g., wireless connection 132). To this end, source communication module 114 can include at least one radio or antenna, e.g., source radio 116, capable of transmitting and receiving wireless data. In some examples, in addition to the at least one radio (e.g., source radio 116), source communication module 114 can also include some form of automatic gain control (AGC), modulator and / or demodulator, and potentially a separate processor for bit processing, electrically connected to source processor 108 and source memory 110, to assist in transmitting and / or receiving wireless data.

[0056] As Figure 3 As illustrated in FIG. 1, each sink device 104 can include sink controller 118, which includes sink processor 120 and sink memory 122 that are configured to respectively execute and store a plurality of non-transitory computer-readable sink instructions 124 to perform various functions of each sink device 104 as will be described herein. Each sink controller 118 also includes sink communication module 126 that is configured to transmit and / or receive wireless data, e.g., data related to at least one of a plurality of wireless data streams discussed below (e.g., wireless connection 132). To this end, each sink communication module 126 can include at least one radio or antenna, e.g., sink radio 128, capable of transmitting and receiving wireless data. In some examples, in addition to the at least one radio (e.g., sink radio 128), sink communication module 126 can also include some form of automatic gain control (AGC), modulator and / or demodulator, and potentially a separate processor for bit processing, electrically connected to sink processor 120 and sink memory 122, to assist in transmitting and / or receiving wireless data. As Figure 3It should be appreciated that, as illustrated, each sink device 104 can also include at least one speaker, i.e., a sink speaker 130, which is, for example, a loudspeaker or acoustic transducer, that is electrically connected to the sink processor 120 and the sink memory 122 and configured to electromechanically convert electrical signals into audible sound energy, e.g., audio playback, within an environment surrounding each sink device. In some examples, the electrical signals and audible sound energy are associated with data included in the wireless connections 132 (discussed below). Further, although not illustrated, each sink controller 118 can include one or more clocks or time keeping circuits configured to maintain independent time during operation of the system 100.

[0057] Each device of the system 100, i.e., the source device 102 and each sink device 104, can use their respective communication modules to establish one or more wireless connections 132A-132C (collectively, “wireless connections 132”) between the source device 102 and each sink device 104. Wireless data can be transmitted and / or received using each wireless connection 132 via one or more wireless data streams between the source device 102 and each sink device 104. In some examples, each data stream is a synchronous data stream 136A-136C (collectively, “synchronous data streams 136” or “synchronous streams 136”), e.g., a connection synchronous stream using the LE Audio standard. In other examples, as will be described below, the synchronous data streams 136 are broadcast synchronous streams, e.g., where the source device 102 is configured to broadcast one or more synchronous streams 136 that are received by one or more sink devices 104. By way of example, the source device 102 can be configured to generate, broadcast, or otherwise wirelessly transmit one or more wireless data streams that are received by each sink device 104. It should be appreciated that the streams established on each wireless connection 132 can use various wireless data protocols, standards, or transmission methods, e.g., the Bluetooth Low Energy protocol, the Bluetooth Low Energy ISO Transport Protocol, or the LE Audio standard. In some examples, these protocols are used to transmit, receive, or otherwise communicate audio data, e.g., data used by the sink devices 104 to generate audible sound energy in the form of audio playback. However, it should be appreciated that these protocols are not limited to the transmission of audio data and include other types of data.

[0058] As Figures 4A to 6As illustrated, each synchronization stream 136 includes one or more of a plurality of data packets 138A-138D (collectively, "data packets 138") and / or one or more supplemental data packets of a plurality of supplemental data packets 140A-140H (collectively, "supplemental packets 140"). As described herein, the data packets 138 are transmitted by the source device 102 to one or more of the sink devices 104 and can include data used by the one or more sink devices 104 to generate or reproduce audible sound energy (e.g., audio playback). In other words, the data packets 138 can include audio data and / or one or more audio data frames that can be used by the sink speakers 130 of each sink device 104 discussed above to generate audible sound energy. To this end, the data packets 138 can be framed or unframed packets. For example, a framed packet can include a header and a payload, while an unframed packet does not include a packet header. In some examples, the header can include fields for fragmentation header data and time offset data, while the payload includes encoded wireless data to be transferred from one device to another. By way of example, if the data to be transferred is audio data associated with one or more audio files, the payload can include audio data in the form of one or more frames of encoded audio data. In unframed arrangements, during initial negotiation of the wireless connection 132, the source controller 106 and each sink controller 118 can negotiate and agree upon parameters that are typically specified in a header of each packet, such that each device knows what type of data and what parameters will be used when transmitting and receiving data, such that including a header is redundant and not necessary.

[0059] In addition to being framed or unframed, each supplemental packet 140 can also include data intended to correct, restore, or enhance data transmitted within one or more of the plurality of data packets 138. For example, as will be discussed in detail below, each supplemental packet 140 can include an error correcting code intended to assist each sink device 104 in restoring or reconstructing at least a portion of one or more data packets 138 that were not successfully received from one or more of the plurality of synchronized streams 136. Alternatively or additionally, each supplemental data packet can include additional data related to one or more data packets 138 that were successfully received from one or more of the plurality of synchronized streams 136, which each sink device 104 can use to enhance the already received data. For example, if a data packet 138 includes audio data or frames of audio data encoded at a lower bit rate or lower quality (e.g., 72 kbps), a supplemental packet 140 can provide additional audio data (e.g., 72 kbps) that would effectively increase the bit rate, and thus the quality of the audio decoded for each frame (e.g., to 144 kbps). It should be appreciated that supplemental packets 140 can be encrypted such that only authorized sink devices 104 can access the error correction or enhancement capabilities provided by supplemental packets 140.

[0060] As will be described below, in some examples, the supplemental packets 140 include error correcting codes. In some examples, the error correcting codes can be selected from any hard decision block code, for example, the error correcting codes can be selected from at least one of Reed-Solomon encoding, multi-dimensional parity check, or Hamming code. It should be appreciated that convolutional codes can also be used, however, this would result in soft decision and potentially increase error correction performance at the expense of artifacts, for example, audio artifacts when soft decision results in incorrect results. Additionally, for the selected block code, the parity check format used can be redundant array of independent disks (RAID) 5 and RAID 6, as they do not require large memory and processing at the decoder side (e.g., at the sink controller 118 side).

[0061] As Figures 4A to 6As shown, it illustrates an example configuration in which data packets 138 and supplemental packets 140 are transmitted via one or more synchronized streams, e.g., streams in which packets are transmitted during predetermined synchronized time intervals (e.g., synchronized intervals 142A-D (collectively, "synchronized intervals 142")) along time T. Each synchronized interval 142 can include a plurality of synchronization events and sub-events that partition and subdivide each Bluetooth synchronized interval based on initial negotiation of a given wireless connection. Additionally, data packets 138 and supplemental packets 140 can be transmitted within the same synchronized stream 136 or within different synchronized streams 136, e.g., via different frequencies or channels. In the example illustrated in FIG. 1, data packets 138 are transmitted in a first synchronized stream 136A using a first frequency 144, while supplemental data packets 140 are transmitted in a second synchronized stream 136B using a second frequency 146 that is different than the first frequency 144. As shown, supplemental packets 140 transmitted via the second synchronized stream 136B are time-shifted relative to data packets 138 transmitted via the first synchronized stream 136A. As a result of this time-shifting, no overlap occurs between packets of each respective stream, it should be appreciated that both the first synchronized stream 136A and the second synchronized stream 136B can be generated by the same radio device (e.g., source radio device 116). Figure 4A In the example illustrated in FIG. 1, data packets 138 are transmitted in a first synchronized stream 136A using a first frequency 144, while supplemental data packets 140 are transmitted in a second synchronized stream 136B using a second frequency 146 that is different than the first frequency 144. As shown, supplemental packets 140 transmitted via the second synchronized stream 136B are time-shifted relative to data packets 138 transmitted via the first synchronized stream 136A. As a result of this time-shifting, no overlap occurs between packets of each respective stream, it should be appreciated that both the first synchronized stream 136A and the second synchronized stream 136B can be generated by the same radio device (e.g., source radio device 116). Figures 4A to 4B In the example illustrated in FIG. 1, data packets 138 are transmitted in a first synchronized stream 136A using a first frequency 144, while supplemental data packets 140 are transmitted in a second synchronized stream 136B using a second frequency 146 that is different than the first frequency 144. As shown, supplemental packets 140 transmitted via the second synchronized stream 136B are time-shifted relative to data packets 138 transmitted via the first synchronized stream 136A. As a result of this time-shifting, no overlap occurs between packets of each respective stream, it should be appreciated that both the first synchronized stream 136A and the second synchronized stream 136B can be generated by the same radio device (e.g., source radio device 116).

[0062] With particular reference to the example of illustrating system 100, Figure 4A source device 102 is configured to transmit a plurality of data packets 138A-D via a first broadcast synchronized stream 136A and at a first frequency 144. Additionally, source device 102 is also configured to transmit a plurality of supplemental data packets 140 via a second broadcast synchronized stream 136B at a second frequency 146 that is different than the first frequency 144. In particular, as illustrated, within the first synchronized interval 142A, source device 102 is configured to transmit a first data packet 138A (shown schematically as a shaded square having the numeral "1" displayed thereon) and one or more retransmission packets (shown schematically as a shaded square having the numeral "1" displayed thereon) that include the same payload as the first data packet 138A. Figure 4A In the example illustrated in FIG. 1, data packets 138 are transmitted in a first synchronized stream 136A using a first frequency 144, while supplemental data packets 140 are transmitted in a second synchronized stream 136B using a second frequency 146 that is different than the first frequency 144. As shown, supplemental packets 140 transmitted via the second synchronized stream 136B are time-shifted relative to data packets 138 transmitted via the first synchronized stream 136A. As a result of this time-shifting, no overlap occurs between packets of each respective stream, it should be appreciated that both the first synchronized stream 136A and the second synchronized stream 136B can be generated by the same radio device (e.g., source radio device 116). Figure 4Awhite squares) are shown. After transmitting the first data packet 138A and the two retransmission packets associated with the first data packet 138A, and within the first broadcast synchronization stream 136A, the source device 102 is also configured to transmit one or more supplemental packets 140, i.e., supplemental packets 140A and 140B, via the second broadcast synchronization stream 136B. As discussed above, each of the supplemental packets 140A and 140B can contain an error correction code computed based on one or more data packets 138 that can be used by one or more sink devices 104 to recover or reconstruct the data packets 138. Alternatively, as discussed above, the supplemental packets 140A and 140B can contain additional data for augmentation or addition to, for example, data successfully obtained in the first data packet 138A, e.g., additional audio data or audio frames. Further, and similar to the packets sent during the first synchronization interval 142A, the source device 102 is configured to send the second data packet 138B, the third data packet 138C, and the fourth data packet 138D (shown in Figure 4A respectively) during the second synchronization interval 142B, the third synchronization interval 142C, and the fourth synchronization interval 142D, respectively, within the second broadcast synchronization stream 136B. Additionally, one or more retransmission packets can follow each respective packet (shown in Figure 4A respectively). Also, within the second synchronization stream 136B, and during each synchronization interval 142, the source device 102 is configured to send one or more supplemental packets 140, e.g., supplemental packets 140C and 140D during the second synchronization interval 142B, supplemental packets 140E and 140F during the third synchronization interval 142C, and supplemental packets 140G and 140H during the fourth synchronization interval 142D. The supplemental packets 140A-H are illustrated as boxes with cross-hatching. It should be appreciated that the supplemental packets 140A-H are also time-shifted relative to the data packets 138 and their respective retransmission packets, such that no overlap occurs between the data packets and the supplemental packets. Thus, a single radio device, i.e., the source radio device 116, can broadcast the data packets 138, the respective retransmission packets associated with the data packets 138, and the supplemental packets 140.

[0063] Figure 4B One example of a system 100 that includes the use of supplemental packets 140 with error correction codes to recover missing data packets is illustrated. As shown, each supplemental packet 140 can include an error correction code computed using data from one or more data packets 138A-D. For example, as shown, the first data packet 138A and the second data packet 138B are successfully received, while the third data packet 138C is missing (shown in Figure 4Bby the solid line "X" on the third data packet 138C and its corresponding retransmission packets). Additionally, supplemental packets 140A-140D are transmitted via the second broadcast synchronization stream 136B. Since supplemental packet 140C can include error correction codes calculated using data packets 138A-138B, the error correction codes of supplemental data packet 140C can be used to calculate and recover the missing packet (e.g., 138C) and pass the data from the missing packet to the sink device 104 for decoding the first synchronization stream 136A. In other words, the error correction codes within supplemental packet 140C can use data from the first data packet 138A, the second data packet 138B, and the supplemental packet 140C to reconstruct the missing or lost data packet 138C (illustrated by the arrow in Figure 4B It should be appreciated that the error correction codes within a given supplemental packet 140 can be calculated using one or more data packets 138. For example, although not illustrated, supplemental packets 140A and / or 140B can be calculated based on two data packets, i.e., the first data packet 138A and the second data packet 138B. Thus, given that at least one of these data packets and one of the supplemental packets is successfully received, the missing data packet can be recovered. Additionally, it should be appreciated that within the second synchronization stream 136B, multiple supplemental packets 140 are transmitted within a single synchronization interval, e.g., supplemental packets 140A and 140B are transmitted within the first synchronization interval 142A. In this example, supplemental packet 140A can include error correction codes or additional data to enhance one or more packets 138, while supplemental packet 140B is a retransmission of supplemental packet 140A, i.e., supplemental packet 140B has the same payload as supplemental packet 140A.

[0064] As Figure 5As shown, the plurality of data packets 138 can include a first plurality of data packets 148A-148D (collectively referred to as "the first plurality of packets 148") and a second plurality of data packets 150A-150D (collectively referred to as "the second plurality of packets 150"). As illustrated, the first plurality of packets 148 is transmitted via a first synchronization stream, i.e., a first broadcast synchronization stream 136A, while the second plurality of data packets 150 is transmitted via a second synchronization stream, i.e., a second broadcast synchronization stream 136B. It should be appreciated that the first broadcast synchronization stream 136A can be transmitted using a first frequency 144, while the second broadcast synchronization stream 136B can be transmitted using a second frequency 146 that is different than the first frequency 144. Additionally, the second plurality of packets 150 can be time-shifted relative to the first plurality of packets 148 such that there is no temporal overlap in the play time for transmitting each of the respective pluralities of packets. Thus, a single radio device, e.g., the source radio device 116, can be used to transmit both the first plurality of data packets 148 and the second plurality of data packets 150. The first plurality of data packets 148 includes audio data or audio data frames associated with a left channel audio stream, while the second plurality of data packets 150 includes audio data or audio data frames associated with a right channel audio stream. In other words, for a stereo application, left channel audio can be transmitted via a separate channel or frequency, while right channel audio can be transmitted via another separate channel or frequency. Similarly Figures 4A to 4B The first plurality of data packets 148A-148D and the second plurality of data packets 150A-150D are illustrated as shaded boxes having the numbers 1-4 displayed thereon, respectively. Additionally, retransmission packets associated with each of these packets are illustrated as white boxes having the corresponding numbers 1-4 displayed thereon. Furthermore, the supplemental data packets 140A-140H are illustrated as boxes having cross-hatching.

[0065] Similarly to the supplemental packets 140 described above with respect to Figures 4A to 4B The supplemental data packets 140 can be transmitted via yet another separate channel or frequency. For example, a third synchronization stream, i.e., a third broadcast synchronization stream 136C, can be used to transmit the supplemental data packets 140 via a third frequency 152, where the third frequency 152 is different than the first frequency 144 and the second frequency 146. Furthermore, the supplemental packets 140 can be time-shifted or offset relative to both the first plurality of packets 148 and the second plurality of packets 150. By time-shifting the first plurality of packets 148, the second plurality of packets 150, and the supplemental packets 140 relative to one another and such that none of these packets are transmitted simultaneously, a single radio device, e.g., the source radio device 116, can be used to transmit all three synchronization streams 136A-136C.

[0066] In Figure 5In the example illustrated, it will be appreciated that the supplemental packets 140A-140H can include error correction codes computed based on one or more of the first plurality of packets 148 and / or one or more of the second plurality of packets 150. For example, within each synchronization interval, one or more data packets of the first plurality of packets 148 and two retransmission packets associated with each respective data packet 148 are transmitted within the first broadcast synchronization stream 136A, while one or more data packets of the second plurality of packets 150 and two retransmission packets associated with each respective data packet 150 are transmitted within the second broadcast synchronization stream 136B. Following transmission of these data packets and their respective retransmission packets, and within each synchronization interval 142, two supplemental packets 140 are transmitted via the third broadcast synchronization stream 136C. Within each synchronization interval, one of the two supplemental packets 140 can include an error correction code computed based on one or more of the first plurality of packets 148, while the other supplemental packet 140 can be computed based on one or more of the second plurality of packets 150. In other words, within each synchronization interval 142, two supplemental packets 140 are transmitted. One of the two supplemental packets will include an error correction code computed based on packets associated with the left channel audio stream, while the other supplemental packet will include an error correction code computed based on packets associated with the right channel audio stream. For example, as shown in Figure 5 supplemental packet 140C can be computed based on data packets 148A and 148B, while supplemental packet 140D can be computed based on data packets 150A and 150B. In this manner, given that either of packets 148A or 148B is lost and the other is successfully received, supplemental packet 140C can recover or reconstruct the missing packet. Similarly, given that either of packets 150A or 150B is lost and the other is successfully received, supplemental packet 140D can recover or reconstruct the missing packet.

[0067] As Figure 6As shown, supplemental packets can be transmitted prior to one or more corresponding data packets or after the corresponding packets. For example, as shown, supplemental packet 140A (represented as a cross-hatched box with the letter "R" displayed thereon) can contain an error correction code computed based on data of first packet 138A and second packet 138B. Because supplemental packet 140A is transmitted in time between first packet 138A and second packet 138B, supplemental packet 140A is referred to as a pre-transmission, i.e., the supplemental packet is transmitted in time prior to at least one packet from which the error correction code of the supplemental packet is computed. Thus, the first supplemental packet 140 transmitted within each synchronization interval 142 can be a pre-transmission packet having an error correction code computed based on a packet immediately preceding the packet within first synchronization stream 136A and a packet immediately following the packet. For example, supplemental packet 140C is computed based on data packet 138B and data packet 138C, and supplemental packet 140E is computed based on data packet 140C and data packet 140D. It should be appreciated that the illustrated supplemental packets contain a letter displayed on each representative box that indicates progression through a sequential order of packets having letters. For example, supplemental packets 140A, 140C, and 140E contain consecutive payloads represented as R, S, and T to illustrate that each of these supplemental packets is in logical alphabetical order with respect to one another. To increase the robustness of the system discussed herein, the second supplemental packet 140 transmitted within each synchronization interval 142 can be a post-transmission or post-retransmission packet, as each post-retransmission packet can be computed based on one or more packets transmitted immediately prior to the post-retransmission packet. For example, as shown, the payload associated with a retransmission packet can be shifted in time such that the retransmitted payload is in the future by one or more complete synchronization intervals with respect to the data packets used to compute the error correction code retained therefor. For example, as shown, the payload of retransmission packet 140G is represented as "T" to illustrate that the payload of this retransmission packet is in the future by one complete synchronization interval with respect to the data packet 138D used to compute the error correction code retained therefor. Figure 6 As shown, the second supplemental packets 140 transmitted within each synchronization interval 142 are each computed based on data packets transmitted at least two synchronization intervals prior to the transmission of the corresponding supplemental packet 140. In particular, as shown, supplemental data packet 140F is labeled with "R" to indicate that the payload within this supplemental packet is the same as the payload within supplemental packet 140A, and the error correction code within these packets is computed based on data within packets 138A and 138B. As such, the post-transmission of this payload is in the future by two synchronization intervals with respect to the data packets used to compute the error code contained therein.

[0068] This example pre- and post-transmission configuration is advantageous in situations where packet loss is common, or where packet loss occurs at the end of a particular link budget of the wireless connection described herein. For example, given that a connection experiences interference within a particular synchronization interval, both the data packet 138 and the supplemental packet 140 that can assist in recovering those data packets can be lost. By providing post-transmissions in future synchronization intervals, the likelihood of resolving the interference that caused the initial packet loss is increased, and in the case of a sufficiently large buffer, all of the initially lost packets can be recoverable. For example, as shown, given that interference or other factors cause data packet 138A as well as supplemental packets 140A and 140B to be lost or missing, a post-transmission packet 140F including the same payload as the lost packet 140A will be sent at a different time in the future, at which point the interference can have been resolved, and the post-transmitted supplemental data can be used with packet 138B to recover the lost packet 138A.

[0069] In some examples, packet recovery using the methods described herein can be iterative. For example, referring to Figure 6 , given that interference or other environmental factors cause packets 138A, 138B, and 140A to be lost, the systems and methods described herein can begin recovery of packet 138B by using data from received packet 138C and received supplemental packet 140C. Once packet 138B is recovered, the system 100 can use the recovered packet 138B and post-transmission packet 140F to recover the first packet 138A.

[0070] As mentioned above, it should be appreciated that the broadcast stream described in the present disclosure can utilize encryption to prevent unauthorized users from accessing the error correction and enhancement capabilities described herein. For example, the source controller 106 can take the encoded data that is to be sent via the broadcast synchronization stream associated with the supplemental packets 140 and encrypt each packet prior to broadcast. The respective keys of the key pair used to encrypt the data can be sent to the authorized sink devices 104 prior to initiating the stream, such that the sink controllers 118 of the authorized devices can decrypt the decoded data provided in the supplemental stream. In this way, the data associated with the first broadcast synchronization stream 136A will still be available to unauthorized users or devices, but the increased robustness resulting from the use of error correction codes and / or the increased quality of additional audio data sent within the supplemental packets 140 will not be available. In other words, in this example, the broadcast stream data associated with the data packets 138 will not be encrypted, while the broadcast stream data associated with the supplemental data packets 140 will be encrypted. In another example, both the broadcast stream data associated with the data packets 138 and the broadcast stream data associated with the supplemental data packets 140 will be encrypted. For example, the broadcast stream associated with the data packets 138 can utilize a first encryption key pair Kp1 (atFigure 2 and Figure 3 associated with supplemental packets 140 will utilize a second encryption key pair KP2 that is different from the first encryption key pair KP1. In this manner, for an unauthorized user or an unauthorized device, data associated with the first broadcast synchronization stream 136A will be available as long as the user or device has access to the respective key of the first encryption key pair KP1 used to decrypt data associated with data packets 138, but only in the case that the user or device has access to the respective key of the second encryption key pair KP2 used to decrypt data associated with supplemental data packets 140 will the increased robustness resulting from the use of error correction codes and / or the increased quality of additional audio data sent within supplemental data packets 140 be available.

[0071] Additionally, it should be appreciated that although illustrated as separate streams, data packets 138 and supplemental packets 140 described herein can be sent within the same synchronization stream. Referring to Figure 4A For example, within the first synchronization interval 142A, packets 138A and their respective retransmission packets can be sent. Immediately following the last retransmission packet and within the first synchronization interval 142A, supplemental packets 140A and 140B can be sent by system 100. Supplemental packets 140A and 140B will be time-shifted relative to packets 138A and the respective retransmission packets such that all packets can be sent using a single radio device, e.g., source radio device 116. It should be appreciated that in this example, a packet header can be needed to indicate to the sink controller 118 of each sink device 104 the type of data sent in each packet of the first synchronization stream 136A. Further, the examples provided herein describe the use of data contained in one or more supplemental packets sent via a second broadcast synchronization stream to recover, reconstruct, or enhance data sent via a first broadcast synchronization stream. It should be appreciated that each packet 138 (or packets 148 and 150) can include multiple frames of audio data. As such, the error correction codes and / or additional data provided in supplemental packets 140 can be computed or applied on a per frame basis rather than on a per packet basis. In other words, one or more supplemental data packets 140 are used to reconstruct and / or enhance at least a portion (one or more frames) of one or more data packets 138 (or packets 148 and 150) of a plurality of data packets.

[0072] While the above description provides for multiple broadcast synchronization streams, it should be appreciated that similar concepts can be employed on non-broadcast systems, such as using a connection synchronization stream between the source device 102 and each of the sink devices 104. If applied in a non-broadcast scenario, such as with a connection synchronization stream, the system can include an additional interface to the source controller 106 to indicate which packets need to be acknowledged by the source controller 106 but not time received. In the non-broadcast example, the system described herein includes acknowledging successful recovery or reconstruction of one or more of the plurality of data packets 138. Thus, the described system makes it possible to reconstruct packets that were difficult for the sink device 104 to receive and send an acknowledgement of the successful recovery of that packet so that the system can continue transmission of the next packet required by that sink device.

[0073] Figure 7 The simplicity of the implementation of the systems and methods described herein is illustrated. For example, the benefit of the configuration disclosed herein is that it does not require any changes to the Bluetooth radios or controllers that the source and sink devices currently use for audio transmission. For example, the implementations described herein can be implemented by creating an interface between a synchronization adaptation layer (ISOAL) and a traditional LC3 encoder / decoder and the I2S serial bus interface of a typical audio source and sink device. This interface is represented by the rectangle labeled “hook” in FIG. 1. Additionally, when pre-computing packets, the system can utilize this interface to indicate to the source controller 106 which packets of the first synchronization stream 136A to pre-pick up. The same interface would be required when error correction codes are post-transmitted and not needed. Figure 7

[0074] Figure 8 The steps of an example method 200 according to the present disclosure are illustrated. The method 200 includes, for example: transmitting a synchronization stream 136A including a plurality of data packets 138 (or 148 and 150) transmitted within a first synchronization interval 142A or using a first frequency 144 (step 202); and transmitting one or more supplemental data packets 140 within the first synchronization interval 142A and shifted in time relative to the plurality of data packets 138 (or 148 and 150) or at a second frequency 146 different from the first frequency 144 (step 204); wherein the one or more supplemental data packets 140 are used to reconstruct and / or enhance at least a portion of one or more of the plurality of data packets 138 received during the first synchronization interval 142A or wherein the one or more supplemental data packets 140 are used to create and / or enhance at least a portion of one or more of the plurality of data packets 138 to be received during the first synchronization interval 142A or during a second synchronization interval 142B after the first synchronization interval 142A. Optionally, the method 200 can also include acknowledging successful receipt of the one or more supplemental data packets 140 (step 206).​

[0075] Figure 9A Examples Figure 4A The illustrated variation of the wireless topology involves supplementary data packets 140A to 140H being transmitted in the same first synchronization stream 136 as data packets 138A to 138D, instead of in a separate second synchronization stream. Each data packet in data packets 138A to 138D may include audio data or audio frames for playback by the destination device 104. Furthermore, each supplementary data packet in supplementary data packets 140A to 140H is transmitted in place of retransmission packets (such as...). Figure 4A A retransmitted packet (shown as a white square in Figure 1-4). For example, supplementary packets 140A to 140H can be transmitted in the same time slot that would normally be used for retransmission of typical synchronous stream data packets. Overall system efficiency can be improved by replacing the transmitted packets with supplementary data packets 140A to 140H because... Figure 4A The topology removes the entire flow from system 100, while transmitting two fewer packets per synchronization interval 142A to 142D. As in the previous example, various combinations of data packets 138A to 138D with supplementary data packets 140A to 140H can be used to create, reconstruct, or recover data packets 138A to 138D lost during transmission from source device 102 to destination device 104. While some reconstruction schemes may require a combination of both data packet 138 and supplementary data packet 140 to reconstruct data packet 138, other reconstruction schemes may require only data packet 138 or supplementary data packet 140, rather than both types of packets 138 and 140. In some examples, supplementary data packets 140A to 140H can also be used to enhance data packets 138A to 138D successfully received by destination device 104. Furthermore, if synchronization stream 136 is a connected synchronization stream, then when one of the data packets 138A to 138D is successfully created, rebuilt, or recovered using error correction, the sink device 104 may provide acknowledgment to the source device 102.

[0076] The technique of transmitting supplementary data packets in retransmission slots allows for more reliable transmission of more data within a given time period, resulting in more robust transmission and / or increased data bandwidth. Therefore, if increased data bandwidth is not required, additional supplementary data packets can be transmitted to increase the robustness of data transmission, especially in environments with challenging RF conditions (such as Wi-Fi or other RF interference, physical obstacles, etc.). In other configurations, if increased data bandwidth is desired, such as to increase the number of audio channels being transmitted, the technique may include transmitting a lower number of supplementary data packets per data packet. This enables, for example, the transmission of 5-12 audio data channels to achieve a spatialized audio experience using a single audio device (e.g., a set of headphones or earbuds) or multiple audio devices (e.g., a set of surround sound wireless speakers).

[0077] In Figure 9A examples, source device 102 is configured to transmit a plurality of data packets 138A-138D via synchronous stream 136. Synchronous stream 136 is divided into a series of synchronization intervals 142A-142D. The series of synchronization intervals 142A-142D (and the data within synchronization intervals 142A-142D) can be considered a data block 154. Each synchronization interval 142A-142D includes data packets 138A-138D and two supplemental data packets 140A-140H. In Figure 9A examples, the two supplemental data packets 140A-140H of synchronization intervals 142A-142D are transmitted immediately after data packets 138A-138D. While Figure 9A examples illustrate data packets 138 being transmitted prior to corresponding supplemental data packets 140, in other examples, supplemental data packets 140 can be transmitted prior to data packets 138. Further, while Figure 9A examples illustrate each synchronization interval 142 as including at least one data packet 138 and at least one supplemental packet, in other examples, some synchronization intervals 142 or synchronization events can include only data packets 138 or supplemental data packets 140, but not both.

[0078] In some examples, each data packet 138A-138D and / or each supplemental data packet 140A-140H can include header information. The header information can include a variety of information, such as data regarding an error correction code and / or data identifying data packets 138A-138D or supplemental data packets 140A-140H. The error correction code information can identify a type of error correction being implemented by system 100, such as Reed-Solomon encoding, multi-dimensional parity check, or Hamming code. By incorporating error correction code information into the header of data packets 138A-138D and / or supplemental data packets 140A-140H, source device can dynamically change the type of error correction used when receiving synchronous stream 136. The packet identification information can inform source device 102 of the sequential order of data packets 138A-138D of the synchronous stream. In further examples, the error correction code information can be transmitted by source device 102 prior to first synchronization interval 142A. In these examples, the error correction code information can be transmitted as part of synchronous stream 136 as depicted in Figure 9A or as part of another wireless transmission.

[0079] Figure 9B variations of the wireless topology shown in Figure 4B are illustrated, in which sink device 104 fails to receive a third data packet 138C of synchronous stream 136. Figure 9BThe topology uses a first data packet 138A received during the first synchronization interval 142A, a second data packet 138B received during the second synchronization interval 142B, and a third supplementary data packet 140C also received during the second synchronization interval 142C to reconstruct the third data packet, rather than relying on retransmitted data packets. In this example, the sink device 104 is previously provided with error correction codes indicating which combinations and numbers of data packets 138A to 138D and supplementary data packets 140A to 140H are needed to reconstruct the data packets 138A to 138D lost during transmission. Error correction codes identifying the type of error correction being implemented can be embedded in the headers of supplementary data packets 140A to 140H. In this example, to reconstruct the lost data packet 138C, error correction codes may be needed following the two data packets 138A and 138B immediately preceding the lost data packet 138C. The headers of data packets 138A to 138D may also include identification information that facilitates this reconstruction. In some examples, each data packet in data packet 138 may correspond to one channel of a multi-channel audio stream. For example, if three audio channels are required, the first portion of data packet 138 and supplementary data packet 140 may correspond to the first audio channel, the second portion of data packet 138 and supplementary data packet 140 may correspond to the second audio channel, and the third portion of data packet 138 and supplementary data packet 140 may correspond to the third audio channel.

[0080] Figure 10 Examples Figure 6 The variation of the wireless topology shown includes one or more supplementary packets 140A to 140F transmitted before their corresponding data packets 138A to 138D. Furthermore, with... Figures 9A to 9B Similarly, data packets 138A to 138D and supplementary data packets 140A to 140F are all transmitted by the same synchronization stream 136. For example, as shown, error correction data for supplementary packet 140A (represented by a crosshair square with the letter "R" displayed on it) can be generated based on the data of the first packet 138A and the second packet 138B. Because supplementary packet 140A is transmitted in time between the first packet 138A and the second packet 138B, supplementary packet 140A is referred to as a pretransmission packet, that is, the supplementary packet is transmitted in time before at least one packet from which the error correction data of the supplementary packet is calculated. Therefore, the first supplementary packets 140A-F transmitted within each synchronization interval 142A-D can be pretransmission packets with error correction codes calculated based on packets transmitted immediately before and immediately after the packets within the first synchronization stream 136. This exemplary pretransmission and posttransmission configuration is advantageous in situations where packet loss is common or at the end of a particular link budget for the wireless connection described herein.

[0081] Further, Figure 10 An overlapping error correction scheme is exemplified, in which a pre-transmission supplemental data packet or a post-transmission supplemental data packet can be used to reconstruct a data packet 138. For example, in Figure 10 , a first and / or second ("R" and "P") supplemental data packet 140A, 140B (transmitted before the second data packet 138B) from the first synchronization interval 142A or a third and / or fourth ("S" and "Q") supplemental data packet 140C, 140D (transmitted after the second data packet 138B) from the second synchronization interval 142B can be used to reconstruct the second data packet 138B. However, in applications where efficiency is a primary concern, non-overlapping error correction is preferred. Latency is improved by transmitting a data packet 138 before transmitting a supplemental data packet 140 used to reconstruct or augment the data packet 138.

[0082] Figure 11A and Figure 11B The benefits of using supplemental data packets 140 to reconstruct data packets 138 lost during transmission are exemplified. Specifically, Figure 11A and Figure 11B A non-limiting example is exemplified in which a sink device 104 receives data packets 138 and supplemental data packets 140 during eight synchronization intervals 142, and the resulting data packets 138 are provided for playback. Other examples can use any practical number of synchronization intervals 142. Figure 11A A typical packet transmission scheme for a data block 154 of eight data packets 138 is exemplified, in which each data packet 138 is transmitted three times during a synchronization interval 142. In this non-limiting exemplary example, each data packet 138 contains a payload of an audio frame that is 5 milliseconds, 7.5 milliseconds, or 10 milliseconds in length. Thus, the data block 154 includes a total of twenty-four data packets 138. However, due to one or more of a variety of potential problems with transmission and reception, the sink device 104 receives only nine of the twenty-four data packets; two first data packets 138A, two second data packets 138B, one fourth data packet 138D, one fifth data packet 138E, and three seventh data packets 138G. The sink device fails to completely receive the third data packet 138C, the sixth data packet 138F, and the eighth data packet 138H. Since at least one data packet 138 is required to reproduce audio, the sink device 104 fails to reproduce the audio corresponding to the third data packet 138C, the sixth data packet 138F, and the eighth data packet 138H, resulting in three lost audio frames and three instances of audio dropout over a three-period of 5 milliseconds to 10 milliseconds. Furthermore, the repeated first data packets 138A, second data packets 138B, and seventh data packets 138G received by the sink device 104 do not provide an additional benefit to the reproduced audio.

[0083] Figure 11B The solution illustrated in the figure solves the above problems. Figure 11B Examples Figure 11A A variation of the transmission scheme is used where, instead of transmitting two duplicate data packets 138 every synchronization interval 142, these duplicate data packets 138 are replaced with supplementary data packets 140 used to create, reconstruct, or restore data blocks 154. Furthermore, the receiving device 104 has been provided with error-correcting codes, allowing each of the eight data packets 138A through 138H to be reconstructed based on any combination of the eight data packets 138 and the supplementary data packets 140. Figure 11B As shown, during the first synchronization interval 142A, the destination device 142 receives the first data packet 138A (containing the first audio frame) and the ninth supplementary data packet 140I. During the second synchronization interval 142B, the destination device 104 receives the second data packet 138B (containing the second audio frame) and the second supplementary data packet 140B. The destination device 104 fails to receive any data during the third synchronization interval 142C. During the fourth synchronization interval 142D, the destination device 104 receives the fourth supplementary data packet 138D. During the fifth synchronization interval 142E, the destination device 104 receives the thirteenth supplementary data packet 138M. The destination device 104 fails to receive any data during the sixth synchronization interval 142F. During the seventh synchronization interval 142G, the destination device 104 receives the seventh data packet 138G (containing the seventh audio frame), the seventh supplementary data packet 140G, and the fifteenth supplementary data packet 140O. The destination device 104 fails to receive any data during the eighth synchronization interval 142H. Therefore, the receiving device 104 receives three data packets 138A, 138B, and 138G (containing three audio frames) and six supplementary data packets B, D, G, I, M, and O, for a total of nine packets 138 and 140. Thus, by receiving a total of nine data packets 138 and 140, error correction codes can be used to reconstruct the lost third data packet 138C, fourth data packet 138D, fifth data packet 138E, sixth data packet 138F, and eighth data packet 138H, along with their associated audio frames. Therefore, the receiving device 104 can then reproduce the audio frames of all eight data packets 138, thereby generating zero dropped or zero lost audio during the duration of data block 154.

[0084] exist Figure 11BIn the error correction scheme, error correction requires at least a total of eight packets 138 and 140. Therefore, if fewer than a total of eight packets 138 and 140 are received, the supplementary data packet 140 will have no value. In a non-limiting example of Reed-Solomon encoding and decoding, if the receiving device 104 fails to receive the second supplementary data packet 140B and the seventh supplementary data packet 140H, the receiving device 104 will only reproduce the first audio frame, the second audio frame, and the seventh audio frame.

[0085] Figure 12 Examples Figure 9B A variation of the wireless topology shown in the diagram, wherein source device 102 transmits multiple data packets 138A to 138D and multiple supplementary data packets 140A to 140H via a synchronization stream group 158 comprising three synchronization streams 136A to 136C. Figure 9B Similarly, the three synchronization streams 136A to 136C can be divided into a series of synchronization intervals 142A to 142D. During the first synchronization event 156A1 of the first synchronization stream 136A in the first synchronization interval 142A, source device 102 transmits a first data packet 138A, a first supplementary data packet 140A, and a second supplementary data packet 140B. Then, during the first synchronization event 156B1 of the second synchronization stream 136B in the first synchronization interval 142A, source device 102 transmits a second data packet 138B, a third supplementary data packet 140C, and a fourth supplementary data packet 140D. Then, during the first synchronization event 156C1 of the third synchronization stream 136C in the first synchronization interval 142A, source device 102 transmits a third data packet 138C, a fifth supplementary data packet 140E, and a sixth supplementary data packet 140F. Then, during the second synchronization event 156A2 of the first synchronization stream 136A in the second synchronization interval 142B, source device 102 transmits the fourth data packet 138D, as well as the seventh supplementary data packet 140G and the eighth supplementary data packet 140H. This cyclical transmission mode can continue as long as source device 102 provides data packets 138 for transmission. Therefore, source device 102 changes the synchronization stream 136A to 136C for transmitting data packets 138 and supplementary data packets 140 at the end of each synchronization interval 142. Figure 9B As in the example, the host device 104 uses error correction data from the first data packet 138A, the second data packet 138B, and the third supplementary data packet 140C to reconstruct the third data packet 138C.

[0086] Figure 13 Examples Figure 12A variation of the wireless topology shown in FIG. 1 is illustrated in FIG. 2, in which four data packets 138A-138D are transmitted in succession, followed by five consecutive supplemental data packets 140A-140E. Source device 102 first transmits the first, second, and third data packets 138A-138C in first synchronization event 156A1 of first synchronization stream 136A during first synchronization interval 142A. Then, source device 102 transmits the fourth data packet 138D, as well as the first and second supplemental data packets 140A-140B in first synchronization event 156B1 of second synchronization stream 136B during first synchronization interval 142A. Then, source device 102 transmits the third, fourth, and fifth supplemental data packets 140C-140E in first synchronization event 156C1 of third synchronization stream 136C during first synchronization interval 142A. Then, source device 102 transmits the fifth, sixth, and seventh data packets 138E-138G in second synchronization event 156A2 of first synchronization stream 136A during second synchronization interval 142B. This pattern can continue as long as source device 102 provides data packets 138 and supplemental data packets 140 for transmission.

[0087] While Figure 12 and Figure 13 A synchronization stream group 158 is illustrated that alternates transmission between three synchronization streams 136A-136C, although any practical number of streams can be used. Also, while Figure 12 and Figure 13 An example of a repeating transmission pattern is illustrated, although in some examples the pattern of which synchronization stream 136A-136C transmits data packets 138 or supplemental data packets 140 during a synchronization interval 142 can be random or pseudo-random.

[0088] Also, in some examples, the transmission of data packets 138 and supplemental data packets 140 can be ordered to improve latency or packet loss concealment. To improve latency, some synchronization events within a synchronization stream 136 will include only data packets 138, while other synchronization events will include only supplemental data packets 140. Figure 13 An example of this type of ordering is shown in FIG. 3. In contrast, extending the transmission of data packets 138 within a data block 154 in time will improve packet loss concealment. In this example, data packets 138 are transmitted in an order that results in the longest possible time difference between two adjacent data packets 138. For example, if a data block 154 includes three data packets 138A-138C and three supplemental data packets 140A-140C, the transmission would be ordered as (1) first data packet 138A, (2) first supplemental data packet 140A, (3) third data packet 138C, (4) second supplemental data packet 140B, (5) second data packet 138B, and (6) third supplemental data packet 140C.

[0089] Figure 14 A variation of the wireless topology shown in Figure 9B is illustrated, in which the source device 102 transmits a plurality of data packets 138A-138D and a plurality of supplemental data packets 140A-140H via the synchronization stream 136. Figure 14 The example of Figure 9B differs from that of in that the supplemental data packets 140 of some of the synchronization intervals 142, specifically the second synchronization interval 142B and the third synchronization interval 142C, are transmitted before the data packets 138 of the corresponding synchronization interval 142.

[0090] Figure 15 Steps of an example method 300 according to the present disclosure are illustrated. The method 300 comprises, for example, transmitting (step 302) at least one data packet transmitted at a first time using a first frequency using a synchronization stream group comprising one or more synchronization streams, and transmitting (step 304) one or more supplemental data packets via the synchronization stream group. The one or more supplemental data packets are shifted in time relative to the at least one data packet and / or at a second frequency different from the first frequency.

[0091] According to an example, the at least one data packet is created, reconstructed and / or enhanced from error correction encoded supplemental data or enhancement data.

[0092] According to an example, the one or more supplemental data packets comprise error correction encoded supplemental data or enhancement data.

[0093] In an optional step, the method 300 further comprises transmitting (step 306) an error correction code packet comprising an error correction code via the source device to the sink device.

[0094] According to an example, each of the at least one data packet comprises a header. The header comprises supplemental data type information and / or packet identification information.

[0095] According to an example, each of the one or more supplemental data packets comprises a header. The header comprises supplemental data type information and / or packet identification information.

[0096] According to an example, when received by the audio device, the at least one data packet is usable to create a part of audio to be played by the audio device.

[0097] According to an example, the synchronization stream can be a broadcast synchronization stream or a connected synchronization stream. In examples in which the synchronization stream is a connected synchronization stream, the method 300 further comprises the following optional step: acknowledging (step 306) successful recovery of one or more of the plurality of data packets based on the plurality of supplemental data packets via the source device.

[0098] All definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and / or ordinary meanings of the defined terms.

[0099] The indefinite articles "a" and "an," as used herein in the specification and in the claims, unless clearly indicated to the contrary, should be understood to mean "at least one."

[0100] The phrase "and / or," as used herein in the specification and in the claims, should be understood to mean "either or both" of the elements so conjoined, i.e., elements that are conjunctively present (in some instances) jointly

[0101] "Or" as used herein in the specification and in the claims, should be understood to have the same meaning as "and / or" as defined above. For example, when separating items in a list, "or" or "and / or" shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also the inclusion of more than one, of elements that are conjunctively listed. Only terms clearly indicated to the contrary, such as "only one of or "exactly one of," or, when used in the claims, "consisting of," will refer to the inclusion of exactly one element of a number or list of elements. In general, the term "or" as used herein shall only be interpreted as indicating exclusive alternatives (i.e. "one or the other but not both") when preceded by terms of exclusivity, such as "either," "one of," "only one of," or "exactly one of."

[0102] The phrase "at least one," as used herein in reference to a list of one or more elements should be understood to mean at least one of the elements in the list, but not necessarily including at least one of each of the elements in the list. For example, "at least one of A, B, and C" should be understood as "at least one of A, at least one of B, and at least one of C."

[0103] It should also be understood that, unless clearly indicated to the contrary, in any methods claimed herein that include more than one step or act, the order of the steps or acts of the method is not necessarily limited to the order in which the steps or acts are recited.

[0104] In the claims, as well as in the specification above, all transitional phrases such as “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” “holding,” “composed of,” and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of’ and “consisting essentially of’ shall be closed or semi-closed transitional phrases, respectively.

[0105] The above examples of the subject matter described can be implemented in any of various ways. For example, some aspects can be implemented using hardware, software, or a combination thereof. When any aspect is implemented at least partially 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.

[0106] This disclosure can be implemented as a system, method, and / or computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

[0107] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or punched tape, as well as any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0108] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions to a computer readable storage medium within the respective computing / processing device for storage and / or installation.

[0109] Computer readable program instructions for carrying out operations of the disclosure can be in any interpretation of assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuitry, or any combination of 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 a procedural programming language such as the "C" programming language or similar programming languages. The computer readable program instructions can be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer, partly on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In some examples, electronic circuitry, including for example programmable logic circuitry, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute computer readable program instructions to perform aspects of the disclosure by personalizing the electronic circuitry with state information of the computer readable program instructions.

[0110] Aspects of the 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. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0111] The computer readable program instructions can 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 can 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

[0112] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0113] The flow diagrams and block diagrams in the drawings are illustrative of architectures, functions, and operations for possible implementations according to various examples of the present disclosure. In this regard, each block in the flow diagrams or block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logic functions. In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession can in fact be executed substantially concurrently or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0114] Other implementations are within the scope of the following claims and any other claims that may be granted.

[0115] While various examples have been described and illustrated herein, those of ordinary skill in the art will readily envision a variety of other means and / or structures for performing the functions and / or obtaining the results and / or advantages described herein, and each of such examples that is within its scope is intended to be encompassed by the instant examples. More generally, those skilled in the art will readily appreciate that all parameters, dimensions, materials, and configurations described herein are meant to be exemplary and that the actual parameters, dimensions, materials, and / or configurations will depend upon the specific application or applications for which the teachings is / are used. Those skilled in the art will recognize, or be able to ascertain using no more than routine experimentation, many equivalents to the specific examples described herein. It is, therefore, to be understood that the foregoing examples are presented by way of example only and that other examples can be developed and used without departing from the scope of the appended claims. Examples of the present disclosure are directed to each individual feature, system, article, material, kit, and / or method described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and / or methods, if such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent, is included within the scope of the present disclosure.

Claims

1. A source device comprising at least one processor to execute instructions configured to: transmitting, to at least one sink device, at least one data packet transmitted at a first time using a first frequency using a synchronization stream group comprising one or more synchronization streams; and transmit one or more supplemental data packets to the at least one sink device via the set of synchronized streams, the one or more supplemental data packets being shifted in time and / or at a second frequency different from the first frequency relative to the at least one data packet; wherein the one or more supplemental data packets are used to reconstruct and / or enhance at least a portion of the at least one data packet.

2. The source device of claim 1, wherein the at least one data packet is created, reconstructed, and / or enhanced from error correction coded supplemental data provided by the source device to the sink device.

3. The source device of claim 2, wherein the one or more supplemental data packets are error correction coded packets comprising the error correction coded supplemental data.

4. The source device of claim 2, wherein each of the at least one data packet comprises a header, wherein the header comprises error correction code information and / or packet identification information.

5. The source device of claim 2, wherein each of the one or more supplemental data packets comprises a header, wherein the header comprises error correction code information and / or packet identification information.

6. The source device of claim 2, wherein the error correction coded supplemental data is related to a first data packet transmitted within a first synchronization interval of one or more synchronization intervals and a second data packet transmitted during a second synchronization interval of the one or more synchronization intervals.

7. The source device of claim 2, wherein the error correction coded supplemental data is related to a first supplemental data packet transmitted within a first synchronization interval of one or more synchronization intervals and a second supplemental data packet transmitted during a second synchronization interval of the one or more synchronization intervals.

8. The source device of claim 2, wherein the error correction coded supplemental data is related to a first data packet transmitted within a first synchronization interval of one or more synchronization intervals and a second supplemental data packet transmitted during a second synchronization interval of the one or more synchronization intervals.

9. The source device of claim 1, wherein each of the at least one data packet comprises one or more audio frames of encoded audio data, and wherein the one or more supplemental data packets are used to reconstruct at least one of the one or more audio frames.

10. The source device of claim 1, wherein the at least one data packet, when received by the sink device, can be used to create a portion of audio to be played by the sink device.

11. The source device of claim 1, wherein one of the one or more synchronized streams is a broadcast synchronized stream or a connected synchronized stream.

12. The source device of claim 11, wherein the one of the one or more synchronized streams is a connected synchronized stream, and wherein the source device is further configured to: acknowledge successful recovery of one or more of the at least one data packet based on the one or more supplemental data packets.

13. A method for improving wireless communication, the method comprising: transmitting at least one data packet transmitted at a first time using a first frequency using a group of synchronized streams comprising one or more synchronized streams; and transmitting one or more supplemental data packets via the group of synchronized streams, the one or more supplemental data packets being time-shifted relative to the at least one data packet and / or at a second frequency different from the first frequency; wherein the one or more supplemental data packets are used to reconstruct and / or enhance at least a portion of the at least one data packet.

14. The method of claim 13, wherein the at least one data packet is created, reconstructed, and / or enhanced from error correction coded supplemental data or enhancement data.

15. The method of claim 14, wherein the one or more supplemental data packets comprise the error correction coded supplemental data or enhancement data.

16. The method of claim 14, wherein each of the at least one data packet comprises a header, wherein the header comprises supplemental data type information and / or packet identification information.

17. The method of claim 14, wherein each of the one or more supplemental data packets comprises a header, wherein the header comprises supplemental data type information and / or packet identification information.

18. The method of claim 13, wherein the at least one data packet, when received by an audio device, can be used to create a portion of audio to be played by the audio device.

19. The method of claim 13, wherein one of the one or more synchronized streams is a broadcast synchronized stream or a connected synchronized stream.

20. The method of claim 19, wherein the one of the one or more synchronized streams is a connected synchronized stream, and wherein the method further comprises: acknowledge successful recovery of the at least one data packet based on the one or more supplemental data packets.

Images