Robust Retransmission Topology with Error Correction

Abstract

Methods and systems for improving the robustness of wireless communications are provided. The methods and systems transmit data packets on one or more isochronous streams and transmit one or more supplemental data packets in the same time interval. The one or more supplemental data packets are used to recreate and / or extend at least a portion of one or more data packets of a plurality of data packets already transmitted. Alternatively, the one or more supplemental data packets are used to create and / or extend at least a portion of one or more data packets of a plurality of data packets received during a next isochronous interval. The methods and systems described herein enable increased robustness by enabling better retransmissions using correctly received packets.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Non-Provisional Patent Application No. 18 / 184,417, entitled "Robust Retransmission Topologies Using Error Correction," filed March 15, 2023, which is a continuation-in-part of U.S. Non-Provisional Patent Application No. 17 / 366,613, entitled "Robust Retransmission Topologies Using Error Correction," filed July 2, 2021, the disclosure of which is incorporated by reference in its entirety. [Background technology]

[0002] Aspects and implementations of the present disclosure are generally directed to systems and methods for transmitting and receiving wireless data streams, for example, for transmitting and receiving wireless data streams between wireless devices.

[0003] Wireless systems, such as wireless multi-speaker systems, wireless headphones or headsets, or any system including a broadcasting device and a receiving device, typically transmit and receive streams of data packets within a wireless connection between the devices of the system. The wireless devices may experience losses, such as packet loss, failed transmissions, and failed retransmissions, over the wireless connection when the connection is at the limit of its link budget or if interference is present. For example, as wireless devices in the system move away from each other and the distance between the source and sink devices increases, packet loss may increase with the distance between the devices. Similarly, situations in which devices in the system experience other forms of environmental interference, such as the presence of multiple other wireless communications in the vicinity or the presence of objects (e.g., a user's body or a wall) that can reduce signal strength between devices, can strain the link budget and ultimately degrade quality. Summary of the Invention

[0004] The present disclosure provides methods and systems for improving the robustness of wireless communications. The provided methods and systems transmit a data packet on a first isochronous stream and transmit one or more supplemental data packets in the same time interval. The one or more supplemental data packets are used to recreate and / or extend at least a portion of one or more data packets of a plurality of data packets already transmitted. Alternatively, the one or more supplemental data packets are used to create and / or extend at least a portion of one or more data packets of a plurality of data packets received during a next isochronous interval. The methods and systems described herein enable increased robustness by enabling better retransmissions using correctly received packets.

[0005] The present disclosure includes broadcasting audio data in a first isochronous stream while also broadcasting a separate data stream that includes an error correction code for the audio stream. With the configurations described herein, each sink device can utilize correctly received packets from the audio stream in combination with the error correction code to calculate missing audio data. Alternatively, the separate data stream can include additional audio data to enhance the quality of already received data. For example, the sink device can utilize correctly received packets or at least a portion of correctly received packets (e.g., one or more frames of audio data) to calculate missing portions of packets or entire missing packets.

[0006] The present systems and methods may utilize hard or soft block codes, and the error correction codes may be calculated based on discrete left and right channel audio streams or multi-channel audio streams. Furthermore, the error correction codes may be transmitted prior to transmission of one or more packets used to calculate a given error correction code packet, or may be transmitted significantly after transmission of such packets (e.g., pre-transmission or post-transmission). Furthermore, the concepts described herein may be extended to scenarios other than broadcast, such as when using connected isochronous streams.

[0007] In general, in one aspect, a source device is provided, the source device including at least one processor that executes instructions configured to transmit at least one data packet, the data packet being transmitted at a first time using a first frequency, to at least one sink device using an isochronous stream group including one or more isochronous streams.

[0008] The source device is further configured to transmit one or more supplemental data packets over the isochronous 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 to the at least one sink device, the one or more supplemental data packets being used to recreate and / or extend at least a portion of the at least one data packet.

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

[0010] According to one example, one or more of the supplemental data packets are error correction coded packets that include error correction coded supplemental data.

[0011] According to one example, each of the at least one data packet includes a header, the header including error correction code information and / or packet identification information.

[0012] According to one example, each of the one or more supplemental data packets includes a header, the header including error correction code information and / or packet identification information.

[0013] According to one example, the error correction coded supplemental data is associated with a first data packet transmitted within a first isochronous interval of the one or more isochronous intervals and a second data packet transmitted during a second isochronous interval of the one or more isochronous intervals.

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

[0015] According to one example, the error correction code is associated with a first data packet transmitted within a first isochronous interval of the one or more isochronous intervals and a second supplemental data packet transmitted during a second isochronous interval of the one or more isochronous intervals.

[0016] According to one example, each of the at least one data packet includes one or more audio frames of encoded audio data, and the one or more supplemental data packets are used to recreate at least one of the one or more audio frames.

[0017] According to one example, upon receipt by a sink device, the at least one data packet may be used to create a portion of audio to be played by the sink device.

[0018] According to one example, one of the one or more isochronous streams is a broadcast isochronous stream or a connected isochronous stream.

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

[0020] In general, in another aspect, a method for improving wireless communications is provided that includes transmitting at least one data packet using an isochronous stream group including one or more isochronous streams, the data packet being transmitted at a first time using a first frequency.

[0021] The method further includes transmitting one or more supplemental data packets over the isochronous 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 being used to recreate and / or extend at least a portion of the at least one data packet.

[0022] According to one example, at least one data packet is created, recreated, and / or extended in accordance with error correction coded supplemental or extension data.

[0023] According to one example, the method further includes one or more supplemental data packets including error correction coded supplemental or extended data.

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

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

[0026] According to one example, upon receipt by an audio device, the at least one data packet may be used to create a portion of audio to be played by the audio device.

[0027] According to one example, one of the one or more isochronous streams is a broadcast isochronous stream or a connected isochronous stream.

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

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

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

[0031] [Figure 1] 1 is a schematic diagram of a system according to the present disclosure. [Figure 2] FIG. 2 is a schematic diagram of components of a source device according to the present disclosure. [Figure 3] FIG. 2 is a schematic diagram of components of a sink device according to the present disclosure. [Figure 4A] FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 4B]FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 5] FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 6] FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 7] FIG. 1 is a schematic diagram of a logical stack including a schematic interface according to the present disclosure. [Figure 8] 1 illustrates steps of a method according to the present disclosure. [Figure 9A] FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 9B] FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 10] FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 11A] FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 11B] FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 12] FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 13] FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 14] FIG. 1 is a schematic diagram of a wireless broadcast topology according to the present disclosure. [Figure 15] 1 illustrates steps of a method according to the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0032] The present disclosure provides methods and systems for improving the robustness of wireless communications. The provided methods and systems transmit a data packet on a first isochronous stream and transmit one or more supplemental data packets in the same time interval. The one or more supplemental data packets are used to recreate and / or extend at least a portion of one or more data packets of a plurality of data packets already transmitted. Alternatively, the one or more supplemental data packets are used to create and / or extend at least a portion of one or more data packets of a plurality of data packets received during a next isochronous interval. The methods and systems described herein enable improved robustness by enabling better retransmissions using correctly received packets, and the methods described herein work with any Bluetooth broadcaster sink without modification.

[0033] As used in this disclosure, the term "wearable audio device," in addition to including its ordinary meaning or meaning known to those skilled in the art, is intended to mean a device that fits around, on, in, or near the ear (including open-ear audio devices worn on the user's head or shoulders) and radiates acoustic energy into or toward the ear. Wearable audio devices may also be referred to as headphones, earphones, earpieces, headsets, earbuds, or sports headphones and may be wired or wireless. Wearable audio devices include an acoustic driver that converts audio signals into acoustic energy. The acoustic driver may be housed in ear cups. While some of the following figures and descriptions 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 may also be a single, standalone unit with only one ear cup. Each earcup of a wearable audio device can be mechanically connected to another earcup or headphone, for example, by a headband and / or by leads that carry audio signals to acoustic transducers in the earcups or headphones. A wearable audio device can include components that wirelessly receive audio signals. A wearable audio device can include components of an active noise reduction (ANR) system. A wearable audio device can also include other features, such as a microphone, so that the device can function as a headset. While FIG. 1 shows examples of an in-ear headphone form factor, an eyeglass form factor, and an over-ear headset, in other examples, the wearable audio device can be an on-ear, around-ear, behind-ear, or near-ear headset.In some examples, the wearable audio device may be an open-ear device that includes an acoustic driver that radiates acoustic energy toward the ear, while opening the ear to the ear's environment and surroundings.

[0034] The term "connected isochronous stream," as used in this disclosure, includes its ordinary meaning or meaning known to those skilled in the art, and is intended to refer to an isochronous data stream that utilizes a pre-established point-to-point communication link over LE Audio, for example, between a source device (also known as a central or master device) and one or more audio devices (also known as peripheral or slave device(s)). In other words, a connected isochronous stream can provide an isochronous audio stream that utilizes at least one established reliable communication channel and / or at least one confirmed communication channel between the source device and any respective audio devices.

[0035] The term "broadcast isochronous stream" as used in this application is intended to include its ordinary meaning or that known to those skilled in the art, and also to refer to an isochronous data stream in which no pre-established communication link needs to be established between a source device transmitting the data and an audio device receiving the data, and no acknowledgements or negative acknowledgements need to be sent or received.

[0036] The following description should be read with reference to FIGS. 1-15. FIG. 1 is a schematic diagram of components of a system 100 consistent with the present disclosure. In some examples, system 100 includes a source device 102 and at least one sink device 104. Additionally, in some examples, such as that shown in FIG. 1, system 100 includes multiple sink devices 104A-104C (collectively referred to as "sink device 104" or "multiple sink devices 104"). Source device 102 is intended to be a device capable of establishing a wireless connection, e.g., wireless connection 132 (described below), with at least one sink device 104. While illustrated as a smartphone, it should be understood that source device 102 can be selected from at least one of a tablet, a smart hub, a media hub, a stereo hub, a sound bar, a headphone case, or any device capable of transmitting or broadcasting wireless data (described below) to at least one sink device 104. Furthermore, while illustrated as a pair of truly wireless earbuds 104A, eyeglasses 104B, and over-ear headset 104C, it should be understood that sink devices 104 can be selected from at least one of a smartphone, a tablet, a smart hub, a media hub, a stereo hub, a soundbar, a headphone case, or any device capable of receiving wireless data (described below) from source device 102. In some examples, each sink device 104 is intended to be a device capable of rendering audible acoustic energy, e.g., audio data, based on the wireless data received from source device 102. In some examples, as described below, source device 102 is configured to transmit one or more supplemental packets 140 (described below) to each sink device 104, which may include error correction codes and / or additional codes for restoring and / or enhancing the audio data prior to rendering.

[0037] 2, source device 102 includes a source controller 106 including a source processor 108 and a source memory 110 configured to execute and store, respectively, a plurality of non-transitory computer-readable source instructions 112 for performing various functions of source device 102 described herein. Source controller 106 also includes a source communication module 114 configured to transmit and / or receive wireless data, e.g., at least one of a plurality of wireless data streams described below, e.g., data associated with a plurality of wireless connections 132. To that end, source communication module 114 may include at least one radio or antenna, e.g., source radio 116, capable of transmitting and receiving wireless data. In some examples, source communication module 114 may include, in addition to the at least one radio (e.g., source radio 116), some form of automated gain control (AGC), a modulator and / or demodulator, and potentially a discrete processor for bit processing, electrically connected to source processor 108 and source memory 110 to facilitate the transmission and / or reception of wireless data.

[0038] 3 , each sink device 104 may include a sink controller 118 including a sink processor 120 and a sink memory 122 configured to execute and store, respectively, a plurality of non-transitory computer-readable sink instructions 124 to perform various functions of each sink device 104 as described herein. Each sink controller 118 also includes a sink communication module 126 configured to transmit and / or receive wireless data, e.g., at least one of a plurality of wireless data streams described below, e.g., data associated with a wireless connection 132. To that end, each sink communication module 126 may include at least one radio or antenna, e.g., a sink radio 128, capable of transmitting and receiving wireless data. In some examples, the sink communication module 126 may include, in addition to the at least one radio (e.g., the sink radio 128), some form of automated gain control (AGC), a modulator and / or demodulator, and potentially a discrete processor for bit processing, electrically connected to the sink processor 120 and the sink memory 122 to facilitate the transmission and / or reception of wireless data. 3, it should be appreciated that each sink device 104 may also include at least one speaker, i.e., sink speaker 130, e.g., a loudspeaker or acoustic transducer, electrically connected to sink processor 120 and sink memory 122 and configured to electromechanically convert electrical signals into audible acoustic energy, e.g., audio reproduction, in an environment surrounding each sink device. In some examples, the electrical signals and audible acoustic energy are associated with data contained on wireless connection 132 (described below). Additionally, although not shown, each sink controller 118 may include one or more clocks or timing circuits configured to keep independent time during operation of system 100.

[0039] Each device in 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 referred to as "wireless connections 132") between the source device 102 and each sink device 104. Each wireless connection 132 can be used to transmit and / or receive wireless data via one or more wireless data streams between the source device 102 and each sink device 104. In some examples, each data stream is an isochronous data stream 136A-136C (collectively referred to as "isochronous data stream 136" or "isochronous stream 136"), e.g., a connected isochronous stream using the LE Audio standard. In other examples, as described below, the isochronous data stream 136 is a broadcast isochronous stream, e.g., the source device 102 is configured to broadcast one or more isochronous streams 136 to be received by one or more sink devices 104. For example, source device 102 may 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 understood that the streams established over each wireless connection 132 may use a variety of wireless data protocols, standards, or transmission methods, such as 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 send, receive, or otherwise transmit audio data, e.g., data used by sink device 104 to generate audible acoustic energy in the form of audio playback. However, it should be understood that these protocols are not limited to the transmission of audio data and include other types of data.

[0040] As shown in FIGS. 4A-6 , each isochronous stream 136 includes one or more packets from a plurality of data packets 138A-138D (collectively referred to as “data packets 138”) and / or one or more packets from a plurality of supplemental data packets 140A-140H (collectively referred to as “supplemental packets 140”). Data packets 138 may include data transmitted by source device 102 to one or more sink devices 104 as described herein and used by one or more sink devices 104 to generate or render audible acoustic energy, e.g., audio playback. In other words, data packets 138 may include audio data and / or one or more frames of audio data that may be used to generate audible acoustic energy using sink speaker 130 of each sink device 104, as described above. To that end, data packets 138 may be framed packets or unframed packets. For example, framed packets may include a header and a payload, while unframed packets do not include a packet header. In some examples, the header can include fields for segmentation header data and time offset data, and the payload includes the encoded wireless data to be transferred from one device to the other. For 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 an unframed configuration, during initial negotiation of the wireless connection 132, the source controller 106 and each sink controller 118 can negotiate and agree on parameters that would normally be specified in the header of each packet, allowing each device to know what data type and what parameters will be used when sending and receiving data, making the inclusion of a header redundant and unnecessary.

[0041] In addition to being framed or unframed, each supplemental packet 140 may include data intended to correct, recover, or enhance data transmitted in one or more of the plurality of data packets 138. For example, as described in more detail below, each supplemental packet 140 may include an error correction code intended to assist each sink device 104 in recovering or reconstructing at least a portion of one or more data packets 138 that were not successfully received from one or more isochronous streams 136. Alternatively or additionally, each supplemental data packet may include additional data associated with one or more data packets 138 that were successfully received from one or more isochronous streams 136, and that each sink device 104 may use to enhance the data that was already received. For example, if data packet 138 contained audio data or frames of audio data encoded at a lower bit rate or lower quality (e.g., 72 kbps), supplemental packet 140 could provide additional audio data (e.g., 72 kbps) that effectively increases the bit rate and therefore the quality of the decoded audio for each frame (e.g., to 144 kbps). It should be understood that supplemental packet 140 is encrypted so that only authorized sink device 104 can access the error correction or error enhancement capabilities provided by supplemental packet 140.

[0042] As described below, in some examples, the supplemental packet 140 includes an error correction code. In some examples, the error correction code can be selected from any hard-decision block code, such as at least one of Reed-Solomon coding, multidimensional parity, or Hamming code. It should be understood that convolutional codes can also be used, but this leads to soft decisions, which can improve error correction performance at the expense of artifacts, e.g., audio artifacts, when soft decisions lead to inaccurate results. Furthermore, for the selected block code, the parity type used can be Redundant Array of Independent Disks (RAID) 5 and RAID 6, as these do not require significant memory and processing on the decoder side, e.g., on the sink controller 118 side.

[0043] 4A-6, which illustrate one exemplary configuration, data packets 138 and supplemental packets 140 are transmitted via one or more isochronous streams, e.g., streams that transmit packets during predetermined isochronous time intervals along time T, e.g., isochronous intervals 142A-142D (collectively referred to as "isochronous intervals 142"). Each isochronous interval 142 may include multiple isochronous events and isochronous sub-events, which divide and subdivide each Bluetooth isochronous interval based on the initial negotiation of a given wireless connection. Furthermore, data packets 138 and supplemental packets 140 may be transmitted within the same isochronous stream 136 or within different isochronous streams 136, e.g., over different frequencies or channels. 4A , data packets 138 are transmitted on a first isochronous stream 136A using a first frequency 144, and supplemental data packets 140 are transmitted on a second isochronous stream 136B using a second frequency 146 that is different from the first frequency 144. As shown in FIGS. 4A-4B , the supplemental packets 140 transmitted on the second isochronous stream 136B are shifted in time relative to the data packets 138 transmitted on the first isochronous stream 136A. It should be appreciated that this time shifting, such that there is no overlap between packets of each respective stream, allows both the first isochronous stream 136A and the second isochronous stream 136B to be generated by the same radio, e.g., the source radio 116.

[0044] 4A , which illustrates an example of system 100, source device 102 is configured to transmit a plurality of data packets 138A-138D via a first broadcast isochronous stream 136A 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 isochronous stream 136B at a second frequency 146, different from first frequency 144. Specifically, as illustrated, within a first isochronous interval 142A, source device 102 is configured to transmit a first data packet 138A (schematically shown in FIG. 4A as a shaded box with the number "1" displayed) and one or more retransmission packets (schematically shown in FIG. 4A as open boxes with the number "1" displayed) that include an identical payload to first data packet 138A. Following transmission of both first data packet 138A and the retransmission packet associated with first data packet 138A, within first broadcast isochronous stream 136A, source device 102 is also configured to transmit one or more supplemental packets 140, namely, supplemental packets 140A and 140B, via second broadcast isochronous stream 136B. As described above, supplemental packets 140A and 140B may each include an error correction code calculated based on one or more data packets 138, which is used by one or more sink devices 104 to recover or recreate data packet 138. Alternatively, as described above, supplemental packets 140A and 140B may include additional data, such as additional audio data or audio frames, used to extend or add to the data successfully captured in first data packet 138A.Further, similar to the packets transmitted during the first isochronous interval 142A, source device 102 is configured to transmit a second data packet 138B, a third data packet 138C, and a fourth data packet 138D (all shown in FIG. 4A as shaded boxes numbered 2 through 4, respectively) during the second isochronous interval 142B, the third isochronous interval 142C, and the fourth isochronous interval 142D, respectively, each of which is followed by one or more retransmitted packets (shown in FIG. 4A as open boxes numbered 2 through 4, respectively). Also within second isochronous stream 136B, during each isochronous interval 142, source device 102 is configured to transmit one or more supplemental packets 140, e.g., supplemental packets 140C and 140D during second isochronous interval 142B, supplemental packets 140E and 140F during third isochronous interval 142C, and supplemental packets 140G and 140H during fourth isochronous interval 142D. Supplemental packets 140A-140H are shown as cross-hatched boxes. It should be understood that supplemental packets 140A-140H are also shifted in time relative to data packet 138 and its respective retransmission packets so that there is no overlap between the data packet and the supplemental packet. Thus, a single radio, i.e., source radio 116, can broadcast data packet 138, each retransmission packet associated with data packet 138, and supplemental packet 140.

[0045] 4B illustrates an example of a system 100 that includes recovering missing data packets using supplemental packets 140 having error correction codes. As shown, each supplemental packet 140 may include an error correction code calculated using data from one or more data packets 138A-138D. For example, as shown, first data packet 138A and second data packet 138B are successfully received, but third data packet 138C is lost (indicated in FIG. 4B by a solid "X" over third data packet 138C and its respective retransmission packet). Additionally, supplemental packets 140A-140D are transmitted over second broadcast isochronous stream 136B. Supplemental packet 140C can include an error correction code calculated using data packets 138A-138B, such that the error correction code of supplemental data packet 140C is used to calculate and recover a missing packet (e.g., 138C) and pass the data from the missing packet to sink device 104 for use in decoding first isochronous stream 136A. In other words, the error correction code in supplemental packet 140C can reconstruct missing or lost data packet 140C using data from first data packet 138A, second data packet 138B, and supplemental packet 138C (indicated by arrows in FIG. 4B ). It should be understood that the error correction code in a given supplemental packet 140C can be calculated using one or more data packets 138A. For example, although not shown, supplemental packets 140A and / or 140B can be calculated based on two data packets, i.e., first data packet 138A and second data packet 138B. Thus, if at least one of these data packets and one of the supplemental packets is successfully received, the missing data packet can be recovered. It should further be appreciated that within second isochronous stream 136B, multiple supplemental packets 140 are transmitted within a single isochronous interval, e.g., supplemental packets 140A and 140B are transmitted within first isochronous interval 142A.In this example, supplemental packet 140A may include error correction codes or additional data used to extend one or more packets 138, and supplemental packet 140B is a retransmission of supplemental packet 140A, i.e., supplemental packet 140B has the same payload as supplemental packet 140A.

[0046] 5, the plurality of data packets 138 includes 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 shown, the first plurality of packets 148 are transmitted via a first isochronous stream, i.e., first broadcast isochronous stream 136A, and the second plurality of data packets 150 are transmitted via a second isochronous stream, i.e., second broadcast isochronous stream 136B. It should be understood that the first broadcast isochronous stream 136A is transmitted using a first frequency 144, and the second broadcast isochronous stream 136B is transmitted using a second frequency 146 that is different from the first frequency 144. Additionally, the second plurality of packets 150 are time-shifted relative to the first plurality of packets 148 such that there is no time overlap in the airtime used to transmit each of the respective plurality of packets. Thus, a single radio, e.g., source radio 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 frames of audio data associated with a left channel audio stream, and the second plurality of data packets 150 includes audio data or frames of audio data associated with a right channel audio stream. In other words, for stereo applications, the left channel audio is transmitted over a separate channel or frequency, and the right channel audio is transmitted over another separate channel or frequency. Similar to FIGS. 4A-4B, the first plurality of data packets 148A-148D and the second plurality of data packets 150A-150D are shown as shaded boxes labeled with the numbers 1-4, respectively. Additionally, retransmitted packets associated with each of these packets are shown as white boxes labeled with the corresponding numbers 1-4. Additionally, supplemental data packets 140A-140H are shown as boxes with cross-hatching.

[0047] 4A-4B, supplemental data packets 140 are transmitted over yet another separate channel or frequency. For example, a third isochronous stream, i.e., third broadcast isochronous stream 136C, is used to transmit supplemental data packets 140 over a third frequency 152, which is different from first frequency 144 and second frequency 146. Furthermore, supplemental packets 140 are offset or shifted in time relative to both first plurality of packets 148 and second plurality of packets 150. By shifting first plurality of packets 148, second plurality of packets 150, and supplemental packets 140 in time relative to one another so that none of these packets are transmitted simultaneously, a single radio, e.g., source radio 116, can be used to transmit all three isochronous streams 136A-136C.

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

[0049] 6, a supplemental packet may be transmitted prior to or after one or more corresponding data packets. For example, as shown, supplemental packet 140A (shown as a cross-hatched rectangle with the letter "R" displayed) may include an error correction code calculated based on data from first packet 138A and second packet 138B. Because supplemental packet 140A is transmitted temporally between first packet 138A and second packet 138B, supplemental packet 140A is said to be pre-transmitted, i.e., transmitted temporally before at least one packet for which its error correction code was calculated. Thus, the first supplemental packet 140 transmitted within each isochronous interval 142 is a pre-transmitted packet having an error correction code calculated based on the immediately preceding and immediately following packets in first isochronous stream 136A. For example, supplemental packet 140C is calculated based on data packets 138B and 138C, and supplemental packet 140E is calculated based on data packets 140C and 140D. It should be understood that the illustrated supplemental packets each include letters displayed on a representative rectangle indicating progression through a sequential sequence of packets having an alphabetical order. For example, supplemental packets 140A, 140C, and 140E include sequential payloads labeled R, S, and T to indicate that each of these supplemental packets is in logical alphabetical order relative to one another. To increase the robustness of the systems described herein, the second supplemental packet 140 transmitted within each isochronous interval 142 is a post-transmission or post-retransmission packet, in that each post-retransmission packet is calculated based on one or more packets transmitted significantly earlier than the post-retransmission packet. For example, as shown, the payload associated with the retransmitted packet is shifted in time so that the retransmitted payload is one or more full isochronous intervals in the future relative to the data packet used to calculate the error correction code it carries.6, each second supplemental packet 140 transmitted within each isochronous interval 142 is calculated based on a data packet transmitted at least two isochronous intervals prior to the transmission of the corresponding supplemental packet 140. Specifically, as shown, supplemental data packet 140F is labeled with an "R," indicating that the payload within that supplemental packet is identical to the payload within supplemental packet 140A, and that the error correction codes within these packets are calculated based on the data within packets 138A and 138B. Thus, subsequent transmission of this payload occurs two isochronous intervals after the data packet used to calculate the error code contained therein.

[0050] This exemplary pre-transmission and post-transmission 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. For example, if a given connection experiences interference within a particular isochronous interval, both data packet 138 and supplemental packet 140, which could aid in the recovery of those data packets, may be lost. By providing several isochronous intervals in the future for post-transmission, the likelihood that the interference that caused the initial packet loss will be resolved and, given a sufficiently large buffer, all of the initially lost packets will be recoverable increases. For example, as shown, if interference or other factors cause data packet 138A and supplemental packets 140A and 140B to be lost or missing, post-transmission packet 140F, containing the same payload as lost packet 140A, is sent at a different time in the future when the interference is likely to have been resolved, and the post-transmission supplemental data is used together with packet 138B to recover lost packet 138A.

[0051] In some examples, packet recovery using the methods described herein is iterative. For example, referring to FIG. 6, if packets 138A, 138B, and 140A are lost due to interference or other environmental factors, the systems and methods described herein may begin with recovering packet 138B by using data from received packet 138C and received supplemental packet 140C. Once packet 138B is recovered, system 100 may use recovered packet 138B and subsequently transmitted packet 140F to recover first packet 138A.

[0052] As mentioned above, it should be understood that the broadcast streams described in this 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 obtain the encoded data transmitted via the broadcast isochronous stream associated with the supplemental packet 140 and encrypt each packet before broadcasting it. Each key of the key pair used to encrypt the data can be transmitted to authorized sink devices 104 before initiating the stream so that the authorized device's sink controller 118 can decrypt the decrypted data provided in the supplemental stream. In this manner, for unauthorized users or devices, the data associated with the first broadcast isochronous stream 136A is still available, but the increased robustness created by the use of error correction codes and / or the increased quality of transmitting the additional audio data in the supplemental packet 140 is not available. In other words, in this example, the broadcast stream data associated with the data packet 138 is not encrypted, but the broadcast stream data associated with the supplemental data packet 140 is encrypted. In another example, both the broadcast stream data associated with the data packet 138 and the broadcast stream data associated with the supplemental data packet 140 are encrypted. For example, the broadcast stream associated with data packet 138 utilizes a first encryption key pair KP1 (schematically shown in Figures 2 and 3), while the broadcast stream associated with supplemental packet 140 utilizes a second encryption key pair KP2 that is different from the first encryption key pair KP1.In this way, to an unauthorized user or device, the data associated with the first broadcast isochronous stream 136A is available so long as the user or device has access to the respective keys of the first encryption key pair KP1 used to decrypt the data associated with the data packet 138, but the increased robustness generated by the use of error correction codes and / or the increased quality of transmitting the additional audio data in the supplemental data packet 140 is only available if the user or device has access to the respective keys of the second encryption key pair KP2 used to decrypt the data associated with the supplemental data packet 140.

[0053] Furthermore, although shown as separate streams, it should be understood that the data packets 138 and supplemental packets 140 described herein are transmitted within the same isochronous stream. Referring to FIG. 4A , for example, within first isochronous interval 142A, packet 138A and its respective retransmitted packets are transmitted. Immediately following the last retransmitted packet, within first isochronous interval 142A, system 100 may transmit supplemental packets 140A and 140B. Supplemental packets 140A and 140B are shifted in time relative to packet 138A and its respective retransmitted packets, thereby allowing all packets to be transmitted using a single radio, e.g., source radio 116. It should be understood that in this example, a packet header would likely be required to instruct sink controller 118 of each sink device 104 as to the type of data being transmitted in each packet of first isochronous stream 136A. Furthermore, examples provided herein describe using data contained in one or more supplemental packets transmitted via a second broadcast isochronous stream to recover, recreate, or enhance data transmitted via a first broadcast isochronous stream. It should be understood that each packet 138 (or packets 148 and 150) may contain multiple frames of audio data. Thus, the error correction code and / or additional data provided in supplemental packet 140 is calculated based on or applied to individual frames of data, rather than each packet as a whole. In other words, one or more supplemental data packets 140 are used to recover and / or enhance at least a portion (one or more frames) of one or more data packets 138 (or packets 148 and 150) of the plurality of data packets.

[0054] While the above description provides multiple broadcast isochronous streams, it should be understood that similar concepts can be employed on non-broadcast systems, for example, using connected isochronous streams between the source device 102 and each sink device 104. When applied in a non-broadcast scenario, e.g., in a connected isochronous stream, the system may include an additional interface to the source controller 106 to indicate packets that need to be acknowledged by the source controller 106 but do not take time to receive. In a non-broadcast example, the system described herein includes acknowledging successful recovery or reproduction of one or more of the plurality of data packets 138. Thus, the described system allows the sink device 104 to reproduce a packet that it had difficulty receiving and sends an acknowledgment of successful recovery of that packet so that the system can continue transmitting the next packet that the sink device needs.

[0055] FIG. 7 illustrates a simplified implementation of the systems and methods described herein. For example, an advantage of the configuration disclosed herein is that it does not require any modifications to the Bluetooth radio or controller currently used by source and sink devices for audio transmission. For example, the implementation described herein can be realized by creating an interface between an Isochronous Adaptation Layer (ISOAL) and the conventional LC3 encoder / decoder and I2S serial bus interface of typical audio source and sink devices. This interface is represented by the rectangle labeled "hook" in FIG. 7. Furthermore, when packets are pre-computed, the system can utilize this interface to indicate to the source controller 106 which packets of the first isochronous stream 136A to pre-pick. The same interface is also needed when error correction codes are transmitted post-computation and are not needed.

[0056] 8 illustrates steps of a preferred method 200 according to the present disclosure. The method 200 may include, for example, transmitting an isochronous stream 136A including a plurality of data packets 138 (or 148 and 150) transmitted within a first isochronous interval 142A or using a first frequency 144 (step 202), transmitting one or more supplemental data packets 140 within the first isochronous interval 142A at a second frequency 146 that is shifted in time relative to the plurality of data packets 138 (or 148 and 150) or that is different from the first frequency 144 (step 204), and transmitting one or more supplemental data packets 140. The foot data packet 140 is used to recreate and / or extend at least a portion of one or more data packets 138 of the plurality of data packets 138 received during the first isochronous interval 142A, or the one or more supplemental data packets 140 are used to generate and / or extend at least a portion of one or more data packets of the plurality of data packets 138 received during the first isochronous interval 142A or during a second isochronous interval 142B after the first isochronous interval 142A. Optionally, the method 200 also includes confirming successful reception of the one or more supplemental data packets 140 (step 206).

[0057] 9A shows a variation of the wireless topology shown in FIG. 4A in which supplemental data packets 140A-H are transmitted in the same first isochronous stream 136 as data packets 138A-D, rather than in a separate second isochronous stream. Each of data packets 138A-D may contain audio data or audio frames for playback by sink device 104. Additionally, each of supplemental data packets 140A-H is transmitted in place of one of the retransmitted packets (shown as white squares 1-4 in FIG. 4A ). For example, supplemental packets 140A-H may be transmitted in a slot that would have been a retransmission slot for a typical isochronous stream data packet. Because the topology of FIG. 4A removes an entire stream from system 100 while transmitting two fewer packets per isochronous interval 142A-D, replacing transmitted packets with supplemental data packets 140A-H may improve overall system efficiency. As with the previous example, various combinations of data packets 138A-D and supplemental data packets 140A-H may be used to create, recreate, or recover data packets 138A-D lost during transmission from source device 102 to sink device 104. Some reconstruction schemes may require a combination of both data packets 138 and supplemental data packets 140 to recreate data packets 138, while other reconstruction schemes may require only data packets 138 or supplemental data packets 140, but not both types of packets 138, 140. In some examples, supplemental data packets 140A-H may also be used to extend data packets 138A-D that were successfully received by sink device 104. Furthermore, if isochronous stream 136 is a connected isochronous stream, sink device 104 may provide an acknowledgment to source device 102 when one of data packets 138A-D is successfully created, recreated, or recovered using error correction.

[0058] The technique of transmitting supplemental data packets in retransmission slots allows more data to be transmitted more reliably in a given time period, thereby enabling more robust transmission and / or increased data bandwidth. Thus, when increased data bandwidth is not required, additional supplemental data packets can be sent to increase the robustness of data transmission, particularly in environments with difficult RF conditions (Wi-Fi or other RF interference, physical obstructions, etc.). In other configurations, when increased data bandwidth is desired, such as to increase the number of transmitted audio channels, the technique may include sending fewer supplemental data packets per data packet. This can allow, for example, to send 5 to 12 channels of audio data to enable a spatialized audio experience using a single audio device (e.g., a set of headphones or earphones) or multiple audio devices (e.g., a set of surround sound wireless speakers).

[0059] In the example of FIG. 9A , source device 102 is configured to transmit multiple data packets 138A-D via isochronous stream 136. Isochronous stream 136 is divided into a series of isochronous intervals 142A-D. The series of isochronous intervals 142A-D (and the data within isochronous intervals 142A-D) may be considered a data block 154. Each isochronous interval 142A-D includes a data packet 138A-D and two supplemental data packets 140A-H. In the example of FIG. 9A , the two supplemental data packets 140A-H of an isochronous interval 142A-D are transmitted immediately after data packet 138A-D. While the example of FIG. 9A shows a data packet 138 transmitted before a corresponding supplemental data packet 140, in other examples, a supplemental data packet 140 may be transmitted before a data packet 138. Furthermore, although the example of FIG. 9A shows each isochronous interval 142 as including at least one data packet 138 and at least one supplemental packet, in other examples, some isochronous intervals 142 or isochronous events may include only one of a data packet 138 or a supplemental data packet 140, but not both.

[0060] In some examples, each data packet 138A-D and / or each supplemental data packet 140A-H may include header information. The header information may include various information, such as data regarding an error correction code and / or data identifying the data packet 138A-D or supplemental data packet 140A-H. The error correction code information may identify the type of error correction implemented by the system 100, such as a Reed-Solomon code, a multidimensional parity code, or a Hamming code. By incorporating the error correction code information into the headers of the data packets 138A-D and / or supplemental data packets 140A-H, the source device may dynamically change the type of error correction used while receiving the isochronous stream 136. The packet identification information may inform the source device 102 regarding the order of the data packets 138A-D of the isochronous stream. In a further example, the error correction code information may be transmitted by the source device 102 prior to the first isochronous interval 142A. In these examples, the error correction code information may be transmitted as part of the isochronous stream 136 shown in FIG. 9A or as part of a separate wireless transmission.

[0061] 9B illustrates a variation of the wireless topology shown in FIG. 4B in which sink device 104 fails to receive third data packet 138C of isochronous stream 136. Rather than relying on retransmitted data packets, the topology of FIG. 9B recreates the third data packet using first data packet 138A received during first isochronous interval 142A, second data packet 138B received during second isochronous interval 142B, and third supplemental data packet 140C, also received during second isochronous interval 142C. In this example, sink device 104 was previously provided with error correction codes indicating what combination and amount of data packets 138A-D and supplemental data packets 140A-H is needed to recreate data packets 138A-D lost during transmission. Error correction codes identifying the type of error correction being implemented may be embedded within the headers of supplemental data packets 140A-H. In this example, to reconstruct lost data packet 138C, the error correction code may require the two data packets 138A and 138B that immediately precede lost data packet 138C. The headers of data packets 138A-D may also include identifying information to aid in this reconstruction. In some examples, each of data packets 138 may correspond to one channel of a multi-channel audio stream. For example, if three audio channels are required, a first portion of data packet 138 and supplemental data packet 140 may correspond to a first audio channel, a second portion of data packet 138 and supplemental data packet 140 may correspond to a second audio channel, and a third portion of data packet 138 and supplemental data packet 140 may correspond to a third audio channel.

[0062] 10 illustrates a variation of the wireless topology shown in FIG. 6, in which one or more of supplemental packets 140A-F are transmitted before their corresponding data packets 138A-D. Furthermore, similar to FIGS. 9A-9B, data packets 138A-D and supplemental data packets 140A-F are both transmitted via the same isochronous stream 136. For example, as illustrated, supplemental packet 140A (shown as a cross-hatched rectangle displaying the letter "R") may be generated based on data from 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 said to be a pre-transmitted packet, i.e., transmitted in time before at least one packet from which its error correction data was calculated. Thus, the first supplemental packets 140A-F transmitted in each isochronous interval 142A-D may be pre-transmitted packets having error correction data generated based on the immediately preceding and immediately following transmitted packets in the first isochronous stream 136. This exemplary pre-transmit and post-transmit 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.

[0063] 10 further illustrates a duplication error correction scheme that can reconstruct data packet 138 using either pre- or post-transmitted supplemental data packets. For example, in FIG. 10, second data packet 138B can be reconstructed using either first and / or second (“R” and “P”) supplemental data packets 140A, B from first isochronous interval 142A (transmitted before second data packet 138B) or third and / or fourth (“S” and “Q”) supplemental data packets 140C, D from second isochronous interval 142B (transmitted after second data packet 138B). However, in applications where efficiency is a primary concern, non-duplication error correction is preferred. Latency is improved by transmitting data packet 138 before transmitting supplemental data packet 140 used to reconstruct or enhance data packet 138.

[0064] 11A and 11B illustrate the benefits of using supplemental data packets 140 to reconstruct data packets 138 lost during transmission. In particular, FIGS. 11A and 11B illustrate a non-limiting example in which data packets 138 and supplemental data packets 140 are received by sink device 104 during eight isochronous intervals 142, and the resulting data packets 138 are provided for playback. Other examples may use any practical number of isochronous intervals 142. FIG. 11A illustrates a typical packet transmission scheme for a data block 154 of eight data packets 138, with each data packet 138 transmitted three times during the isochronous intervals 142. In this non-limiting illustrative example, each data packet 138 contains the payload of an audio frame having a length of 5 milliseconds, 7.5 milliseconds, or 10 milliseconds. Thus, data block 154 contains a total of 24 data packets 138. However, due to one or more of a variety of potential transmission and reception issues, sink device 104 only receives nine of the 24 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 completely fails to receive the third, sixth, and eighth data packets 138C, F, and H. Because at least one data packet 138 is required to render audio, sink device 104 fails to render the audio corresponding to the third, sixth, and eighth data packets 138C, F, and H, resulting in three lost audio frames and audio drops over three periods of 5 to 10 milliseconds. Furthermore, the duplicate first, second, and seventh data packets 138A, B, and G received by sink device 104 provide no additional benefit to the rendered audio.

[0065] The above-mentioned problem is addressed by the scheme shown in Figure 11B. Figure 11B shows a variation of the transmission scheme of Figure 11A, in which, rather than transmitting two duplicate data packets 138 per isochronous interval 142, these duplicate data packets 138 are replaced with supplemental data packets 140 used to create, reconstruct, or recover data packets 138 of data block 154. Furthermore, sink device 104 is provided with an error correction code so that each of eight data packets 138A-H can be reconstructed from any combination of the eight data packets 138 and supplemental data packets 140. As shown in Figure 11B, during a first isochronous interval 142A, sink device 142 receives a first data packet 138A (comprising a first audio frame) and a ninth supplemental data packet 140I. During a second isochronous interval 142B, sink device 104 receives a second data packet 138B (comprising a second audio frame) and a second supplemental data packet 140B. Sink device 104 fails to receive data during the third isochronous interval 142C. During the fourth isochronous interval 142D, sink device 104 receives the fourth supplemental data packet 138D. During the fifth isochronous interval 142E, sink device 104 receives the thirteenth supplemental data packet 138M. Sink device 104 fails to receive data during the sixth isochronous interval 142F. During the seventh isochronous interval 142G, sink device 104 receives the seventh data packet 138G (including the seventh audio frame), the seventh supplemental data packet 140G, and the fifteenth supplemental data packet 140O. Sink device 104 fails to receive data during the eighth isochronous interval 142H. Thus, sink device 104 receives three data packets 138A, B, G (containing three audio frames) and six supplemental data packets B, D, G, I, M, O for nine total packets 138, 140. Thus, by receiving the nine total data packets 138, 140, error correction codes can be used to reconstruct the missing third, fourth, fifth, sixth, and eighth data packets 138C, D, E, H and their associated audio frames.Thus, sink device 104 may then render an audio frame for all eight data packets 138, resulting in zero dropouts or lost audio during the duration of data block 154.

[0066] 11B requires at least eight total packets 138, 140 for error correction. Therefore, if fewer than eight total packets 138, 140 are received, supplemental data packet 140 has no value. In a non-limiting example of Reed-Solomon encoding and decoding, if sink device 104 fails to receive the second and seventh supplemental data packets 140B, H, only the first, second, and seventh audio frames will be rendered by sink device 104.

[0067] 12 illustrates a variation of the wireless topology shown in FIG. 9B in which source device 102 transmits multiple data packets 138A-D and multiple supplemental data packets 140A-H over an isochronous stream group 158 that includes three isochronous streams 136A-C. As in FIG. 9B, the three isochronous streams 136A-C may be divided into a series of isochronous intervals 142A-D. Source device 102 transmits first data packet 138A and first and second supplemental data packets 140A, B during a first isochronous event 156A1 of first isochronous stream 136A in first isochronous interval 142A. Source device 102 then transmits second data packet 138B and third and fourth supplemental data packets 140C, D during the first isochronous event 156B1 of second isochronous stream 136B in first isochronous interval 142A. Source device 102 then transmits third data packet 138C and fifth and sixth supplemental data packets 140E, F during the first isochronous event 156C1 of third isochronous stream 136C in first isochronous interval 142A. Source device 102 then transmits fourth data packet 138D and seventh and eighth supplemental data packets 140G, H during the second isochronous event 156A2 of first isochronous stream 136A in second isochronous interval 142B. This periodic pattern of transmission may continue as long as source device 102 provides data packets 138 for transmission. Thus, source device 102 modifies isochronous streams 136A-C to transmit data packets 138 and supplemental data packets 140 at the end of each isochronous interval 142. Similar to the example of FIG. 9B, sink device 104 uses the error correction data in first data packet 138A, second data packet 138B, and third supplemental data packet 140C to recreate third data packet 138C.

[0068] 13 illustrates a variation of the wireless topology shown in FIG. 12 in which four data packets 138A-D are transmitted consecutively, followed by five consecutive supplemental data packets 140A-E. Source device 102 first transmits first, second, and third data packets 138A-C at a first isochronous event 156A1 of first isochronous stream 136A during a first isochronous interval 142A. Source device 102 then transmits fourth data packet 138D and first and second supplemental data packets 140A, B at a first isochronous event 156B1 of second isochronous stream 136B during the first isochronous interval 142A. Source device 102 then transmits third, fourth, and fifth supplemental data packets 140C-E at a first isochronous event 156C1 of third isochronous stream 136C during first isochronous interval 142A. Source device 102 then transmits fifth, sixth, and seventh data packets 138E-G at a second isochronous event 156A2 of first isochronous stream 136A during second isochronous interval 142B. This pattern may continue as long as source device 102 provides data packets 138 and supplemental data packets 140 for transmission.

[0069] 12 and 13 show an isochronous stream group 158 that alternates transmissions between three isochronous streams 136A-C, although any practical number of streams may be used. Additionally, while Figures 12 and 13 show examples of repeating patterns of transmission, in some examples, the pattern of which isochronous streams 136A-C transmit data packets 138 or supplemental data packets 140 during an isochronous interval 142 may be random or pseudo-random.

[0070] Furthermore, in some examples, transmission of data packets 138 and supplemental data packets 140 may be ordered to improve latency or packet loss concealment. To improve latency, some isochronous events within isochronous stream 136 include only data packets 138, while other isochronous events include only supplemental data packets 140. An example of this type of ordering is shown in FIG. 13. Conversely, spreading transmitted data packets 138 in time within data block 154 improves 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 data block 154 includes three data packets 138A-C and three supplemental data packets 140A-C, the transmission will be in the following order: (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.

[0071] Figure 14 illustrates a variation of the wireless topology shown in Figure 9B in which source device 102 transmits multiple data packets 138A-D and multiple supplemental data packets 140A-H over isochronous stream 136. The example of Figure 14 differs from Figure 9B in that the supplemental data packets 140 for some of the isochronous intervals 142 (particularly the second and third isochronous intervals 142B, C) are transmitted before the data packets 138 for the corresponding isochronous intervals 142.

[0072] 15 illustrates steps of a preferred method 300 according to the present disclosure. Method 300 includes, for example, transmitting at least one data packet using a first frequency at a first time using an isochronous stream group including one or more isochronous streams (step 302), and transmitting one or more supplemental data packets over the isochronous stream group (step 304), where the one or more supplemental data packets are time-shifted relative to the at least one data packet and / or at a second frequency different from the first frequency.

[0073] According to one example, at least one data packet is created, recreated, and / or extended in accordance with error correction coded supplemental or extension data.

[0074] According to one example, one or more supplemental data packets include error correction coded supplemental or extended data.

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

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

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

[0078] According to one example, upon receipt by an audio device, the at least one data packet may be used to create a portion of audio to be played by the audio device.

[0079] In one aspect, the isochronous stream is a broadcast isochronous stream or a connected isochronous stream. In examples where the isochronous stream is a connected isochronous stream, method 300 further includes the optional step of confirming successful recovery of one or more of the plurality of data packets based on the plurality of supplemental data packets via the source device (step 306).

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

[0081] The indefinite articles "a" and "an," as used in the specification and claims, unless expressly indicated otherwise, should be understood to mean "at least one."

[0082] The phrase "and / or," as used in the specification and claims, should be understood to mean "either or both" of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with "and / or" should be construed in the same manner, i.e., "one or more" of the elements so conjoined. Other elements, whether related or unrelated to the elements specifically identified, may optionally be present other than the elements specifically identified by the "and / or" clause.

[0083] As used in this specification and claims, "or" 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" should be interpreted as inclusive, i.e., including at least one, but also including more than one, of a number or list of elements, and optionally including additional unlisted items. Terms such as "only one of" or "exactly one of," or, when used in the claims, "consisting of," refer to the inclusion of exactly one element of a number or list of elements only when clearly indicated otherwise. Generally, the term "or" as used herein will 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."

[0084] As used in this specification and claims, the phrase "at least one" in reference to a list of one or more elements should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed in the list of elements, and not excluding any combinations of elements in the list of elements. This definition also allows for elements, whether related or unrelated to the specifically identified elements, to be optionally present other than the elements specifically identified in the list of elements to which the phrase "at least one" refers.

[0085] It is also to be understood that, unless expressly indicated otherwise, in any method claimed herein that includes more than one step or action, the order of the method steps or actions is not necessarily limited to the order in which the method steps or actions are recited.

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

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

[0088] The present disclosure may be implemented as a system, method, and / or computer program product at any level of technical detail contemplated. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions that cause a processor to perform aspects of the present disclosure.

[0089] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but 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 computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM, or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, punch cards, or mechanically encoded devices having instructions recorded thereon such as raised structures in grooves, and suitable combinations of the foregoing. As used herein, a computer-readable storage medium is not to be construed as a transitory signal itself, such as a freely propagating electromagnetic wave such as an electric wave, an electromagnetic wave propagating through a transmission medium such as a waveguide (e.g., a light pulse passing through a fiber optic cable), or an electrical signal traveling down an electrical wire.

[0090] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface of each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0091] The computer-readable program instructions that carry out the operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state configuration data, integrated circuit configuration data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk or C++, procedural programming languages ​​such as the "C" programming language, or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may 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 may be connected to an external computer (e.g., through the Internet using an Internet Service Provider). In some examples, electronic circuitry, including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by individualizing the electronic circuitry using state information of the computer-readable program instructions to perform aspects of the present disclosure.

[0092] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to examples of the present 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.

[0093] Computer-readable program instructions may be provided to a processor of a special-purpose computer or other programmable data processing device to produce a machine, whereby the instructions, executing via the processor of the computer or other programmable data processing device, create means for performing the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. Furthermore, these computer-readable program instructions may be stored on a computer-readable storage medium that can direct a computer, programmable data processing device, and / or other device to function in a particular manner, whereby the computer-readable storage medium on which the instructions are stored includes an article of manufacture having instructions that implement aspects of the functions / operations specified in the flowcharts and / or block diagrams or blocks.

[0094] Furthermore, the computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device to generate a computer-implemented process for a series of operational steps to be performed on the computer, other programmable apparatus, or other device, such that the instructions executing on the computer, other programmable apparatus, or other device perform the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0095] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various examples of the present disclosure. In this regard, each block in the flowcharts or block diagrams may correspond to a module, segment, or portion of instructions, including one or more executable instructions that perform a specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or in some cases, the blocks may be executed in the reverse order, depending on the functionality involved. Furthermore, it should 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, may be implemented in a dedicated hardware-based system that performs a particular function or that operates or executes a combination of dedicated hardware and computer instructions.

[0096] Other implementations are within the scope of the following claims and other claims to which the applicant may be entitled.

[0097] While various examples have been described and illustrated herein, those skilled in the art will readily conceive of numerous other means and / or structures for performing the functions and / or results and / or obtaining one or more of the advantages described herein, and each of such modifications and / or variations is deemed to be within the scope of the examples described herein. More generally, those skilled in the art will readily recognize that all parameters, dimensions, materials, and configurations described herein are exemplary, and further, that the actual parameters, dimensions, materials, and / or configurations will depend on the particular application or applications for which the teachings of the present invention 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. Accordingly, it is to be understood that the foregoing examples are presented by way of example only and that, within the scope of the appended claims and equivalents thereof, the examples may be practiced otherwise than as specifically described and claimed. Examples of the present disclosure are directed to each individual feature, system, article, material, kit, and / or method described herein. Furthermore, any combination of two or more such features, systems, articles, materials, kits, and / or methods is included within the inventive scope of the present disclosure, if such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent. [Explanation of symbols]

[0098] 100 systems 102 Source Devices 104 sink devices 106 Source Controller 108 Source Processor 110 Source Memory 112 computer readable source instructions 114 Source Communication Module 116 Source Radio 118 Sink Controller 120 Sync Processor 122 Sync Memory 124 computer readable sink instructions 126 Sink Communication Module 128 Sync Radio 130 Sync Speaker 132 Wireless Connection 136 Isochronous Data Streams 138 data packets 140 Supplemental Data Packets 142 Isochronous Interval 144 First Frequency 146 Second Frequency 148 first plurality of data packets 150 second plurality of data packets 152 Third Frequency 154 data blocks 156 Isochronous Events 158 Isochronous Stream Group 200 ways 202 steps 204 steps 206 steps 300 ways 302 steps 304 steps 306 steps

Claims

1. A source device comprising at least one processor for executing instructions, the instructions comprising: transmitting at least one data packet to at least one sink device using an isochronous stream group including one or more isochronous streams, the data packet being transmitted at a first time using a first frequency; configured to transmit one or more supplemental data packets over the isochronous 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 to the at least one sink device; The one or more supplemental data packets are used to recreate and / or extend 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, recreated, and / or enhanced in accordance with 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 containing the error correction coded supplemental data.

4. The source device of claim 2 , wherein each of the at least one data packet includes a header, the header including 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 includes a header, the header including error correction code information and / or packet identification information.

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

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

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

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

10. The source device of claim 1 , wherein, upon receipt by the sink device, the at least one data packet 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 of the isochronous streams is a broadcast isochronous stream or a connected isochronous stream.

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

13. 1. A method for improving wireless communications, comprising: transmitting at least one data packet using an isochronous stream group including one or more isochronous streams, the data packet being transmitted at a first time using a first frequency; transmitting one or more supplemental data packets over the isochronous stream group, the one or more supplemental data packets being time-shifted with respect to the at least one data packet and / or at a second frequency different from the first frequency; The method, wherein the one or more supplemental data packets are used to recreate and / or extend 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, recreated, and / or extended in accordance with error correction coded supplemental or extension data.

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

16. The method of claim 14 , wherein each of the at least one data packet includes a header, the header including 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 includes a header, the header including supplemental data type information and / or packet identification information.

18. 14. The method of claim 13, wherein, upon receipt by an audio device, the at least one data packet 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 isochronous streams is a broadcast isochronous stream or a connected isochronous stream.

20. one of the one or more isochronous streams is a connected isochronous stream, and the method 20. The method of claim 19, further comprising verifying successful recovery of the at least one data packet based on the one or more supplemental data packets.

Images