Updating parameters of machine-learning codec based on channel conditions

Abstract

A first device includes a memory configured to store parameters of an ML codec. The first device also includes one or more processors configured to obtain channel condition data indicating channel conditions experienced by a radio frontend of a second device. The one or more processors are configured to obtain updated parameters of the ML codec based on the channel condition data and to cause data indicating the updated parameters of the ML codec to be sent to the second device.

Description

UPDATING PARAMETERS OF MACHINE-LEARNING CODEC BASED ON CHANNEL CONDITIONSI. Cross-Reference to Related Applications

[0001] The present application claims the benefit of priority from the commonly owned Greek Provisional Patent Application No. 20240100341, filed May 14, 2024, the contents of which are expressly incorporated herein by reference in their entirety.IL Field

[0002] The present disclosure is generally related to machine-learning codecs.III. Description of Related Art

[0003] Advances in technology have resulted in smaller and more powerful computing devices. For example, there currently exist a variety of portable personal computing devices, including wireless telephones such as mobile and smart phones, tablets and laptop computers that are small, lightweight, and easily carried by users. These devices can communicate voice and data packets over wireless networks. Further, many such devices incorporate additional functionality such as a digital still camera, a digital video camera, a digital recorder, and an audio file player. Also, such devices can process executable instructions, including software applications, such as a web browser application, that can be used to access the Internet. As such, these devices can include significant computing capabilities.

[0004] Such computing devices often incorporate functionality to exchange data with other devices via wireless transmissions. During a communication session to exchange data, a transmitting device generally encodes the data using an encoder and sends the encoded data to a receiving device via a communications channel. The receiving device receives signals representing the encoded data and uses a decoder to decode the data. If the communication channel were perfect, the decoded data would approximate the data encoded by the transmitting device, except for losses due to the encoding process. However, in reality, few if any communication channels are perfect. As a result, thereceiving device generally does not receive some portions of the encoded data and other portions of the encoded data are corrupted during transmission. Thus, such computing devices benefit from the ability to reconstruct data that is corrupted, lost, or delayed during transmission.IV. Summary

[0005] According to one implementation of the present disclosure, a device includes a memory configured to store parameters of a machine-learning (ML) codec. The device also includes one or more processors configured to obtain channel condition data indicating channel conditions experienced by a first radio frontend during a first communication session. The one or more processors are configured to obtain updated parameters of the ML codec based on the channel condition data.

[0006] According to another implementation of the present disclosure, a method includes obtaining, by one or more processors, channel condition data indicating channel conditions experienced by a first radio frontend during a first communication session. The method also includes obtaining, by the one or more processors, updated parameters of an ML codec associated with the first communication session based on the channel condition data.

[0007] According to another implementation of the present disclosure, a non-transitory computer-readable medium stores instructions that are executable by one or more processors to cause the one or more processors to obtain channel condition data indicating channel conditions experienced by a first radio frontend during a first communication session. The instructions further cause the one or more processors to obtain updated parameters of an ML codec based on the channel condition data.

[0008] According to another implementation of the present disclosure, an apparatus includes means for obtaining channel condition data indicating channel conditions experienced by a first radio frontend during a first communication session. The apparatus also includes means for obtaining updated parameters of an ML codec associated with the first communication session based on the channel condition data.

[0009] According to one implementation of the present disclosure, a device includes a memory configured to store channel condition data. The device also includes one or more processors configured to obtain first channel condition data indicating first channel conditions experienced by a first radio frontend in a first location. The one or more processors are also configured to obtain, based on the first channel condition data, a first set of parameters of an ML codec for the first channel conditions. The one or more processors are also configured to, based on location data associated with a second device that is associated with a second radio frontend, cause data indicating the first set of parameters of the ML codec to be sent to the second device.

[0010] According to another implementation of the present disclosure, a method includes obtaining, by one or more processors, first channel condition data indicating first channel conditions experienced by a first radio frontend in a first location. The method also includes obtaining, by the one or more processors and based on the first channel condition data, a first set of parameters of an ML codec for the first channel conditions. The method also includes, based on location data associated with a second device that is associated with a second radio frontend, causing data indicating the first set of parameters of the ML codec to be sent to the second device.

[0011] According to another implementation of the present disclosure, a non-transitory computer-readable medium stores instructions that are executable by one or more processors to cause the one or more processors to obtain first channel condition data indicating first channel conditions experienced by a first radio frontend in a first location. The instructions further cause the one or more processors to obtain, based on the first channel condition data, a first set of parameters of an ML codec for the first channel conditions. The instructions further cause the one or more processors to, based on location data associated with a second device that is associated with a second radio frontend, cause data indicating the first set of parameters of the ML codec to be sent to the second device.

[0012] According to another implementation of the present disclosure, an apparatus includes means for obtaining first channel condition data indicating first channel conditions experienced by a first radio frontend in a first location. The apparatus alsoincludes means for obtaining, based on the first channel condition data, a first set of parameters of an ML codec for the first channel conditions. The apparatus also includes means for, based on location data associated with a second device that is associated with a second radio frontend, causing data indicating the first set of parameters of the ML codec to be sent to the second device.

[0013] According to one implementation of the present disclosure, a device includes a memory configured to store mapping data that associates channel condition data to parameters of an ML codec. The device also includes one or more processors configured to obtain first channel condition data associated with channel conditions experienced at a first radio frontend during one or more first communication sessions. The one or more processors are also configured to determine first parameters of the ML codec based on the first channel condition data and the mapping data. The one or more processors are also configured to send data indicating the first parameters to a first device.

[0014] According to another implementation of the present disclosure, a method includes obtaining first channel condition data associated with channel conditions experienced at a first radio frontend during one or more first communication sessions. The method also includes determining first parameters of an ML codec based on the first channel condition data and mapping data that associates channel condition data to parameters of the ML codec. The method also includes causing data indicating the first parameters to be sent to a first device.

[0015] According to another implementation of the present disclosure, a non-transitory computer-readable medium stores instructions that are executable by one or more processors to cause the one or more processors to obtain first channel condition data associated with channel conditions experienced at a first radio frontend during one or more first communication sessions. The instructions further cause the one or more processors to determine first parameters of an ML codec based on the first channel condition data and mapping data that associates channel condition data to parameters of the ML codec. The instructions further cause the one or more processors to send data indicating the first parameters to a first device.

[0016] According to another implementation of the present disclosure, an apparatus includes means for obtaining first channel condition data associated with channel conditions experienced at a first radio frontend during one or more first communication sessions. The apparatus also includes means for determining first parameters of an ML codec based on the first channel condition data and mapping data that associates channel condition data to parameters of the ML codec. The apparatus also includes means for causing data indicating the first parameters to be sent to a first device.

[0017] According to one implementation of the present disclosure, a device includes a memory configured to store parameters of an ML codec. The device also includes one or more processors configured to obtain bit error data indicative of bit errors associated with a first communication session. The one or more processors are also configured to obtain updated parameters of the ML codec based on the bit error data.

[0018] According to another implementation of the present disclosure, a method includes obtaining bit error data indicative of bit errors associated with a first communication session. The method also includes obtaining updated parameters of an ML codec based on the bit error data.

[0019] According to another implementation of the present disclosure, a non-transitory computer-readable medium stores instructions that are executable by one or more processors to cause the one or more processors to obtain bit error data indicative of bit errors associated with a first communication session. The instructions further cause the one or more processors to obtain updated parameters of an ML codec based on the bit error data.

[0020] According to another implementation of the present disclosure, an apparatus includes means for obtaining bit error data indicative of bit errors associated with a first communication session. The apparatus also includes means for obtaining updated parameters of an ML codec based on the bit error data.

[0021] According to one implementation of the present disclosure, a first device includes a memory configured to store parameters of an ML codec. The device also includes one or more processors configured to obtain channel condition data indicatingchannel conditions experienced by a radio frontend of a second device. The one or more processors are configured to obtain updated parameters of the ML codec based on the channel condition data and to cause data indicating the updated parameters of the ML codec to be sent to the second device.

[0022] According to another implementation of the present disclosure, a method includes obtaining, by one or more processors of a first device, channel condition data indicating channel conditions experienced by a radio frontend of a second device. The method includes obtaining, by the one or more processors, updated parameters of an ML codec based on the channel condition data and causing, by the one or more processors, data indicating the updated parameters of the ML codec to be sent to the second device.

[0023] According to another implementation of the present disclosure, a non-transitory computer-readable medium stores instructions that are executable by one or more processors to cause the one or more processors to obtain channel condition data indicating channel conditions experienced by a radio frontend of a second device. The instructions cause the one or more processors to obtain updated parameters of the ML codec based on the channel condition data. The instructions cause the one or more processors to cause data indicating the updated parameters of the ML codec to be sent to the second device.

[0024] According to another implementation of the present disclosure, an apparatus includes means for obtaining, by one or more processors of a first device, channel condition data indicating channel conditions experienced by a radio frontend of a second device. The apparatus also include means for obtaining updated parameters of an ML codec based on the channel condition data. The apparatus includes means for causing data indicating the updated parameters of the ML codec to be sent to the second device.

[0025] According to one implementation of the present disclosure, a first device includes a memory configured to store parameters of an ML codec. The device also includes one or more processors configured to obtain channel condition data indicating channel conditions experienced by a radio frontend associated with the one or moreprocessors. The one or more processors are also configured to cause data the channel condition data to be sent to a second device and to receive, from the second device, data indicating updated parameters of the ML codec based on the channel condition data.

[0026] According to another implementation of the present disclosure, a method includes obtaining, at one or more processors, channel condition data indicating channel conditions experienced by a radio frontend associated with the one or more processors. The method includes causing data the channel condition data to be sent to a second device and receiving, from the second device, data indicating updated parameters of an ML codec based on the channel condition data.

[0027] According to another implementation of the present disclosure, a non-transitory computer-readable medium stores instructions that are executable by one or more processors to cause the one or more processors to obtain channel condition data indicating channel conditions experienced by a radio frontend associated with the one or more processors. The instructions are executable to cause the one or more processors to cause data the channel condition data to be sent to a second device and to receive, from the second device, data indicating updated parameters of an ML codec based on the channel condition data.

[0028] According to another implementation of the present disclosure, an apparatus includes means for obtaining, at one or more processors, channel condition data indicating channel conditions experienced by a radio frontend associated with the one or more processors. The apparatus includes means for causing data the channel condition data to be sent to a second device and means for receiving, from the second device, data indicating updated parameters of an ML codec based on the channel condition data.

[0029] Other aspects, advantages, and features of the present disclosure will become apparent after review of the entire application, including the following sections: Brief Description of the Drawings, Detailed Description, and the Claims.V. Brief Description of the Drawings

[0030] FIG. 1 A is a block diagram of a particular illustrative aspect of a system operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0031] FIG. IB illustrates an example of aspects of operation of the system of FIG. 1A according to a particular embodiment.

[0032] FIG. 1C illustrates aspects of operation of a particular example of a remote device of FIG. IB.

[0033] FIG. ID illustrates aspects of operation of another particular example of the remote device of FIG. IB.

[0034] FIG. 2 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0035] FIG. 3 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0036] FIG. 4A is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0037] FIG. 4B is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0038] FIG. 5 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0039] FIG. 6 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0040] FIG. 7 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0041] FIG. 8 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0042] FIG. 9 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0043] FIG. 10 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0044] FIG. 11 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0045] FIG. 12 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0046] FIG. 13 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0047] FIG. 14 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0048] FIG. 15 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0049] FIG. 16 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0050] FIG. 17 is a diagram of an illustrative aspect of operations associated with updating parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0051] FIG. 18 illustrates an example of an integrated circuit operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0052] FIG. 19 is a diagram of a mobile device operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0053] FIG. 20 is a diagram of a hearing aid device operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0054] FIG. 21 is a diagram of a headset operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0055] FIG. 22 is a diagram of a wearable electronic device operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0056] FIG. 23 is a diagram of a mixed reality or augmented reality glasses device operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0057] FIG. 24 is a diagram of earbuds operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0058] FIG. 25 is a diagram of a voice-controlled speaker system operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0059] FIG. 26 is a diagram of a camera operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0060] FIG. 27 is a diagram of a headset, such as a virtual reality, mixed reality, or augmented reality headset, operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0061] FIG. 28 is a diagram of a first example of a vehicle operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0062] FIG. 29 is a diagram of a second example of a vehicle operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.

[0063] FIG. 30 is a diagram of a particular implementation of a method of updating parameters of an ML codec based on channel conditions that may be performed by the device of FIG. 1A, in accordance with some examples of the present disclosure.

[0064] FIG. 31 is a diagram of a particular implementation of a method of updating parameters of an ML codec based on channel conditions that may be performed by the device of FIG. 1A, in accordance with some examples of the present disclosure.

[0065] FIG. 32 is a diagram of a particular implementation of a method of updating parameters of an ML codec based on channel conditions that may be performed by the device of FIG. 1A, in accordance with some examples of the present disclosure.

[0066] FIG. 33 is a diagram of a particular implementation of a method of updating parameters of an ML codec based on channel conditions that may be performed by the device of FIG. 1A, in accordance with some examples of the present disclosure.

[0067] FIG. 34 is a diagram of a particular implementation of a method of updating parameters of an ML codec based on channel conditions that may be performed by the device of FIG. 1A, in accordance with some examples of the present disclosure.

[0068] FIG. 35 is a diagram of a particular implementation of a method of updating parameters of an ML codec based on channel conditions that may be performed by the device of FIG. 1A, in accordance with some examples of the present disclosure.

[0069] FIG. 36 is a block diagram of a particular illustrative example of a device that is operable to update parameters of an ML codec based on channel conditions, in accordance with some examples of the present disclosure.VI Detailed Description

[0070] Autoencoders have gained popularity in recent years as they are able to learn efficient representations of input data without the need for labels, i.e., unsupervised learning. Various types of autoencoders exist and are well explained in “Autoencoder and its various variants” (2018 IEEE International Conference on Systems, Man, and Cybernetics), Zhang et al.

[0071] Autoencoders conditioned on log Mel Cepstrum / spectrograms input have been used for speech compression, as described in "Enhancing into the Codec: Noise Robust Speech Coding with Vector-Quantized Autoencoders" (arXiv:2010.06610vl [eess.AS], 12 Feb 2021), Casebeer et al. Speech coding is a lossy compression process. For example, for speech coding, an autoencoder performs dimensionality reduction, wherein an N-dimensional input vector is passed into the encoder of the autoencoder, and a compressed representation is generated to represent the important aspects of the input vector in an M-dimensional vector, where M is smaller than N, e.g., by an order of magnitude.

[0072] A drawback of using conventional, feedforward autoencoders for speech coding is that they cannot necessarily exploit the temporal relationships between sets of input data. U.S. patent 11,526,734 ("'734 patent”) assigned to Qualcomm, Inc., "Method and Apparatus for Recurrent Auto Encoding" (Yang et al.) describes a feedback recurrent autoencoder ("FRAE") that improves speech coding by exploiting temporal redundancies and correlations among audio frames. The FRAE in '734 provides details on training and application of compression of sequential data with temporal correlation. The recurrent structure of the FRAE efficiently extracts the redundancy embedded along the time-dimension of sequential data, enabling compact discrete representation of the data at the bottleneck in a sequential fashion.

[0073] The '734 patent describes (e.g. at Table 1) an error function used for training the FRAE. In particular, the '734 patent describes use of MSE (Mean Squared Error), used as Mel-scale mean-square-error, as a measure of reconstruction loss for training. In Table 1, the MSE of each frequency bin is scaled according to its weight at Mel- frequency for both latent feedback and output feedback.

[0074] The FRAE described in the ‘734 patent has two advantageous features not found in traditional autoencoders: (1) recurrent layers, e.g., LSTM or GRU layers, which retain memory of past inputs; and (2) feedback from the decoder of the autoencoder to the encoder of the autoencoder. The feedback connection 150 in Fig. 2, Fig. 3, and Fig. 7 of the ‘734 patent provides additional historical information from the state (ht) in the decoder to the encoder about how reconstruction of a prior input has fared. This feedback loop is present during both training and inference, which allows the encoder to be trained to respond to particular feedback conditions in a manner that improves reproduction of the input data by the decoder. Thus, the feedback loop is analogous to a mode switch input that serves as an input that influences how the encoder operates on the next input vector.

[0075] In addition, the ‘734 patent describes a second feedback connection (152) from the state (ht) of the decoder to an earlier layer of the decoder. This second feedback connection (152) enables the decoder to learn from its previous reconstruction attempts, providing additional historical context about how reconstruction of a prior input hasfared. This second feedback loop is also present during both training and inference, which allows the decoder to be trained to respond to particular feedback conditions in a manner that improves reproduction of the input data by the decoder.

[0076] The ‘734 patent also describes other optional feedback connections. For example, an embedding vector (z) may be fed back via a third feedback connection (356 in Fig. 3 of the ‘734 patent) to the encoder. As another optional example, the '734 patent describes that the FRAE can be a variational autoencoder. In this example, an output of the decoder (754 in Fig. 7 of the ‘734 patent) is sampled and / or parameterized to a generate an autoregressive prior which can be used as a fourth feedback connection to condition a prior model for the next latent space embedded vector (zt+1). Like the previously described feedback connections, each of these optional connections is present during both training and inference, and thus are trained as part of the training process thereby improving functionality of the FRAE.

[0077] When used as part of a system to communicate encoded data between two devices, the FRAE of the '734 patent can efficiently encode speech for transmission. In such a system, a transmitting device typically includes the full FRAE, and a receiving device includes at least the decoder of the FRAE. On the transmitting device side, input data (e.g., an input vector) including speech is provided as input to the encoder, and the encoder compresses the input data and provides the compressed data to a bottleneck layer. The bottleneck layer generates a latent space vector, which is optionally quantized, for transmission to the receiving device. At the receiving device a dequantized version of the latent space vector is provided as input to the decoder, which decompresses the latent space vector to generate a reproduction of the input data.

[0078] How closely the reproduction matches the input data is influenced by multiple factors, such as the training of the FRAE. One factor that can lead to less accurate reproduction of the input data by the decoder is error introduced during transmission. As a simple example, if one or more bits are flipped during transmission, the dequantized version of the latent space vector provided as input to the decoder does not match the latent space vector generated by the bottleneck of the FRAE at the transmitting device. The decoder is trained to reproduce the input to the encoder with reasonable accuracywhen provided a latent space vector corresponding to the input data, but there is no reason to expect the decoder to reproduce the input data accurately if the latent space vector input to the decoder includes erroneous bits.

[0079] The feedback connections discussed above can exacerbate this problem. For example, if a first latent space vector provided to the decoder has one or more flipped bits, the decoder output generated based on that erroneous latent space vector can be used to generate an audio output at the receiving device and is also provided via one or more feedback connections to earlier stages of the decoder, which can lead to incorrect decoding of later latent space vectors as well.

[0080] Similar problems arise if packets are lost during transmission. For example, on the transmitting device side, a first segment of audio data (Nt) is encoded and transmitted, and feedback related to the first segment Nt is provided to an earlier stage of the encoder and influences encoding of a second segment (Nt+1). On the receiving device side, if a packet including an encoded version of the first segment is not received, the decoder will attempt to decode the second segment Nt+1, but since the decoder did not decode the first segment Nt, feedback to earlier stage of the decoder is not available (or is not correct), which can result introduce errors on decoding of the second segment.

[0081] Each of the problems above are related to differences between the training environment of the FRAE and the actual operating environment of the FRAE. For example, generally both the encoder and the decoder of an FRAE are trained on a single device, so during the training process there are no transmission errors between the encoder and decoder. In this manner, the decoder is trained to operate with access to error free data from the encoder, and like most machine-learning models, the decoder tends to perform poorly when operating on data that differs significantly from training data used to train the decoder.

[0082] Disclosed embodiments solve these problems by modifying parameters of the ML codec (including the encoder, the decoder, or both) to parameters that are appropriate for the channel conditions actually experienced (or expected) during transmission. Modifying the parameters of the ML codec in this manner has thetechnical advantage of reducing decoding errors that result from transmission errors. For example, the parameters can be updated in a manner that introduces a simulated channel between the encoder and an instance of the decoder. In this example, the simulated channel intentionally introduces errors into encoded data in a manner selected to simulate errors expected due to the channel conditions, and the decoder can be trained (e.g., parameters of the decoder can be updated) to reduce differences between the input data to the encoder used to generate the encoded data and output of the decoder after decoding encoded data with intentionally introduced errors. Alternatively, parameters of both the encoder and the decoder can be updated.

[0083] In some embodiments, the parameters of the ML codec can be modified as needed. For example, training with the simulated channel as described above can be performed during a communication session in which particular channel conditions simulated by the simulated channel are experienced. Alternatively, training can be performed in advance (i.e., offline / before deployment to device) using channel conditions that capture the typical operating condition during inference. By incorporating such techniques into model training, the FRAE or similar systems learn to balance between predictive coding efficiency and error robustness. Given channel conditions can have a wide range. In some embodiments, training can be performed in advance for various channel conditions, and parameters associated with particular channel conditions can be retrieved as needed.

[0084] Additionally, various embodiments disclosed herein provide optional techniques for reducing the communication burden of modifying the ML codec. For example, ML codec parameters can be constrained, during training, to generate sparse parameter sets. As another example, a codebook can associate ML codec parameters with a codebook index.

[0085] Traditional procedural codecs, such as the enhanced voice service (EVS) codec, do not face the same challenges as ML codecs as they can be crafted to accommodate frame erasures due to dropped or delayed packets. While ML codecs offer many advantages over procedural codecs, such as reduced resource demand, lower-power operation, and / or better data reproduction, ML codecs often ignore frame erasures. Insituations in which channel conditions lead to significant frame erasures, the performance of many ML codecs may be degraded. To address variability of channel conditions, an ML codec can be trained to improve robustness across a wide range of channel conditions; however, training the ML codec in this manner generally reduces performance of the ML codec for at least a sub-set of the channel conditions, which is less than optimal.

[0086] Factors that can influence channel conditions include, without limitation, whether the channel includes terrestrial or non-terrestrial (e.g., orbital or aerial) communication links, a mode of operation of the communication links (e.g., best efforts or managed), type(s) of radio access technology used by the communication links (e.g., a BLUETOOTH® connection, a WIFI® connection, a terrestrial mobile data connection (e.g., a connection conforming to a cellular voice and data network protocol from a 3rd Generation Partnership Project (3GPP) standards organization, such as a 3G, 4G, 5G, or a 6G connection), a non-terrestrial network connection (e.g., a GLOBALSTAR® satellite network connection, an IRIDIUM® satellite network connection, a STARLINK® satellite network connection)), etc. (Bluetooth® is a registered trademark of Bluetooth SIG, Inc., a Delaware Corporation; Wi-Fi® is a registered trademark of Wi-Fi Alliance, a California corporation; GLOBALSTAR® is a registered trademark of the GLOBALSTAR, INC., a Delaware corporation; IRIDIUM® is a registered trademark of IRIDIUM SATELLITE LLC, a Delaware corporation; STARLINK® is a registered trademark of the Space Exploration Technologies Corp., a Delaware corporation), the specific frequency band(s) used for transmissions, whether one or more devices of a communication link are mobile, whether frame bundling is used, and many other factors that affect specific channel condition metrics, such as block error rate, delay, jitter, Carrier-to-Interference plus Noise Ratio (CINR), Signal-to- Interference plus Noise Ratio (SINR), Doppler spread, and so forth. Given the wide range of channel conditions that may be encountered, it is challenging to train a single ML codec to operate well in all conditions.

[0087] Embodiments disclosed herein solve the challenge of using ML codecs in a variety of channel conditions by updating parameters of an ML codec based on the channel conditions. For example, a pre-trained model (e.g., an ML codec that includesan initial set of parameters) can be used during the start of a communication session, and the parameters of the ML codec can be changed during or after the communication session to better align with the channel conditions experienced during the communication session. As another example, the channel conditions experienced by a first radio frontend (e.g., of a first device) can be used to determine updated parameters of the ML codec, and the updated parameters can be provided to one or more other devices that are experiencing (or are predicted to experience) the same or similar channel conditions.

[0088] Updated parameters of the ML codec can be obtained using one or more of several different techniques. In some embodiments, the updated parameters can be retrieved (e.g., looked up) from mapping data that maps particular channel conditions to corresponding ML codec parameters. In other embodiments, the updated parameters can be determined using ML training techniques. In some embodiments, the updated parameters can be received from another device that determines the updated parameters.

[0089] In some embodiments, the updated parameters of the ML codec can be determined at a device participating in a communication session. For example, at the beginning of a communication session, a first device can encode and transmit data using a first version of the ML codec, and a second device can receive and decode the encoded data using the first version of the ML codec. However, as channel conditions associated with the communication session change, the second device can update the parameters of its decoder, based on the channel conditions, to improve reproduction of the data. Updating the parameters of the ML codec onboard the second device enables the second device to determine parameters that are specific to the channel conditions experienced by the second device and specific to the hardware and configuration of the second device. In some embodiments, the second device can update the parameters of both its encoder and its decoder. In such embodiments, the second device can send the updated encoder parameters to the first device to update the encoder used at the first device, which can further improve reproduction of the data at the second device.

[0090] In other embodiments, the updated parameters of the ML codec can be determined at a device distinct from those participating in the communication session.To illustrate, continuing the example above, during or after the communication session, the second device can send channel condition data indicating channel conditions experienced by the second device during the communication session to another device (e.g., an edge server of a network). In this example, the other device can determine updated parameters of the ML codec based on the channel condition data. The other device can subsequently send data indicating the updated parameters to the first device, the second device, or one or more third devices. To illustrate, when a third device experiences or is predicted to experience similar channel conditions to those associated with the channel condition data, the other device can send the data indicating the updated parameters to the third device.

[0091] The data indicating the updated parameters of the ML codec can include the updated parameters or other data characterizing the updated parameters. For example, sets of updated parameters can be aggregated based on similarity to one another or based on similarity of channel conditions with which they are associated. In this example, a codebook index can be assigned to an aggregate set of parameters, and the codebook index can be sent to a device to indicate which parameters should be used for particular channel conditions. In some embodiments, adaptation of the parameters of the ML codec can be constrained to generate sparse data (e.g., sparse adapted parameter data) to enable communication of the updated parameters using fewer bits than would be required to send a full set of floating-point value representations of the parameters.

[0092] In some embodiments, the channel conditions can be determined at a single endpoint device (e.g., a receiving device). For example, the channel conditions can be determined based on signal-to-noise metrics, packet losses, block error metrics, estimated or measured bit error metrics, packet delays, or temporal distributions of any of these. In a particular embodiment, bit error metrics can be determined at a receiving device based on a transmitting device sending a sequence of bits that are known by the receiving device. For example, the transmitting device can send a sequence of bits that both the transmitting device and the receiving device know in advance (e.g., a test sequence stored in a memory of both the transmitting device and the receiving device). As another example, the transmitting device can use a particular seed to generate arandomized sequence of bits for transmission to the receiving device, and the receiving device can recreate the randomized sequence of bits using the same seed.

[0093] In some embodiments, the bit error metric can be estimated at the receiving device based on soft bit decoding of symbols received from the transmitting device. For example, log-likelihood ratios (LLRs) of each bit can be used to estimate the probability of bit errors. As another example, block error rates (BLERs) can be measured using parity data (e.g., low-density parity check (LDPC) data), and the BLER data can be mapped to estimates of bit error rates (e.g., using cumulative distribution functions (CDFs)) for various BLERs.

[0094] Thus, the disclosed embodiments solve the problem of how to provide an ML codec that is robust to various channel conditions by updating the parameters of an encoder, a decoder, or both, of an ML codec based on channel conditions experienced by individual devices. The disclosed embodiments also facilitate communication of ML codec parameters as they are needed or before they are needed by a particular device by generating sparse sets of parameters, by mapping parameters to codebook indices, or both; thereby reducing resources used to communicate ML codec parameters.

[0095] Particular aspects of the present disclosure are described below with reference to the drawings. In the description, common features are designated by common reference numbers. As used herein, various terminology is used for the purpose of describing particular implementations only and is not intended to be limiting of implementations. For example, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Further, some features described herein are singular in some implementations and plural in other implementations. To illustrate, FIG. 1 A depicts a device 102 including one or more processors ("processor(s)" 190 of FIG. 1 A), which indicates that in some implementations the device 102 includes a single processor 190 and in other implementations the device 102 includes multiple processors 190. For ease of reference herein, such features are generally introduced as "one or more" features and are subsequently referred to in the singular or optional plural (as indicated by "(s)") unless aspects related to multiple of the features are being described.

[0096] In some drawings, multiple instances of a particular type of feature are used. Although these features are physically and / or logically distinct, the same reference number is used for each, and the different instances are distinguished by addition of a letter to the reference number. When the features as a group or a type are referred to herein, e.g., when no particular one of the features is being referenced, the reference number is used without a distinguishing letter. However, when one particular feature of multiple features of the same type is referred to herein, the reference number is used with the distinguishing letter. For example, referring to FIG. 1 A, multiple channels are illustrated and associated with reference numbers 176A, 176B, and 176C. When referring to a particular one of these channels, such as a channel 176A, the distinguishing letter "A" is used. However, when referring to any arbitrary one of these channels or to these channels as a group, the reference number 176 is used without a distinguishing letter.

[0097] As used herein, the terms "comprise," "comprises," and "comprising" may be used interchangeably with "include," "includes," or "including." Additionally, the term "wherein" may be used interchangeably with "where." As used herein, "exemplary" indicates an example, an implementation, and / or an aspect, and should not be construed as limiting or as indicating a preference or a preferred implementation. As used herein, an ordinal term (e.g., "first," "second," "third," etc.) used to modify an element, such as a structure, a component, an operation, etc., does not by itself indicate any priority or order of the element with respect to another element, but rather merely distinguishes the element from another element having a same name (but for use of the ordinal term). As used herein, the term "set" refers to one or more of a particular element, and the term "plurality" refers to multiple (e.g., two or more) of a particular element.

[0098] As used herein, "coupled" may include "communicatively coupled," "electrically coupled," or "physically coupled," and may also (or alternatively) include any combinations thereof. Two devices (or components) may be coupled (e.g., communicatively coupled, electrically coupled, or physically coupled) directly or indirectly via one or more other devices, components, wires, buses, networks (e.g., a wired network, a wireless network, or a combination thereof), etc. Two devices (or components) that are electrically coupled may be included in the same device or indifferent devices and may be connected via electronics, one or more connectors, or inductive coupling, as illustrative, non-limiting examples. In some implementations, two devices (or components) that are communicatively coupled, such as in electrical communication, may send and receive signals (e.g., digital signals or analog signals) directly or indirectly, via one or more wires, buses, networks, etc. As used herein, "directly coupled" may include two devices that are coupled (e.g., communicatively coupled, electrically coupled, or physically coupled) without intervening components.

[0099] In the present disclosure, terms such as "determining," "calculating," "estimating," "shifting," "adjusting," etc. may be used to describe how one or more operations are performed. It should be noted that such terms are not to be construed as limiting and other techniques may be utilized to perform similar operations. Additionally, as referred to herein, "generating," "calculating," "estimating," "using," "selecting," "accessing," and "determining" may be used interchangeably. For example, "generating," "calculating," "estimating," or "determining" a parameter (or a signal) may refer to actively generating, estimating, calculating, or determining the parameter (or the signal) or may refer to using, selecting, or accessing the parameter (or signal) that is already generated, such as by another component or device.

[0100] As used herein, the term "machine learning" should be understood to have any of its usual and customary meanings within the fields of computers science and data science, such meanings including, for example, processes or techniques by which one or more computers can learn to perform some operation or function without being explicitly programmed to do so. As a typical example, machine learning can be used to enable one or more computers to analyze data to identify patterns in data and generate a result based on the analysis. For certain types of machine learning, the results that are generated include data that indicates an underlying structure or pattern of the data itself. Such techniques, for example, include so-called "clustering" techniques, which identify clusters (e.g., groupings of data elements of the data).

[0101] For certain types of machine learning, the results that are generated include a data model (also referred to as a "machine-learning model" or simply a "model"). Typically, a model is generated using a first data set to facilitate analysis of a seconddata set. For example, a first portion of a large body of data may be used to generate a model that can be used to analyze the remaining portion of the large body of data. As another example, a set of historical data can be used to generate a model that can be used to analyze future data.

[0102] Since a model can be used to evaluate a set of data that is distinct from the data used to generate the model, the model can be viewed as a type of software (e.g., instructions, parameters, or both) that is automatically generated by the computer(s) during the machine learning process. As such, the model can be portable (e.g., can be generated at a first computer, and subsequently moved to a second computer for further training, for use, or both). Additionally, a model can be used in combination with one or more other models to perform a desired analysis. To illustrate, first data can be provided as input to a first model to generate first model output data, which can be provided (alone, with the first data, or with other data) as input to a second model to generate second model output data indicating a result of a desired analysis. Depending on the analysis and data involved, different combinations of models may be used to generate such results. In some examples, multiple models may provide model output that is input to a single model. In some examples, a single model provides model output to multiple models as input.

[0103] Examples of machine-learning models include, without limitation, perceptrons, neural networks, support vector machines, regression models, decision trees, Bayesian models, Boltzmann machines, adaptive neuro-fuzzy inference systems, as well as combinations, ensembles and variants of these and other types of models. Variants of neural networks include, for example and without limitation, prototypical networks, autoencoders, transformers, self-attention networks, convolutional neural networks, deep neural networks, deep belief networks, etc. Variants of decision trees include, for example and without limitation, random forests, boosted decision trees, etc.

[0104] Since machine-learning models are generated by computer(s) based on input data, machine-learning models can be discussed in terms of at least two distinct time windows - a creation / training phase and a runtime phase. During the creation / training phase, a model is created, trained, adapted, validated, or otherwise configured by thecomputer based on the input data (which in the creation / training phase, is generally referred to as "training data"). Note that the trained model corresponds to software that has been generated and / or refined during the creation / training phase to perform particular operations, such as classification, prediction, encoding, or other data analysis or data synthesis operations. During the runtime phase (or "inference" phase), the model is used to analyze input data to generate model output. The content of the model output depends on the type of model. For example, a model can be trained to perform classification tasks or regression tasks, as non-limiting examples. In some implementations, a model may be continuously, periodically, or occasionally updated, in which case training time and runtime may be interleaved or one version of the model can be used for inference while a copy is updated, after which the updated copy may be deployed for inference.

[0105] In some implementations, a previously generated model is trained (or re-trained) using a machine-learning technique. In this context, "training" refers to adapting the model or parameters of the model to a particular data set. Unless otherwise clear from the specific context, the term "training" as used herein includes "re-training" or refining a model for a specific data set. For example, training may include so called "transfer learning." In transfer learning a base model may be trained using a generic or typical data set, and the base model may be subsequently refined (e.g., re-trained or further trained) using a more specific data set.

[0106] A data set used during training is referred to as a "training data set" or simply "training data". The data set may be labeled or unlabeled. "Labeled data" refers to data that has been assigned a categorical label indicating a group or category with which the data is associated, and "unlabeled data" refers to data that is not labeled. Typically, "supervised machine-learning processes" use labeled data to train a machine-learning model, and "unsupervised machine-learning processes" use unlabeled data to train a machine-learning model; however, it should be understood that a label associated with data is itself merely another data element that can be used in any appropriate machinelearning process. To illustrate, many clustering operations can operate using unlabeled data; however, such a clustering operation can use labeled data by ignoring labels assigned to data or by treating the labels the same as other data elements.

[0107] Training a model based on a training data set generally involves changing parameters of the model with a goal of causing the output of the model to have particular characteristics based on data input to the model. To distinguish from model generation operations, model training may be referred to herein as optimization or optimization training. In this context, "optimization" refers to improving a metric, and does not mean finding an ideal (e.g., global maximum or global minimum) value of the metric. Examples of optimization trainers include, without limitation, backpropagation trainers, derivative free optimizers (DFOs), and extreme learning machines (ELMs). As one example of training a model, during supervised training of a neural network, an input data sample is associated with a label. When the input data sample is provided to the model, the model generates output data, which is compared to the label associated with the input data sample to generate an error value. Parameters of the model are modified in an attempt to reduce (e.g., optimize) the error value. As another example of training a model, during unsupervised training of an autoencoder, a data sample is provided as input to the autoencoder, and the autoencoder reduces the dimensionality of the data sample (which is a lossy operation) and attempts to reconstruct the data sample as output data. In this example, the output data is compared to the input data sample to generate a reconstruction loss, and parameters of the autoencoder are modified in an attempt to reduce (e.g., optimize) the reconstruction loss.

[0108] FIG. 1 A is a block diagram of a particular illustrative aspect of a system 100 that includes a device 102 that includes a machine-learning (ML) codec 134. The device 102 is configured to determine updated parameters (e.g., parameters 142) of the ML codec 134 based on channel conditions experienced at a radio frontend of one or more devices, such as by the device 102 or one or more other devices (e.g., one or more endpoint devices 180 or one or more network devices 182). The ML codec 134 can include, for example, a data codec, an audio codec, a video codec, a graphics codec, or a combination thereof.

[0109] In the example illustrated in FIG. 1 A, the device 102 includes one or more processors 190, memory 140, one or more sensors 110, a modem 170, and a radio frontend (RFE) 172. The RFE 172 includes transmit and receive circuitry, such as one or more amplifiers, one or more filters, one or more oscillators, gain control circuitry, ananalog-to-digital converter (ADC), a digital-to-analog converter (DAC), etc. The RFE 172 is coupled to one or more antennas 174 and to the modem 170. The modem 170 and the RFE 172 are configured to cooperate to receive transmissions 178 including encoded data for decoding by the ML codec 134, to send transmissions 178 including encoded data encoded by the ML codec 134 to one or more other devices, or both.

[0110] In FIG. 1 A, the sensor(s) 110 include one or more location sensors 112, one or more microphones ("mic(s)") 114, one or more cameras 116, other sensors, or a combination thereof. The sensors 110 are configured to provide sensor data 118 to the processors 190. The sensor data 118 can include data for transmission to another device, such as audio data representing sounds detected by the microphone(s) 114, images (e.g., video) captured by the cameras 116, location data from the location sensors 112, etc.[OHl] In FIG. 1 A, the memory 140 includes parameters 142 of the ML codec 134, channel condition data 144, mapping data 146, other data 148, or combinations thereof. The parameters 142 of the ML codec 134 include link weights and biases used by various layers of the ML codec 134 to encode or decode input data. In some embodiments, the parameters 142 can also specify other trainable or adaptable aspects of the ML codec 134, such as kernel dimensions, probability distributions, codebooks, etc. In a particular aspect, the codec updater 132 is configured to select, determine, or otherwise obtain a set of parameters 142 for particular channel conditions as indicated by the channel condition data 144.

[0112] The channel condition data 144 characterizes conditions of one or more channels 176, such as a channel 176A between the device 102 and one or more of the network devices 182, a channel 176B between the device 102 and one or more of the endpoint devices 180, a channel 176C between one or more of the endpoint devices 180 and one or more of the network devices 182, or channels between respective endpoint devices 180 or network devices 182.

[0113] The mapping data 146 includes, for example, information associating particular channel conditions to corresponding parameters 142. Additionally, or alternatively, the mapping data 146 can include information mapping particular parameters 142 (e.g.,representative parameters 142) to a corresponding codebook index, as described further with reference to FIG. 14.

[0114] In some embodiments, the other data 148 includes data exchanged via transmissions 178 over one or more of the channels 176. For example, during a communication session, a portion of the other data 148 may be encoded by the ML codec 134 and sent, via the channel 176B to one of the endpoint devices 180 or via the channel 176A to one of the network devices 182. Additionally, or alternatively, during the communication session, a portion of the other data 148 may be received, via the channel 176B from one of the endpoint devices 180 or via the channel 176A from one of the network devices 182, decoded by the ML codec 134, and stored at the memory 140 for playback. In this context, a communication session refers to any bidirectional or unidirectional exchange of data.

[0115] The other data 148 can also, or alternatively, include training data used by the codec updater 132 to facilitate adaptation of the parameters 142 of the ML codec 134. For example, the other data 148 can include samples of relevant data (e.g., audio data if the ML codec 134 is used to encode and decode audio data, image data if the ML codec 134 is used to encode and decode image data, etc.). In this example, the codec updater 132 can perform machine-learning training operations using training data samples from among the other data 148 and based on channel conditions experienced at the device 102 or at one or more other devices.

[0116] In FIG. 1 A, the processor(s) 190 include a channel condition estimator 130, a codec updater 132, and the ML codec 134. The ML codec 134 includes an encoder 136, a decoder 138, or both. The encoder 136 is configured to encode data for transmission to another device (e.g., one of the endpoint devices 180 or one of the network devices 182) or for storage at the memory 140. The decoder 138 is configured to decode encoded data retrieved from the memory 140 or received from another device.

[0117] The channel condition estimator 130 is configured to characterize channel conditions associated with transmissions 178 between the device 102 and one or more remote devices (e.g., the endpoint devices 180 and / or the network devices 182) orbetween two or more of the remote devices (e.g., between two endpoint devices 180 or between an endpoint device 180 and a network device 182). The channel conditions are indicative of data rates, data losses, data delays, a temporal distribution of data losses, a temporal distribution of data delays, etc.

[0118] In a particular aspect, the channel condition estimator 130 is configured to determine channel condition data 144 characterizing channel conditions associated with a particular channel (e.g., one or more of the channels 176) based on channel metrics 152. The channel metrics 152 can include measurements associated with one or more Open System Interconnect (OSI) model abstraction layers, such as physical layer measurements (e.g., signal-to-noise metrics, signal strength, bit error rate (BER), etc.), data link layer measurements (e.g., frame error rate, data throughput, etc.), network layer measurements (e.g., packet loss rate), etc. In FIG. 1A, the channel metrics 152 are illustrated as received at the processors 190 from the RFE 172; however, in some cases, one or more of the channel metrics 152 can be generated by the modem 170, by the channel condition estimator 130, or by the sensors 110. In some cases, the channel metrics 152, or portion thereof, can be received from another device (e.g., one of the endpoint devices 180 and / or one of the network devices 182).

[0119] The codec updater 132 is configured to obtain updated parameters 142 of the ML codec 134 based on the channel condition data 144. As used herein, "adapting" the parameters 142 of the ML codec 134 can include training the ML codec 134, retraining the ML codec 134, or selecting updated parameters from among a set of available parameters 142. For example, the codec updater 132 can include an ML trainer that is configured to perform operations such as providing training data (e.g., a portion of the other data 148) as input to the ML codec 134, comparing output of the ML codec 134 to expected output, and using ML optimization techniques (e.g., gradient descent backpropagation) to adapt the parameters 142 to reduce error between the output of the ML codec 134 and the expected output. As another example, the codec updater 132 may compare the channel condition data 144 to mapping data 146 to determine particular parameters 142 that are well suited for the channel conditions. In some examples, the codec updater 132 may perform ML optimization and use results of the ML optimization (e.g., parameters 142 resulting from training the ML codec 134) to selectparticular parameters 142 using the mapping data 146, as described further with reference to FIG. 14.

[0120] The device 102 can include a network device (e.g., a server, an edge device, etc.) or an endpoint device (e.g., a computer, portable communication device, a wearable device, an internet of things device, a vehicle, etc.). Further, in some embodiments, one or more of the endpoint device(s) 180, one or more of the network device(s) 182, or a combination thereof, include similar components to those of the device 102. For example, one or more of the endpoint device(s) 180, one or more of the network device(s) 182, or both, can include a channel condition estimator, a codec adapter, and / or an ML codec.

[0121] Depending on the specific embodiment, the device 102 can be configured to operate in one of various modes. In some embodiments, the device 102 is configured to, during a communication session with one or more remote devices (e.g., one of the endpoint devices 180, one of the network devices 182, or both), obtain channel condition data 144 associated with a channel 176 associated with the communication session. In some such embodiments, the device 102 is configured to use the codec updater 132 to adapt the parameters 142 of the ML codec 134 during or after the communication session to improve operation of the ML codec 134 under the particular channel conditions. Various techniques for adapting the parameters 142 based on the channel condition data 144 are described with reference to FIGS. 13-15, including, for example training or retraining the ML codec 134 and / or selecting updated parameters 142 based on the mapping data 146.

[0122] The updated parameters 142 include parameters of the decoder 138 of the ML codec 134, parameters of the encoder 136 of the ML codec 134, or both. For example, in such embodiments, the codec updater 132 of the device 102 can determine parameters 142 of the decoder 138 of the ML codec 134 to enable the decoder 138 to more reliably decode received data under the particular channel conditions. To illustrate, the particular channel conditions may be associated with a particular bit error rate or a particular distribution of bit errors. In this example, bit errors associated with received encoded data may introduce decoding errors during decoding by the ML codec 134, andthe adapted parameters 142 of the decoder 138 can reduce the number and / or the effect of such decoding errors.

[0123] In some embodiments, the codec updater 132 of the device 102 can determine parameters 142 of the encoder 136 to enable the encoder 136 to encode data for transmission in a manner that enables more reliable reproduction of the encoded data at a receiving device and / or more efficient transmission of the encoded data (e.g., using fewer bits) under the particular channel conditions. In such embodiments, the device 102 can send the parameter data associated with the updated parameters 142 of the encoder 136 to one or more remote devices (e.g., one of the endpoint devices 180, one of the network devices 182, or both) associated with the communication session to enable the one or more remote devices to send encoded data using the updated parameters 142. For example, at the start of a communication session or during the communication session with another device, the device 102 can send parameter data (e.g., a set of sparse parameters 142 or a codebook index associated with representative parameters 142) to the other device to update the ML codec of the other device in a manner that accounts for channel conditions experienced at the device 102.

[0124] In some embodiments, the codec updater 132 of the device 102 can determine updated parameters 142 of the encoder 136 and the parameters 142 of the decoder 138. In such embodiments, parameter data associated with the updated parameters 142 of the encoder 136 can be communicated to one or more remote devices associated with the communication session for use in encoding data for transmission to the device 102. In such embodiments, the device 102 can use the parameters 142 of the decoder 138 to decode data that is encoded using the updated parameters 142 of the encoder 136.

[0125] In some embodiments, the device 102 is configured to obtain channel condition data 144 associated with a communication session between two or more remote devices (e.g., two or more of the endpoint devices 180, two or more of the network devices 182, or a combination thereof). In such embodiments, the channel condition data 144 indicate channel conditions experienced by a device distinct from the device 102 (e.g., one of the devices associated with the communication session). In some such embodiments, the device 102 is configured to use the codec updater 132 to determine updated parameters142 of the ML codec 134, during or after the communication session, and provide the updated parameters 142 to one or more of the devices associated with the communication session to improve operation of the ML codec(s) 134 of such devices under the particular channel conditions. To illustrate, the communication session can be between two of the endpoint devices 180, and the device 102 can receive channel condition data 144 indicating channel conditions experienced by one of the endpoint devices 180. In this illustrative example, the codec updater 132 determines updated parameters 142 of the ML codec 134 (e.g., the parameters 142 of the decoder 138, the parameters 142 of the encoder 136, or both), and communicates parameter data indicating the updated parameters 142 to one or both of the endpoint devices 180.

[0126] Additionally, or alternatively, in some embodiments, the device 102 may communicate the parameter data indicating the updated parameters 142 to a different device (e.g., a device that is not associated with the communication session). For example, in addition to receiving the channel condition data 144, the device 102 can receive location data from one or more devices associated with the communication session. In this example, the device 102 can store the location data and the parameter data as part of the mapping data 146. The device 102 can subsequently determine that another device is at or expected to be at a location indicated by the location data and can send the parameter data to the other device to enable an ML codec of the other device to encode and / or decode data in a manner that is appropriate for expected channel conditions at the location.

[0127] In embodiments in which the device 102 sends parameter data indicating updated parameters 142 to other devices, the device 102 can use various strategies to reduce the amount of data transmitted to describe the updated parameters 142. For example, in some embodiments, the mapping data 146 maps sets of representative parameters 142 to corresponding codebook indices, as further described with reference to FIG. 14. In this example, rather than transmitting an entire set of updated parameters 142, the device 102 can send a codebook index of a set of representative parameters 142 similar to the updated parameters 142. For example, the codec updater 132 can perform clustering operations to group sets of parameters 142 into clusters based on similarity of the parameters 142, similarity of the channel conditions associated with the parameters142, or both. In this example, the codec updater 132 can determine a cluster centroid of each cluster and can use parameters 142 corresponding to the cluster centroid as representative parameters 142 for each set of parameters 142 of the cluster. In this example, each set of representative parameters 142 corresponding to a cluster centroid can be associated with a codebook index in the mapping data 146.

[0128] In some embodiments, the codec updater 132 uses a constrained adaptation process to generate the updated parameters 142, as further described with reference to FIG. 15. For example, the adaptation process can be constrained to generate a sparse set of updated parameters 142.

[0129] Thus, the system 100 enables use of an ML codec 134 to encode and decode data over a wide range of channel conditions by updating the parameters 142 of the ML codec 134 based on channel conditions experienced by individual devices (e.g., the device 102, the endpoint devices 180, or the network devices 182). The system 100 can also communicate updated parameters 142 of the ML codec 134 efficiently using codebook indices, sparse sets of parameter data, or both.

[0130] FIG. IB illustrates an example of aspects of operation of the system 100 of FIG. 1 A according to a particular embodiment. In FIG. IB, the device 102 is configured to receive audio data 120 for encoding, by an ML codec 134 (e.g., an ML codec 134A), for transmission via the channel 176 to a remote device 184. The remote device 184 of FIG. IB also includes an ML codec (e.g., an ML codec 134B) configured to decode encoded data received from the device 102 to generate output audio data 169. The remote device 184 can include or correspond to, for example, one or more of the endpoint device(s) 180, one or more of the network device(s) 182, or both. In some embodiments, the ML codec 134A is configured to encode the audio data 120 using the parameters 142A based on channel conditions. In the same or different embodiments, the ML codec 134B is configured to decode the encoded audio data using the parameters 142B based on channel conditions. In some embodiments, the parameters 142A and the parameters 142B are identical. In other embodiments, the parameters 142 A and the parameters 142B are different from one another, or one is a subset of the other. For example, the parameters 142B can include a subset of the parameters 142 A.

[0131] In the example illustrated in FIG. IB, the device 102 includes one or more preprocessors 121, one or more feature extractors 123, and one or more encoders and / or quantizers 131 ("encoder / quantizer"). In FIG. IB, the preprocessor s) 121, the feature extractor(s) 123, and the encoders / quantizer(s) 131 are each illustrated as aspects of the ML codec 134A; however, in other embodiments, one or more of the preprocessor(s) 121, the feature extractor(s) 123, or the encoders / quantizer(s) 131 is distinct from the ML codec 134A. For example, one or more of the preprocessor s) 121 can use procedural operations (e.g., non-ML operations) in addition to or instead of ML-based operations. As another example, one or more of the feature extractor(s) 123 can use procedural operations (e.g., non-ML operations) in addition to or instead of ML-based operations. As another example, one or more of the encoders / quantizer(s) 131 can use procedural operations (e.g., non-ML operations) in addition to or instead of ML-based operations.

[0132] The preprocessor(s) 121 are optional and are omitted in some embodiments. The preprocessor(s) 121 are configured to perform one or more operations to prepare the audio data 120 for encoding. For example, in FIG. IB, the preprocessor(s) 121 include a denoiser 122 configured to reduce noise in the audio data 120. In other examples, the preprocessor(s) 121 include components configured to perform other preprocessing operations, such as audio classification, speech enhancement, voice detection, etc. In some embodiments, one or more of the preprocessor(s) 121 are ML-based and use the parameters 142, or a portion thereof, to perform their respective operations. To illustrate, the preprocessor s) 121 can include an ML-based audio enhancement component that operates using one or more of the parameters 142.

[0133] The feature extractor(s) 123 are configured to generate input data for the encoders / quantizer(s) 131, where the input data include features extracted from or generated based on the audio data 120. In some embodiments, one or more of the feature extractor(s) 123 are ML-based and use the parameters 142, or a portion thereof, to perform their respective operations. To illustrate, the feature extractor(s) 123 can include an ML-based feature extractor that operates using one or more of the parameters 142.

[0134] In FIG. IB, the feature extractor(s) 123 include a spectral envelope feature extractor 124 that is configured to generate feature data 125 representing a spectral envelope of one or more segments (e.g., frames, sub-frames, or samples) of the audio data 120. For example, the spectral envelope feature extractor 124 may generate cepstrum data, cepstral coefficients, liftered cepstrum (e.g., determined using discrete cosine transform truncation to exclude pitch information and only capture spectral envelope information), companded (e.g., log) filterbank energies (e.g., determined by applying inverse discrete cosine transform on liftered cepstrum data), filterbank energies computed by uncompanding (e.g., exp) the companded filterbank energies, a full resolution spectrum, linear prediction (LP) coefficients (e.g., determined from speech frames using an autocorrelation method (e.g., Levinson-Durbin) or a covariance method, line spectral frequencies (LSF), line spectral pairs (LSP)cepstrum data, cepstral coefficients, or other data representing the spectral envelope of the audio data 120.

[0135] In FIG. IB, the feature extractor(s) 123 also include a pitch feature extractor 156 configured to generate feature data 157 representing pitch characteristics of one or more segments (e.g., frames or samples) of the audio data 120. The pitch feature extractor 156 can generate fundamental frequency (fO) data, pitch correlation data, pitch lag data, or other frequency-domain data or time-domain data. In some embodiments, the pitch feature extractor 156 can also generate other data, such as an indication of whether speech in the audio data 120 is voiced or unvoiced. The pitch feature extractor 156 is optional and is omitted in some embodiments.

[0136] In FIG. IB, the ML codec 134A is illustrated as including two feature extractors 123 and two encoder / quantizers 131 associated in a one-to-one manner. For example, the spectral envelope feature extractor 124 is configured to provide feature data 125 to an encoder / quantizer 126, and the pitch feature extractor 156 is configured to provide feature data 157 to an encoder / quantizer 158. In other embodiments, two or more feature extractor(s) 123 generate input data for a single encoder / quantizer 131. In some embodiments, input data from a single feature extractor 123 is provided to two or more encoder / quantizer(s) 131. For example, in FIG. IB, the encoder / quantizer 126 is configured to generate encoded audio data 160 based on the feature data 125; however,in some embodiments, the encoder / quantizer 126 is configured to generate encoded audio data 160 based on the feature data 125 and the feature data 157.

[0137] In some embodiments, one or more of the encoder / quantizer(s) 131 are ML- based and use the parameters 142, or a portion thereof, to perform their respective operations. To illustrate, the encoder / quantizer 126 can include an ML-based feature extractor that operates using one or more of the parameters 142. In the example illustrated in FIG. IB, the encoder / quantizer 126 is illustrated as a feedback recurrent autoencoder that includes an encoder 127, a bottleneck 128, and a decoder 129. Optionally, the feedback recurrent autoencoder can be configured to use multiple description coding techniques (or other forward error correction techniques) to reduce the effects of packet loss or delay during transmission. The encoder 127 is configured to dimensionally reduce input data (e.g., the feature data 125) to generate a dimensionally reduced representation of the input data, which is provided to the bottleneck 128. The bottleneck 128 is configured to generate the encoded audio data 160 based on the dimensionally reduced representation of the input data. The bottleneck 128 may include, for example, one or more fully connected layers, a quantizer, a codebook, other components, or a combination thereof. The bottleneck 128 is configured to provide output data (e.g., the encoded audio data 160) to the decoder 129.

[0138] The decoder 129 is configured to dimensionally expand the output data to generate an approximate reproduction of the input data provided to the encoder 127 (e.g., the feature data 125). The decoder 129 is also configured to provide feedback based on the reproduced input data or internal states of the decoder 129 to earlier stages of the decoder 129, to the encoder 127, or both. Feedback from the decoder 129 to an earlier stage of the decoder 129, to the encoder 127, or both, improves encoding and / or decoding of the feature data 125 by enabling the encoder / quantizer 126 to account for temporal relationships in the feature data 125. For example, the feature data 125 can include a time sequence of feature vectors, with each feature vector representing a frame, a subframe, or a sample of the audio data 120. In this example, the feedback representing internal states of the decoder 129 associated with decoding a first feature vector can be provided to the encoder 127 and / or to an earlier stage of the decoder 129 to facilitate encoding and / or decoding of a second feature vector that is subsequent tothe first feature vector in the feature data 125. In some embodiments, the decoder 129 is enabled during training of the autoencoder and is optional or disabled during inference.

[0139] The encoder / quantizer 158 can correspond to or include a second feedback recurrent autoencoder or another ML-based encoder and / or quantizer that is configured to generate the encoded audio data 159 based on the feature data 157. To illustrate, the encoder / quantizer 158 can include a feedforward neural network, a convolutional neural network, a self-attention network, or combinations or variants thereof.

[0140] In some embodiments, one or more of the encoders / quantizer(s) 131 is configured to use procedural (in addition to or instead of ML-based) operations to generate encoded audio data. For example, the encoders / quantizer 158 can be configured to generate the encoded audio data 159 based on the feature data 157 using a non-ML process. To illustrate, the encoder / quantizer 158 can include a quantizer configured to perform single-stage or multistage vector quantization. Additionally, or alternatively, one or more of the encoders / quantizer(s) 131 can be configured to perform forward error correction operations to reduce the effect of lost or delayed packets including the encoded audio data 159, 160. For example, the forward error correction operations can include using multiple description coding or full redundancy.

[0141] The device 102 is configured to transmit the encoded audio data 160, 159, via the channel 176, to the remote device 184. In some aspects, the encoded audio data 160, 159 corresponds to the encoded data 150 of FIG. 1A. The remote device 184 includes the ML codec 134B, one or more aspects of which may be configured to use the parameters 142 based on channel conditions representing the channel 176 to process encoded audio data received from the device 102. For example, in FIG. IB, the ML codec 134B includes one or more decoders and / or dequantizers 133 ("decoder / dequantizer(s)") and a neural synthesizer 166. In this example, one or more of the decoder / dequantizer(s) 133, the neural synthesizer 166, or a combination thereof, can use the parameters 142.

[0142] The decoder / dequantizer(s) 133 are configured to decode and / or dequantize the encoded audio data 160, 159. For example, in FIG. IB, the ML codec 134B includes adecoder / dequantizer 162 configured to decode and / or dequantize the encoded audio data 160, and a decoder / dequantizer 164 configured to decode and / or dequantize the encoded audio data 159. Each of the decoder / dequantizer(s) 133 is configured to substantially or approximately reverse operations performed by a corresponding encoder / quantizer 131 of the ML codec 134A. For example, in FIG. IB, the decoder / dequantizer 162 includes a decoder 163 of a feedback recurrent autoencoder. In some aspects, the decoder 163 is based on (e.g., is a copy of) the decoder 129.

[0143] In some embodiments, one or more of the decoder / dequantizer(s) 133 includes an ML-based decoder / dequantizer that is configured to decode the encoded audio data 160, 159 using the parameters 142 based on channel conditions, as described with reference to FIG. 1 A. In some embodiments, one or more of the decoder / dequantizer(s) 133 is configured to use procedural (in addition to or instead of ML-based) operations to decode encoded audio data. For example, the decoder / dequantizer 164 can be configured to decode the encoded audio data 159 using a non-ML process.

[0144] In FIG. IB, the remote device 184 also includes a neural synthesizer 166 configured to process output data 165 from the decoder / dequantizer(s) 133 to generate reconstructed audio data 167 approximating the audio data 120. The neural synthesizer 166 can include or correspond to any machine learning based audio or speech synthesizer, such as a neural homomorphic vocoder (NHV), an LPCNet network, a WaveNet network, a WaveRNN network, etc. The encoder / quantizer 158 and the decoder / dequantizer 164 are optional and are omitted in some embodiments. In some of these embodiments, the device 102 sends the feature data 157 (e.g., without encoding) and the neural synthesizer 166 generates the reconstructed audio data 167 based on the received feature data 157. In other embodiments, the device 102 does not generate or send the feature data 157, and the neural synthesizer 166 generates the reconstructed audio data 167 independently of the feature data 157.

[0145] Optionally, the reconstructed audio data 167 can be further processed, such as by a linear predictive (LP) synthesis filter 168 to generate output audio data 169. The LP synthesis filter 168 is optional and is omitted in some embodiments. In suchembodiments, the remote device 184 can use the reconstructed audio data 167 directly, or after other processing operations, to generate the output audio data 169.

[0146] FIG. 1C illustrates aspects of operation of a particular example of the remote device 184 of FIG. IB. In FIG. 1C, the remote device 184 is configured to receive the encoded audio data 159 (or the feature data 157), the encoded audio data 160, other data, or a combination thereof, via transmissions over the channel 176 from the device 102 of FIGS. 1A or IB. The remote device 184 can include or correspond to, for example, one or more of the endpoint device(s) 180, one or more of the network device(s) 182, or both. In some embodiments, the remote device 184 includes the ML codec 134B, which is configured to decode the encoded audio data 159, 160 using the parameters 142 based on channel conditions, as described with reference to FIG. 1 A.

[0147] In FIG. 1C, the neural synthesizer 166 of the ML codec 134B includes a neural homomorphic vocoder (NHV). An NHV is based on a two-state excitation model of the human vocal tract, which enables the NHV to generate audio data representing speech with high-fidelity based on low-bit rate data (e.g., the encoded audio data 160, 159, or both).

[0148] In FIG. 1C, the neural synthesizer 166 includes a neural network filter estimator 250 configured to process the output data 165 from the decoder / dequantizer(s) 133 representing features of the audio data (e.g., the audio data 120 of FIGS. 1A or IB). In some embodiments, the output data 165 includes a set of 80 log-Mel features. The neural network filter estimator 250 is configured to generate filter parameters 251 for one or more filters. In FIG. 1C, the one or more filters include a harmonic linear time variant (LTV) filter 252, a noise LTV filter 258, or both. In some embodiments, the harmonic LTV filter 252, the noise LTV filter 258, or both, are implemented in the time domain, as a convolution operation between an input signal and the filter impulse response (e.g., the filter parameters 251). In other embodiments, the harmonic LTV filter 252, the noise LTV filter 258, or both, are implemented in the frequency domain by multiplying the filter frequency response (e.g., spectrum or fast Fourier transform (FFT) of the impulse response) with the spectrum (e.g., FFT) of the input signal. Those skilled in the art will appreciate that other possibilities exist for the filterimplementations, such as cepstral domain and other representations. All such possibilities are encompassed within the scope of the present disclosure. The filter parameters 251 can include cepstrum data, frequency response data, impulse response data, difference equation coefficients, poles and zeros, etc., depending on the specific embodiment. In some embodiments, the neural network filter estimator 250 includes a neural network that is configured to use the parameters 142 to determine the filter parameters 251.

[0149] The neural synthesizer 166 of FIG. 1C includes a pulse train generator 254 coupled to the harmonic LTV filter 252. The pulse train generator 254 is configured to provide a pulse train 253 to the harmonic LTV filter 252. The pulse train 253 can be determined based on, for example, fundamental frequency data, pitch lag, a voiced / unvoiced classification, or other data derived from the encoded audio data 160, 159. The harmonic LTV filter 252 is configured to process the pulse train 253 using harmonic filter parameters of the filter parameters 251 to generate a harmonic component 255.

[0150] The neural synthesizer 166 of FIG. 1C also includes a noise generator 256 coupled to the noise LTV filter 258. The noise generator 256 is configured to generate a random noise signal 257. The noise LTV filter 258 is configured to process the random noise signal 257 using noise filter parameters of the filter parameters 251 to generate a noise component 259.

[0151] A combiner 260 is configured to combine the noise component 259 and the harmonic component 255 to generate a synthesized speech signal 261. In some embodiments, the neural synthesizer 166 is configured to convert the noise component 259, the harmonic component 255, or both, to a common domain for combining by the combiner 260. For example, if the harmonic LTV filter 252 operates in the frequency domain and the noise LTV filter 258 operates in the time domain, the neural synthesizer 166 may convert frequency domain output of the harmonic LTV filter 252 to the time domain to generate the harmonic component 255. As another example, the neural synthesizer 166 may convert the noise component 259, the harmonic component 255, or both, to a domain other than the time domain. Optionally, the synthesized speech signal261 can be further processed to generate the audio data 169. For example, in FIG. 1C, the synthesized speech signal 261 is provided to a post-filter 262 (e.g., a linear time invariant filter), the LP synthesis filter 168, or both. In some embodiments, the synthesized speech signal 261 is used directly as the audio data 169. In such embodiments, the post-filter 262 and the LP synthesis filter 168 are omitted.

[0152] FIG. ID illustrates aspects of operation of another particular example of the remote device 184 of FIG. IB. In FIG. ID, the remote device 184 is configured to receive the encoded audio data 159 (or the feature data 157), the encoded audio data 160, other data, or a combination thereof, via transmissions over the channel 176 from the device 102 of FIGS. 1A or IB. The remote device 184 can include or correspond to, for example, one or more of the endpoint device(s) 180, one or more of the network device(s) 182, or both. In some embodiments, the remote device 184 includes the ML codec 134B, which is configured to decode the encoded audio data 159, 160 using the parameters 142 based on channel conditions, as described with reference to FIG. 1 A.

[0153] In FIG. ID, the ML codec 134B includes the decoder / dequantizer(s) 133 and an example of the neural synthesizer 166. In FIG. ID, the neural synthesizer 166 of the ML codec 134B includes an LPCNet decoder. The LPCNet decoder is a low bitrate speech synthesis model that separates excitation modeling and spectral envelope modeling to improve performance. In particular, spectral envelope modeling of speech is performed using linear prediction (LP), which enables use of much of the capacity of the neural synthesizer 166 for excitation modeling. This arrangement enables the LPCNet to generate audio data representing speech with high-fidelity based on low-bit rate data (e.g., the encoded audio data 160, 159, or both).

[0154] The neural synthesizer 166 includes a frame rate network 270, a sample rate network 272, a linear prediction coefficient (LPC) estimator 274, a linear predictor 276, a sampler 278, and a combiner 280. The parameters 142 can correspond to or include parameters of any of the decoder / dequantizer(s) 133, the frame rate network 270, or the sample rate network 272. In some embodiments, the parameters 142 can optionally also include parameters of the LPC estimator 274, the linear predictor 276, the sampler 278, or a combination thereof.

[0155] The LPC estimator 274 is configured to process output data 165 from the decoder / dequantizer(s) 133 to generate LP coefficients 275. The LP coefficients 275 are provided to the linear predictor 276. The linear predictor 276 is configured to model speech as the output of a linear filter that predicts a current sample (corresponding to LP data 277) based on previous samples (represented by a feedback signal 285) and the LP coefficients 275.

[0156] The frame rate network 270 is configured to process output data 165 from the decoder / dequantizer(s) 133 to generate conditioning features 271 that are held constant for the duration of each frame. The frame rate network 270 can include various ML layers, such as two or more convolution layers coupled in a residual connection arrangement to one or more fully connected layers.

[0157] The sample rate network 272 is configured to generate a probability distribution 279 of an excitation signal (e.g., an LP residual signal) based on the conditioning features 271, the LP data 277, the feedback signal 285, and a feedback signal 283 (representing a previously sampled excitation signal). In a particular embodiment, the sample rate network 272 is configured to combine various input vectors to generate an embedding vector, which is processed by recurrent layers (e.g., gated recurrent units), one or more fully connected (FC) layers (e.g. dual FC layers), and a softmax layer to generate the probability distribution 279.

[0158] The probability distribution 279 of the excitation signal is sampled by the sampler 278 to generate an excitation signal 281. The excitation signal 281 and the LP data 277 are combined by the combiner 280 to generate the audio data 169. FIG. 2 illustrates an example 200 of particular aspects of operations associated with the device 102 of FIG. 1 A according to a particular embodiment. In particular, the example 200 of FIG. 2 represents operations that the device 102 can perform to improve performance of the decoder 138 of the ML codec 134 of the device 102 based on channel conditions experienced at the device 102.

[0159] In some embodiments, the operations represented in FIG. 2 can be performed by the device 102 independently of whether an encoder used to send encoded data to thedevice 102 is updated based on the channel conditions experienced at the device 102. For example, during a communication session between the device 102 and another device (e.g., one of the endpoint devices 180 of FIG. 1A), the other device can encode data for transmission using an encoder of an ML codec, and the device 102 can decode the encoded data using the decoder 138 of the ML codec 134. In this example, the operations described with reference to FIG. 2 can be used to update the decoder 138 of the device 102 whether or not the encoder used by the other device is updated.

[0160] FIG. 2 illustrates the channel condition estimator 130, the codec updater 132, and the ML codec 134, each of which is configured as described with reference to FIG. 1 A. In FIG. 2, the ML codec 134 includes at least the decoder 138.

[0161] In the example 200, the channel condition estimator 130 is configured to determine the channel condition data 144 based on the channel metrics 152, encoded data 202 A received from another device, or a combination thereof. For example, the channel metrics 152 can include signal -to-noise metrics, signal strength, BER estimates (e.g., LLRs), frame error rate, data throughput, packet loss metrics, other metrics representing channel conditions associated with one or more communication sessions, or temporal distribution data associated with these or other metrics. As another example, the encoded data 202 A can represent data as received at the device 102, which may differ from data transmitted over a channel to the device 102 due to losses, interference, or other channel effects. In this example, the channel condition estimator 130 can compare the encoded data 202 A as received at the device 102 to the data transmitted over the channel to the device 102 to determine at least a portion of the channel condition data 144. Various techniques to determine the data transmitted over the channel (e.g., transmitted data) are described with reference to FIGS. 9-11.

[0162] The codec updater 132 is configured to generate or otherwise obtain updated parameters 142 of the ML codec 134 based on the channel condition data 144. For example, in some embodiments, the codec updater 132 includes an ML trainer that is configured to train the ML codec 134 based on the channel condition data 144. To illustrate, in such embodiments, the ML trainer may be configured to encode training data using the ML codec 134 to generate encoded data, modify the encoded data in amanner representative of effects of the channel conditions indicated by the channel condition data 144, provide the modified encoded data as input to the decoder 138 to generate output data, compare the output data to the training data, and use ML optimization techniques (e.g., gradient descent backpropagation) to adapt the parameters 142 of the ML codec 134 to reduce differences between the output data and the training data. In some such embodiments, modifying the encoded data in a manner representative of effects of the channel conditions indicated by the channel condition data 144 can include, for example, dropping or modifying portions of the encoded data to simulate data lost or corrupted during transmission over the channel. In some embodiments, instead of or in addition to training the ML codec 134, the codec updater 132 can be configured to compare the channel condition data 144 to mapping data (e.g., the mapping data 146 of FIG. 1A) to determine particular parameters 142 that are well suited for the channel conditions. For example, the codec updater 132 can check the mapping data 146 for appropriate parameters 142 of the ML codec 134 for the particular channel condition data 144, and if no appropriate parameters 142 are identified in the mapping data 146 can generate the parameters 142 using ML training techniques.

[0163] The updated parameters 142 from the codec updater 132 can be used to update the ML codec 134 or a portion thereof (e.g., the decoder 138). The ML codec 134 can then use the updated parameters 142 to decode encoded data 202B received during the communication session or during a subsequent communication session. For example, the encoded data 202B can be provided to the decoder 138 to generate decoded data 204. In this example, the encoded data 202B can correspond to or include the encoded data 202A used to generate the channel condition data 144. Alternatively, the encoded data 202B can be distinct from the encoded data 202A. To illustrate, the encoded data 202A can be received from a first device during a first communication session, and the encoded data 202B can be received from the first device later in the first communication session. As another illustrative example, the encoded data 202A can be received from the first device during the first communication session, and the encoded data 202B can be received from the first device or a second device during a second communication session.

[0164] In FIG. 2, the updated parameters 142 are only used to update the ML codec 134 at one device (e.g., the device 102). For example, only the parameters 142 of the decoder 138 may be updated. In this example, an encoder used at another device to generate the encoded data 202 is not updated based on the channel condition data 144; however, updating the parameters 142 of the decoder 138 enables the decoder 138 to decode the encoded data 202 with higher fidelity because the updated parameters 142 are based on the specific delays, data losses, and other influences of the channel conditions experienced at the decoder 138.

[0165] FIG. 3 illustrates an example 300 of aspects of operations associated with the device 102 of FIG. 1A according to a particular embodiment. In particular, the example 300 of FIG. 3 represents operations that the device 102 can perform to improve performance of the encoder 136 and the decoder 138 of the ML codec 134 of the device 102 based on channel conditions experienced at the device 102.

[0166] In some embodiments, the operations represented in FIG. 3 can be performed by the device 102 independently of whether an encoder used to send encoded data to the device 102 is updated based on the channel conditions experienced at the device 102. For example, during a communication session between the device 102 and another device (e.g., one of the endpoint devices 180 of FIG. 1A), the other device can encode data for transmission using an encoder of an ML codec, and the device 102 can decode the encoded data using the decoder 138 of the ML codec 134. In this example, the operations described with reference to FIG. 3 can be used to update the encoder 136 and the decoder 138 of the device 102 whether or not the encoder used by the other device is updated.

[0167] FIG. 3 illustrates the channel condition estimator 130, the codec updater 132, and the ML codec 134, each of which is configured as described with reference to FIG. 1 A. In FIG. 3, the ML codec 134 includes the encoder 136 and the decoder 138.

[0168] In the example 300, the channel condition estimator 130 is configured to determine the channel condition data 144 based on the channel metrics 152, encoded data 302 A received from another device, or a combination thereof. As described above,the channel metrics 152 can include signal -to-noise metrics, signal strength, BER estimates (e.g., LLRs), frame error rate, data throughput, packet loss metrics, other metrics representing channel conditions associated with one or more communication sessions, or temporal distribution data associated with these or other metrics. The encoded data 302 A represents data as received at the device 102, which may differ from data transmitted over a channel to the device 102 due to losses, interference, or other channel effects, and the channel condition estimator 130 can compare the received data (e.g., the encoded data 302 A) and the transmitted data to determine at least a portion of the channel condition data 144, as further described with reference to FIGS. 9-11.

[0169] The codec updater 132 is configured to generate or otherwise obtain updated parameters 142 of the ML codec 134 based on the channel condition data 144 as described with reference to FIG. 2. For example, the codec updater 132 can use ML training techniques, mapping data, or both, to determine the updated parameters 142. The updated parameters 142 from the codec updater 132 can be used to update the ML codec 134 (e.g., the encoder 136 and the decoder 138 of the ML codec 134). The ML codec 134 can then use the updated parameters 142 to encode and / or decode data associated with a communication session.

[0170] For example, the decoder 138 can use updated decoder parameters of the parameters 142 to decode encoded data 302B to generate decoded data 304. In this example, the encoded data 302B can include or correspond to the encoded data 302 A, can be distinct from the encoded data 302 A, can be received from the same remote device that send the encoded data 302 A, can be received during the same communication session as the encoded data 302A, or can be from a distinct device and / or communication session from the encoded data 302A.

[0171] As another example, the encoder 136 can use updated encoder parameters of the parameters 142 to encode data 306 to generate encoded data 302C for transmission to another device via the channel.

[0172] In FIG. 3, the updated parameters 142 are used to update the ML codec 134 at one device (e.g., the device 102). For example, the parameters 142 of the encoder 136and the decoder 138 of the device 102 are updated. In this example, an encoder used at another device to generate the encoded data 302A and 302B is not updated based on the channel condition data 144; however, updating the parameters 142 of the ML codec 134 enables the ML codec 134 to encode and decode data in a manner that better accounts for the specific delays, data losses, and other influences of the channel conditions experienced at the device 102.

[0173] FIG. 4A illustrates an example 400 of particular aspects of operations associated with a first device 402A and a second device 402B, either of which can correspond to or include the device 102 of FIG. 1 A and the other can correspond to or include an endpoint device 180 or a network device 182 of FIG. 1A according to a particular embodiment. In particular, the example 400 of FIG. 4 A represents operations that can be performed at the first device 402A and the second device 402B to improve performance of ML codecs 134 of both of the devices 402 based on channel conditions experienced at the first device 402A.

[0174] In FIG. 4 A, the first device 402 A includes the channel condition estimator 130, the codec updater 132, and an ML codec 134A, each of which is configured as described with reference to FIG. 1 A. Further, in FIG. 4 A, the second device 402B includes an ML codec 134B, which corresponds to an instance of the ML codec 134 of FIG. 1 A. At initiation of a communication session over the channel 176, the ML codec 134B of the second device 402B may use the same or different parameters 142 as the ML codec 134A of the first device 402A.

[0175] In the example 400, the channel condition estimator 130 is configured to determine the channel condition data 144 experienced at the first device 402 A based on the channel metrics 152, encoded data 404A received from the second device 402B, or a combination thereof. The codec updater 132 is configured to generate or otherwise obtain updated parameters 142 based on the channel condition data 144, as described with reference to FIG. 2. For example, the codec updater 132 can use ML training techniques, mapping data, or both, to determine the updated parameters 142. The first device 402 A can send parameter data 410 indicating the updated parameters 142 or a portion thereof (e.g., updated parameters 142 for the encoder 136B) to the seconddevice 402B via the channel 176. Additionally, the ML codec 134A of the first device 402A can be updated based on the updated parameters 142. For example, decoder parameters of the decoder 138A of the ML codec 134A can be updated based on the updated parameters 142.

[0176] After the second device 402B receives the parameter data 410, at least the encoder 136B of the ML codec 134B of the second device 402B can be updated. The second device 402B can subsequently use the updated encoder 136B to encode data 412 for transmission via the channel 176 to the first device 402A as encoded data 404B, and the first device 402 A can use the updated decoder 138A to decode the encoded data 404B to generate decoded data 406. The encoded data 404B can be sent during the communication session in which the channel condition data 144 was generated or during a subsequent communication session. For example, in some embodiments, the parameters 142 can be updated based on the channel condition data 144 after the communication session to avoid resource limitations associated with the first device 402A. In this example, the updated parameters 142 of the decoder 138A can be used by the first device 402A during subsequent communication sessions unless further updates are made (e.g., due to changing channel conditions at the first device 402A). Similarly, in this example, the second device 402B can use the updated encoder 136B during subsequent communication sessions with the first device 402A or with another device near a particular location at which the first device 402A received the encoded data 404A unless further updates are made.

[0177] In some embodiments, the devices 402 revert to default parameters 142 when the communication session ends or when a new communication session is initiated. In such embodiments, the updated parameters 142 can be stored at a memory of the first device 402A, the second device 402B, or both, and retrieved for use during a subsequent communication session based on detecting the same or similar channel conditions in the subsequent communication session.

[0178] In FIG. 4 A, the updated parameters 142 are used to update the ML codecs 134 at two or more devices (e.g., the first device 402A, the second device 402B, and optionally at one or more additional devices participating in the communication session). Updatingthe parameters 142 of the ML codecs 134 enables the ML codecs 134 to encode and decode data in a manner that better accounts for the specific delays, data losses, and other influences of the channel conditions experienced at the first device 402A.

[0179] FIG. 4B illustrates an example 450 of particular aspects of operations associated with a first device 452A and a second device 452B, either of which can correspond to or include the device 102 of FIG. 1 A and the other can correspond to or include an endpoint device 180 or a network device 182 of FIG. 1A according to a particular embodiment. In particular, the example 450 of FIG. 4B represents operations that can be performed at the first device 452A and the second device 452B to improve performance of ML codecs 134 of one or both of the devices 452 based on channel conditions experienced at a radio frontend of the second device 452B.

[0180] In FIG. 4B, the first device 452 A includes the channel condition estimator 130, the codec updater 132, and an ML codec 134A, each of which is configured as described with reference to FIG. 1 A. Further, in FIG. 4B, the second device 452B includes an ML codec 134B, which corresponds to an instance of the ML codec 134 of FIG. 1 A. At initiation of a communication session over the channel 176, the ML codec 134B of the second device 452B may use the same or different parameters 142 as the ML codec 134A of the first device 452A.

[0181] In the example 450, the channel condition estimator 130 is configured to obtain data indicating channel conditions experienced at a radio frontend of the second device 452B. For example, the second device 452B can transmit the channel metrics 152 to the first device 452 A. The channel condition estimator 130 provides the channel condition data 144 indicating the channel conditions to the codec updater 132.

[0182] The codec updater 132 is configured to generate or otherwise obtain updated parameters 142 based on the channel condition data 144, as described with reference to FIG. 2. For example, the codec updater 132 can use ML training techniques, mapping data, or both, to determine the updated parameters 142. The first device 452A can send parameter data 460 indicating the updated parameters 142 or a portion thereof (e.g., updated parameters 142 for the decoder 138B) to the second device 452B via thechannel 176. Optionally, the ML codec 134A of the first device 452A can be updated based on the updated parameters 142. For example, encoder parameters of the encoder 136A of the ML codec 134A of the first device 452A can be updated based on the updated parameters 142.

[0183] In some embodiments, after the second device 452B receives the parameter data 460, at least the decoder 138B of the ML codec 134B of the second device 452B can be updated. The second device 452B can subsequently use the updated decoder 138B to decode encoded data 454B received via transmissions over the channel 176 to generate decoded data 456. For example, in the example illustrated in FIG. 4B, the encoder 136A of the first device 452A can encode data 462 to generate the encoded data 454B, which the first device 452A transmits to the second device 452B over the channel 176.Optionally, the encoder 136A can use updated parameters 142 to encode the data 462.

[0184] In the example illustrated in FIG. 4B, the encoded data 454B is shown as received from the first device 452 A; however, the decoder 138B (updated based on the parameter data 460) can also, or alternatively, be used to decode encoded data 454B received from one or more other devices. For example, the first device 452A can include a server that is configured to provide updated parameters 142 to other devices (e.g., end point devices) that used the updated parameters 142 to encode and / or decode data. In such examples, the first device 452A may not include an instance of the ML codec 134A.

[0185] The second device 452B can receive the encoded data 454B (from the first device 452A or another device) during the same communication session in which the second device 452B experienced the channel conditions associated with the channel metrics 152 or during a subsequent communication session. For example, in some embodiments, the parameters 142 can be updated based on the channel condition data 144 after the communication session associated with the channel metrics 152 to avoid resource limitations associated with the first device 452A.

[0186] In some embodiments, one or both of the devices 452 revert to default parameters 142 when the communication session associated with the channel metrics152 ends or when a new communication session is initiated. In such embodiments, the updated parameters 142 can be stored at a memory of the first device 452 A, the second device 452B, or both, and retrieved for use during a subsequent communication session based on detecting the same or similar channel conditions in the subsequent communication session.

[0187] In FIG. 4B, the updated parameters 142 are used to update the ML codecs 134 at one or more devices (e.g., the first device 452 A, the second device 452B, and optionally at one or more additional devices participating in the communication session). Updating the parameters 142 of the ML codecs 134 enables the ML codecs 134 to encode and / or decode data in a manner that better accounts for the specific delays, data losses, and other influences of the channel conditions experienced at the second device 452B.

[0188] FIG. 5 illustrates an example 500 of particular aspects of operations associated with a first device 502A, a second device 502B, and a third device 502C, any of which can correspond to or include the device 102 of FIG. 1 A according to a particular embodiment. In particular, the example 500 of FIG. 5 represents operations that can be performed at the devices 502 to improve performance of ML codecs 134 of the first device 502A, the second device 502B, or both, based on channel conditions experienced at the first device 502A.

[0189] In FIG. 5, the third device 502C includes the channel condition estimator 130 and the codec updater 132, the first device 502A includes an ML codec 134A, and the second device 502B includes an ML codec 134B. The channel condition estimator 130, the codec updater 132, and the ML codecs 134A and 134B can be configured as described with reference to FIG. 1 A. In a particular embodiment, at initiation of a communication session between the first device 502A and the second device 502B over a channel 576 A, the ML codec 134B of the second device 502B may use the same or different parameters (e.g., parameters 142 of FIG. 1 A) as the ML codec 134A of the first device 502A.

[0190] In the example 500, the channel condition estimator 130 is configured to obtain the channel metrics 152 via one or more transmissions over a channel 576B from thefirst device 502A and to generate the channel condition data 144 based on the channel metrics 152. Alternatively, the first device 502A can include the channel condition estimator 130, which generates the channel condition data 144 and sends the channel condition data 144 to the third device 502C. In some embodiments, the first device 502A sends both the channel metrics 152 and the channel condition data 144 to the third device 502C.

[0191] The codec updater 132 is configured to generate or otherwise obtain updated ML codec parameters based on the channel condition data 144 as described with reference to FIG. 2. For example, the codec updater 132 can use ML training techniques, mapping data, or both, to determine the updated ML codec parameters. The third device 502C can send parameter data 510 indicating the updated ML codec parameters or a portion thereof (e.g., updated decoder parameters) to the first device 502A. Optionally, the third device 502C can send the parameter data 510 indicating the updated ML codec parameters or a portion thereof (e.g., updated encoder parameters) to the second device 502B. The ML codec 134A of the first device 502A, and optionally the ML codec 134B of the second device 502B can be updated based on the parameter data 510.

[0192] In embodiments in which both of the ML codecs 134 are updated based on the parameter data 510, the second device 502B can subsequently use the updated encoder 136B to encode data 512 for transmission via the channel 576A to the first device 502A as encoded data 504, and the first device 502A can use the updated decoder 138A to decode the encoded data 504 to generate decoded data 506. In embodiments in which the parameter data 510 is only sent to the first device 502A, the ML codec 134A is updated based on the parameter data 510, and the second device 502B can subsequently use the encoder 136B (without updates) to encode data 512 for transmission via the channel 576A to the first device 502A as encoded data 504. The first device 502A can use the updated decoder 138A to decode the encoded data 504 to generate decoded data 506.

[0193] In FIG. 5, determining the parameter data 510 representing updated parameters of one or more of the ML codecs 134 at the third device 502C conserves resources (e.g., power, processing time, memory, etc.) of the first device 502A and the second device502B. In some embodiments, determining updated parameters of the ML codec(s) 134 can involve resource intensive operations, such as ML training. In such embodiments, offloading the resource intensive operations can provide significant benefit to the first device 502A, the second device 502B, or both, by enabling the ML codec(s) 134 to be updated to encode and decode data in a manner that better accounts for the specific delays, data losses, and other influences of the channel conditions experienced at the first device 502A without the burden of performing ML training. For example, the third device 502C can include a network device (e.g., one of the network device(s) 182 of FIG. 1 A), which can include or have access to significant computing resources (e.g., power, processing capacity, and / or memory). In this example, the first device 502A, the second device 502B, or both, can correspond to endpoint devices (e.g., one of the endpoint device(s) 180 of FIG. 1A), which are more resource constrained than the third device 502C. To illustrate, the first device 502A, the second device 502B, or both, can include a portable or mobile device, such as a smart phone, a portable computer (e.g., a notebook computer or tablet), a wearable device, or a computer integrated within a vehicle. Such devices are often battery powered and may have limited available computing capabilities. Thus, offloading updating of ML codec parameters from such devices can improve the functionality of the ML codec for specific channel conditions encountered by the devices without straining or over burdening the computing resources of the devices.

[0194] FIG. 6 illustrates an example 600 of particular aspects of operations associated with a first device 602A and a second device 602B, either of which can correspond to or include the device 102 of FIG. 1A and the other can correspond to the 180 or 182 of FIG. 1A according to a particular embodiment. In particular, the example 600 of FIG. 6 represents operations that can be performed at the devices 602 to improve performance of ML codecs 134 of the devices 602 based on information descriptive of channel condition and location associated with one or both of the devices 602.

[0195] In FIG. 6, the first device 602 A includes the channel condition estimator 130, the codec updater 132, the mapping data 146, and an ML codec 134 A. The second device 602B of FIG. 6 is optional, and if present, includes at least an ML codec 134B. The channel condition estimator 130, the codec updater 132, the mapping data 146 andthe ML codecs 134A and 134B can be configured as described with reference to FIG. 1A.

[0196] In the example 600, the codec updater 132 is configured to determine whether the mapping data 146 includes parameters 142 for the ML codec(s) 134 associated with particular location data 606. For example, the mapping data 146 can include a plurality of entries that associate particular parameters 142 with corresponding locations. In this example, the codec updater 132 can be configured to receive the location data 606 indicating the location of one of the devices 602 (e.g., the first device 602A or the second device 602B), and to query the mapping data 146 to determine whether parameters 142 associated with the location identified by the location data 606 are available.

[0197] If the mapping data 146 includes parameters 142 associated with the location, the codec updater 132 can use the parameters 142 to update an ML codec 134 associated with the location data 606. For example, if the location data 606 indicates the location of the first device 602A, the codec updater 132 updates the ML codecs 134A based on the parameters 142. Alternatively, if the location data 606 indicates the location (or a predicted future location) of the second device 602B, the codec updater 132 can cause location-specific parameter data 610 indicating the parameters 142 to be sent to the second device 602B to update the ML codec 134B.

[0198] If the mapping data 146 does not include parameters 142 associated with the location, the codec updater 132 can determine the parameters 142 based on the channel condition data 144 from the channel condition estimator 130. As described above, the channel condition estimator 130 can determine the channel condition data 144 based on channel metrics 152, based on received encoded data 604, or both. Optionally, the channel condition estimator 130 can determine the channel condition data 144 whether or not the mapping data 146 includes the parameters 142. For example, in some embodiments, channel condition data 144 can be associated with one or more entries of the mapping data 146. In such embodiments, the codec updater 132 can obtain parameters 142 from the mapping data 146 based on the location data 606, the channel condition data 144, or both. To illustrate, the codec updater 132 can look up parameters142 based on the location data 606 and use the parameters 142 to update the ML codec(s) 134 if channel conditions indicated by the channel condition data 144 is sufficiently similar to channel conditions associated with the parameters 142 in the mapping data 146. In some embodiments, if the mapping data 146 does not include parameters 142 associated with the location data 606, the codec updater 132 can determine whether the mapping data 146 includes parameters 142 associated with sufficiently similar channel condition data 144. Thus, channel condition data 144, location data 606, or both, can be used to determine the parameters 142.

[0199] If the mapping data 146 does not include parameters 142 associated with the channel condition data 144, the location data 606, or both, the codec updater 132 can determine the parameters 142 using ML training operations as described herein. In this situation, the parameters 142 can be used to update one or more of the ML codecs 134 and may also be stored as an entry in the mapping data 146 along with the location data 606, the channel condition data 144, or both.

[0200] The first device 602 A can send the location-specific parameter data 610 to the second device 602B via a direct connection or via a routed connection. For example, the first device 602 A can broadcast the location-specific parameter data 610 such than any appropriately configured device that is nearby (e.g., the second device 602B in FIG. 6) can receive and use the location-specific parameter data 610. As another example, the first device 602 A can send the location-specific parameter data 610 to the second device 602B via a peer-to-peer communication link over the channel 176. As still another example, the first device 602 A can send the location-specific parameter data 610 to a network device (e.g., an edge device, a router, etc.). In this example, the network device can send the location-specific parameter data 610 to the second device 602B based on a determination that the location-specific parameter data 610 is relevant to the second device 602B (e.g., the second device 602B is at, or is predicted to be at, a location indicated by the location data 606).

[0201] In the example 600 of FIG. 6, the first device 602A and the second device 602B are not necessarily involved in a communication session with one another. For example, the channel condition data 144 can indicate channel conditions experienced by the firstdevice 602A during a communication session with a device other than the second device 602B. In this example, the location-specific parameter data 610 may be relevant to the second device 602B because the second device 602B is near the first device 602A and therefore is expected to experience similar channel conditions.

[0202] In some embodiments, the parameters 142 and the location-specific parameter data 610 of FIG. 6 correspond to decoder parameters of the ML codecs 134. For example, a receiving device receiving encoded data can update its decoder parameters based on the channel conditions experienced at the receiving device to improve reproduction of data at a receiving device. However, a transmitting device encoding data and sending the encoded data to another device generally needs information about the channel conditions experience by the other device in order to update encoder parameters used to encode the data in a manner that improves reproduction of data at the other device.

[0203] In FIG. 6, the first device 602 A sending the location-specific parameter data 610 to the second device 602B enables the second device 602B to update the ML codecs 134B without using resources (e.g., power, processing time, memory, etc.) required to determine updated parameters 142 of the ML codecs 134B. For example, the second device 602B need not measure channel metrics 152, determine channel condition data 144, or perform ML training to determine the parameters 142. Further, in some embodiments, resources of the first device 602A can be conserved if the mapping data 146 includes appropriate parameters 142 for the ML codecs 134A. For example, if the mapping data 146 includes parameters 142 associated with the location data 606, the channel condition data 144, or both, the codec updater 132 can determine the parameters 142 without using resource intensive ML training operations.

[0204] FIG. 7 illustrates an example 700 of particular aspects of operations associated with a first device 702A, a second device 702B, and a third device 702C, any of which can correspond to or include the device 102 of FIG. 1 A according to a particular embodiment. In particular, the example 700 of FIG. 7 represents operations that can be performed at the devices 702 to improve performance of ML codecs 134 of the first device 702A, the second device 702B, or both, based on information descriptive ofchannel condition and location associated with one or both of the devices 702A and 702B.

[0205] In FIG. 7, the third device 702C includes the channel condition estimator 130, the codec updater 132, the mapping data 146, and a location-based estimator 710. Additionally, the first device 702A includes an ML codec 134A, and the second device 702B includes an ML codec 134B. The channel condition estimator 130, the codec updater 132, the mapping data 146, and the ML codecs 134A and 134B can be configured as described with reference to FIG. 1 A.

[0206] In the example 700, the channel condition estimator 130 is configured to obtain the channel metrics 152 from the first device 702A and to generate the channel condition data 144 based on the channel metrics 152. Alternatively, the first device 702A can include the channel condition estimator 130, which generates the channel condition data 144 and sends the channel condition data 144 to the third device 702C. In some embodiments, the first device 702A sends both the channel metrics 152 and the channel condition data 144 to the third device 702C. The first device 702A may also send location data 704A associated with the first device 702A to the third device 702C. Alternatively, the third device 702C can determine the location data 704A based on other information available to the third device 702C. To illustrate, in some embodiments, the third device 702C includes a network device associated with a communication network, and the third device 702C can determine the location data 704A based on information available to the communication network, such as a signal strength of a transmission from the first device 702A at one or more access points of the communication network.

[0207] The codec updater 132 is configured to generate or otherwise obtain updated ML codec parameters based on the channel condition data 144, as described with reference to FIG. 2 or FIG. 6. For example, the codec updater 132 can use ML training techniques, the mapping data 146, or both, to determine the updated ML codec parameters. The third device 702C can send location-specific parameter data 708A indicating the updated ML codec parameters or a portion thereof (e.g., updated decoderparameters) to the first device 702A. The third device 702C can also store the locationspecific parameter data 708A as an entry in the mapping data 146.

[0208] The location-based estimator 710 is configured to obtain location data (e.g., location data 704B) associated with a device (e.g., the second device 702B) and to determine whether the mapping data 146 includes parameters 142 associated with the location data. If the mapping data 146 includes parameters 142 associated with the location data 704B, the location-based estimator 710 can cause the parameters 142 to be sent to the second device 702B as location-specific parameter data 708B. In some embodiments, the location-specific parameter data 708 of FIG. 7 correspond to decoder parameters of the ML codecs 134, as described with reference to FIG. 6.

[0209] Although the location data 704B is illustrated in FIG. 7 as sent by the second device 702B to the third device 702C, in other examples, the third device 702C can determine the location data 704B based on information available to the third device 702C (e.g., as described above with respect to determination of the location data 704A). In the example 700 of FIG. 7, the first device 702A and the second device 702B are not necessarily involved in a communication session with one another. For example, the channel condition data 144 can indicate channel conditions experienced by the first device 702A during a communication session with a device other than the second device 702B, other than the third device 702C, or both.

[0210] In FIG. 7, determining the location-specific parameter data 708 representing updated parameters of one or more of the ML codecs 134 at the third device 702C conserves resources (e.g., power, processing time, memory, etc.) of the first device 702A and the second device 702B. In some embodiments, determining updated parameters of the ML codec(s) 134 can involve resource intensive operations, such as ML training. In such embodiments, offloading the resource intensive operations can provide significant benefit to the first device 702A, the second device 702B, or both, by enabling the ML codec(s) 134 to be updated to encode and decode data in a manner that better accounts for the specific delays, data losses, and other influences of the channel conditions experienced at the first device 702A without the burden of performing ML training. For example, the third device 702C can include a network device (e.g., one ofthe network device(s) 182 of FIG. 1A), which can include or have access to significant computing resources (e.g., power, processing capacity, and / or memory). In this example, the first device 702A, the second device 702B, or both, can correspond to endpoint devices (e.g., one of the endpoint device(s) 180 of FIG. 1A), which are more resource constrained than the third device 702C. To illustrate, the first device 702A, the second device 702B, or both, can include a portable or mobile device, such as a smart phone, a portable computer (e.g., a notebook computer or tablet), a wearable device, or a computer integrated within a vehicle. Such devices are often battery powered and may have limited available computing capabilities. Thus, offloading updating of ML codec parameters from such devices can improve the functionality of the ML codec for specific channel conditions encountered by the devices without straining or over burdening the computing resources of the devices.

[0211] Further, providing the location-specific parameter data 708B to the second device 702B based on the location data 704B uses fewer resources of the third device 702C than would be used to determine the location-specific parameter data 708B based on channel conditions associated with the second device 702B. For example, rather than performing ML training operations based on the channel conditions experienced by the second device 702B, the third device 702C can look up the location-specific parameter data 708B in the mapping data 146, which is significantly less resource intensive.

[0212] FIGS. 8-12 illustrate examples of operations that can be performed to determine the channel condition data 144 or at least a portion thereof. In some embodiments, the channel condition data 144 can be determined using two or more of the various techniques described with reference to FIGS. 8-12. In each of FIGS. 8-12, two devices 102 (including a first device 102 A and a second device 102B) are participating in a communication session over a channel 176. The first device 102A includes the RFE 172 and the channel condition estimator 130. The RFE 172 in each of FIGS. 8-12 is configured to receive transmissions representing encoded data transmitted via the channel 176, and the channel condition estimator 130 is configured to determine channel condition data 144 based on data from the RFE 172. The encoded data is represented in various ways in FIGS. 8-12 to highlight particular aspects of theoperations described; however, the transmissions in each of FIGS. 8-12 correspond to radiofrequency waveforms that are modulated to represent a bitstream.

[0213] In some embodiments, the channel condition estimator 130 uses procedural techniques to determine the channel condition data 144 based on information from the RFE 172. For example, the RFE 172 can measure signal-to-noise characteristics of a transmission and provide the channel condition estimator 130 with signal-to-noise measurement data as part of the channel metrics 152. In this example, the channel condition estimator 130 can calculate (using one or more algorithms, one or more thresholds, etc.) a value of the channel condition data 144 based on the signal-to-noise measurement data.

[0214] In some embodiments, the channel condition estimator 130 uses ML techniques to determine the channel condition data 144 based on information from the RFE 172. For example, the channel condition estimator 130 can include an ML model configured to receive input data from the RFE 172 (and possibly other sources) and to generate the channel condition data 144 based on the input data. The content of the input data can be different in different embodiments.

[0215] FIG. 8 illustrates an example 800 of operations to determine the channel condition data 144 based on soft bit data 808. During the communication session in FIG. 8, the second device 102B transmits modulated bits 802 via the channel 176, and the RFE 172 of the first device 102A receives symbols 804 representing the modulated bits 802, possibly with errors, delays, or other differences introduced by the channel 176. The modulated bits 802 of FIG. 8 represent encoded data (e.g., data encoded using the encoder 136 of the ML codec 134 of FIG. 1A) and parity data (e.g., low-density parity check (LDPC) data) associated with the encoded data.

[0216] The RFE 172 of the first device 102A of FIG. 8 is configured to generate the channel metrics 152 based, at least in part, on the parity data. For example, the RFE 172 includes or is coupled to an LDPC decoder 806 that is configured to generate soft bit data 808 indicating probability estimates for bits represented by each of the symbols 804. For example, the soft bit data 808 can include log-likelihood ratios representingposterior probabilities of bit states for a plurality of bits received during the communication session.

[0217] The soft bit data 808 (and optionally other channel metrics 152) are provided to the channel condition estimator 130 which determines the channel condition data 144 based on the soft bit data 808 (and optionally the other channel metrics 152). In some embodiments, the channel condition data 144 includes bit error data 810 that indicates an estimate of bit errors associated with the communication session. For example, the bit error data 810 can include an estimate of the count, rate, or distribution of bit errors. In the example 800, the bit error data 810 is based on the soft bit data 808. For example, the channel condition estimator 130 can estimate, based on the probability estimates for bits represented by each of the symbols 804, the likely count, rate, or distribution of bit errors.

[0218] FIG. 9 illustrates an example 900 of operations to determine the channel condition data 144 based on a comparison of received bits 908 to transmitted bits 910. During the communication session in FIG. 9, the second device 102B transmits modulated bits 902 via the channel 176, and the RFE 172 of the first device 102A receives symbols 904 representing the modulated bits 902, possibly with errors, delays, or other differences introduced by the channel 176. The modulated bits 902 of FIG. 9 represent encoded data (e.g., data encoded using the encoder 136 of the ML codec 134 of FIG. 1 A) and optionally parity data associated with the encoded data.

[0219] The RFE 172 of the first device 102A of FIG. 9 is configured to generate received bits 908 based on the symbols 904. Optionally, the RFE 172 may also generate the channel metrics 152. The received bits 908 (and optionally the channel metrics 152) are provided to the channel condition estimator 130. In FIG. 9, the channel condition estimator 130 also obtains data indicating the transmitted bits 910. The transmitted bits 910 correspond to at least a subset of the modulated bits 902 transmitted by the second device 102B. For example, the modulated bits 902 can include a sequence of bits that the first device 102 A knows in advance that the second device 102B will transmit. As another example, the modulated bits 902 can include a sequence of bits that the first device 102A can determine independently of the received bits 908. To illustrate, duringthe communication session, the second device 102B can modulate and transmit a bitstream that includes a prearranged sequence of bits. In this illustrative example, the first device 102 A can include a memory storing data representing the prearranged sequence of bits. In this illustrative example, the prearranged sequence of bits can be selected from among a set of prearranged sequences specified by a communication protocol. For example, during initiation of the communication session, the first device 102 A and the second device 102B can exchange data indicating which of a set of prearranged sequences will be transmitted to facilitate channel measurements.

[0220] The channel condition estimator 130 can compare the received bits 908 to the transmitted bits 910 to determine bit error data 912 associated with the communication session. For example, the bit error data 912 can include a count, a rate, and / or a distribution of bit errors in the received bits 908 as compared to the transmitted bits 910. The channel condition data 144 can include or correspond to the bit error data 912. In some embodiments, the channel condition data 144 can also include one or more values based on the channel metrics 152.

[0221] FIG. 10 illustrates another example 1000 of operations to determine the channel condition data 144 based on a comparison of received bits 1012 and transmitted bits, which in FIG. 10 correspond to randomized bits 1014. During the communication session in FIG. 10, the second device 102B transmits modulated bits 1008 via the channel 176, and the RFE 172 of the first device 102A receives symbols 1010 representing the modulated bits 1008, possibly with errors, delays, or other differences introduced by the channel 176. In FIG. 10, the modulated bits 1008 include a set of bits determined by a bit generator 1004B. For example, the bit generator 1004B can determine the set of bits using a randomization process based on a seed value (e.g., seed 1006).

[0222] The RFE 172 of the first device 102A is configured to generate the received bits 1012 based on the symbols 1010. Optionally, the RFE 172 may also generate channel metrics 152. The received bits 1012 (and optionally the channel metrics 152) are provided to the channel condition estimator 130. The channel condition estimator 130 also obtains data indicating the set of bits generated by the bit generator 1004B. Forexample, the first device 102A includes a bit generator 1004A that is configured to generate a set of randomized bits 1014 using randomization process based on the seed 1006. The seed 1006 can be transmitted by the second device 102B to the first device 102 A, or the first device 102 A and the second device 102B can agree on the seed 1006 before the second device 102B transmits the modulated bits 1008 including the set of bits based on the seed 1006. For example, during initiation of the communication session, the first device 102 A and the second device 102B can exchange data identifying the seed 1006.

[0223] The channel condition estimator 130 can compare the received bits 1012 to the randomized bits 1014 to determine bit error data 1016 associated with the communication session. For example, the bit error data 1016 can include a count, a rate, and / or a distribution of bit errors in the received bits 1012 as compared to bits transmitted by the second device 102B, as represented by the randomized bits 1014. The channel condition data 144 can include or correspond to the bit error data 1016. In some embodiments, the channel condition data 144 can also include one or more values based on the channel metrics 152.

[0224] FIG. 11 illustrates another example 1100 of operations to determine the channel condition data 144. During the communication session in FIG. 11, the second device 102B transmits a particular bit sequence 1104 multiple times, illustrated in FIG. 11 as a first bit sequence 1104 A, a second bit sequence 1104B, and an Nth bit sequence 1104N (where N is an integer greater than two). Each of the bit sequences 1104 is identical.The RFE 172 of the first device 102A receives symbols 1106 representing the bit sequences 1104, possibly with errors, delays, or other differences introduced by the channel 176.

[0225] The RFE 172 of the first device 102A is configured to generate received bits 1108 based on the symbols 1106. Optionally, the RFE 172 may also generate channel metrics 152. The received bits 1108 (and optionally the channel metrics 152) are provided to the channel condition estimator 130. The channel condition estimator 130 includes a joint decoder 1110 configured to jointly process (e.g., decode) a set of bits corresponding to multiple of the repetitions of the bit sequence 1104 to generate jointlydecoded bits 1112. The channel condition estimator 130 also includes an individual decoder 1114 configured to individually process (e.g., decode) a set of bits corresponding to one repetition of the bit sequence 1104 to generate individually decoded bits 1116. The channel condition estimator 130 also includes a comparator 1118 configured to compare the jointly decoded bits 1112 and the individually decoded bits 1116 to determine bit error data 1120. For the comparison, the jointly decoded bits 1112 are considered to correspond to the bits transmitted by the second device 102B; whereas the individually decoded bits 1116 correspond to the received bits. Thus, differences between the jointly decoded bits 1112 and each of the individually decoded bits 1116 are considered to be bit errors.

[0226] The bit error data 1120 can include a count, a rate, and / or a distribution of bit errors in the received bits (e.g., the individually decoded bits 1116) as compared to bits transmitted by the second device 102B, as represented by the jointly decoded bits 1112. The channel condition data 144 can include or correspond to the bit error data 1120. In some embodiments, the channel condition data 144 can also include one or more values based on the channel metrics 152.

[0227] FIG. 12 illustrates an example 1200 of operations to determine the channel condition data 144. During the communication session in FIG. 12, the second device 102B transmits modulated bits representing a set of data blocks 1202 via the channel 176. The RFE 172 of the first device 102A receives symbols 1204 representing the modulated bits, possibly with errors, delays, or other differences introduced by the channel 176.

[0228] The RFE 172 of the first device 102A is configured to generate received bits 1206 based on the symbols 1204. Optionally, the RFE 172 may also generate channel metrics 152. The received bits 1206 (and optionally the channel metrics 152) are provided to the channel condition estimator 130. The channel condition estimator 130 includes a block error rate (BLER) estimator 1210 configured to determine BLER data 1212 based on the received bits 1206. The channel condition estimator 130 also includes a bit error estimator 1218 that is configured to generate estimated bit error data 1220 based on the BLER data 1212 and BLER-based bit error distributions 1214 stored in amemory of the first device 102A. For example, the bit error estimator 1218 can obtain a bit error distribution 1216 from the BLER-based bit error distributions 1214 based on the BLER data 1212. In this example, the BLER-based bit error distributions 1214 can include cumulative distribution functions representing estimates of rates and distributions of bit errors for various block error rates. Thus, the bit error distribution 1216 indicates an estimate of bit errors (e.g., a count of bit errors, a rate of bit errors, and / or a distribution of bit errors) expected to be present for a particular block error rate indicated by the BLER data 1212.

[0229] The bit error data 1220 can include an estimate of a count, a rate, and / or a distribution of bit errors in the received bits 1206 based on the BLER data 1212 and the bit error distribution 1216. The channel condition data 144 can include or correspond to the bit error data 1220. In some embodiments, the channel condition data 144 can also include one or more values based on the channel metrics 152.

[0230] FIG. 13 illustrates an example 1300 of aspects of operations that can be performed to update parameters of the ML codec 134. In some embodiments, the operations described with reference to FIG. 13 can be performed by the codec updater 132 of any of FIGS. 1A-7. For example, in some embodiments, the codec updater 132 includes a simulated channel 1310, an ML trainer 1314, and an error calculator 1320, as illustrated in FIG. 13.

[0231] In FIG. 13, the ML codec 134 is represented as a feedback-recurrent autoencoder that includes the encoder 136, the decoder 138, and a bottleneck 1304 therebetween. In FIG. 13, two instances of the decoder 138 (including decoder 138A and decoder 138B) are shown to illustrate different operations performed by the decoder 138 to update the parameters of the ML codec 134. In some embodiments, the two instances of the decoder 138 are initially identical but diverge as parameters of the ML codec 134 are updated. For example, the operations described with reference to FIG. 13 can update the decoder parameters of the decoder 138B while the decoder parameters of the decoder 138A remain unchanged. In other embodiments, the two instances of the decoder 138 are initially identical and remain identical throughout the operations described with reference to FIG. 13. For example, the decoder parameters of thedecoder 138A and the decoder parameters of the decoder 138B can be updated at the same time.

[0232] The encoder 136 is configured to receive input data to be encoded. The input data can include any type of data that is to be encoded. For example, the input data generally includes an array or vector of values or features representing any type of data that is to be stored or transmitted in an encoded (e.g., compressed) form. As one example, the input data can include audio data representing sound (e.g., speech, music, ambient sound, noise, etc.). In examples in which the input data includes audio data, the audio data can include pulse code modulation (PCM) representations; linear prediction (LP) coefficients; line spectrum pairs (LSPs); line spectrum frequencies (LSFs); speech parameters (e.g., pitch lag, pitch gain, pitch correlation, formant frequencies, etc.); cepstral coefficients (e.g., Mel-scale or Bark-scale coefficients); wavelet coefficients, other spectral or cepstral parameters, etc.

[0233] As another example, the input data can include image data. In examples in which the input data includes image data, the image data can include an individual image (e.g., a photograph or graphic), can include a sequence of images (e.g., frames of video or graphics data representing a game display, etc.), either of which can be subsampled, partitioned (e.g., into blocks or tiles), etc. The image data can represent two-dimensional or three-dimensional content. As non-limiting examples, the image data can include pixel values, motion vector values, transform coefficients (e.g., Discrete Cosine Transform (DCT) coefficients, Discrete Wavelet Transform (DWT) coefficients, or Karhunen-Loeve Transform (KLT) coefficients), geometric features, texture data, transparency data, etc.

[0234] The encoder 136 includes a plurality of layers arranged and interconnected to cause data input to the encoder 136 to be dimensionally reduced and provided to the bottleneck 1304 as dimensionally-reduced data. In some embodiments, the bottleneck 1304 is configured to output the dimensionally-reduced data as output. In other embodiments, the bottleneck 1304 is configured to perform other operations to generate output based on the dimensionally-reduced data. For example, the bottleneck 1304 canquantize the dimensionally-reduced data and output a codebook index and possibly other data (e.g., residual data) representing the dimensionally-reduced data.

[0235] In some embodiments, the ML codec 134 is a multiple description coding (MDC) codec, in which case the bottleneck 1304 generates more than one set of output data representing each set of input data. For example, in response to one input data sample (X) provided to the encoder 136, the bottleneck 1304 can generate two or more encoded data samples, where each of the two or more encoded data samples can be separately decoded to reproduce a representation (X7) of the input data sample (X) and the two or more encoded data samples can be jointly decoded to reproduce a higher fidelity representation (X 'j of the input data sample (X).

[0236] The bottleneck 1304 in FIG. 13 is also configured to provide the dimensionally- reduced data or data representing the dimensionally-reduced data (e.g., a quantized representation of the dimensionally-reduced data) to the decoder 138A. The decoder 138A is configured to dimensionally-expand data received from the bottleneck 1304 to generate output representing a reproduced version of the input data provided to the encoder 136. In the example illustrated in FIG. 13, one or more layers of the decoder 138A are configured to provide feedback 1306 to the encoder 136, to one or more prior layers of the decoder 138A, or both. The feedback 1306 can provide the encoder 136 temporal context for subsequent input data, which can enable the encoder 136 to improve encoding of the subsequent input data.

[0237] During operations to update the parameters of the ML codec 134, input data samples 1302 are provided as input to the encoder 136 of the ML codec 134. The input data samples 1302 can be obtained from a memory of a device performing the parameter update operations. For example, when the device 102 performs operations to update the parameters 142 of the ML codec 134 at the processor(s) 190, the codec updater 132 of the device 102 can obtain the input data samples 1302 from the memory 140 (e.g., from the other data 148). The encoder 136 dimensionally-reduces the input data samples 1302 and provides the dimensionally -reduced input data samples 1302 to the bottleneck 1304. The bottleneck 1304 outputs one or more encoded data samples 1308 based on the dimensionally-reduced input data samples 1302.

[0238] The simulated channel 1310 modifies the encoded data sample(s) 1308 based on the channel condition data 144 to generate one or more modified encoded data samples 1312. For example, the simulated channel 1310 can flip one or more bits of an encoded data sample 1308 in a manner indicated by bit error data of the channel condition data 144. To illustrate, the bit error data can indicate a bit error rate, and the simulated channel 1310 can flip bits of the encoded data sample(s) 1308 such that differences between the encoded data sample(s) 1308 and the modified encoded data sample(s) 1312 are characterized by the bit error rate. If the bit error data specifies a distribution of bit errors, bits can be flipped according to the distribution of bit errors; otherwise, the bits can be selected randomly. As another example, the channel condition data 144 can include packet loss data indicating a rate or distribution of lost packets, and the simulated channel 1310 can drop encoded data sample(s) 1308 such that the modified encoded data sample(s) 1312 (as compared to the encoded data sample(s) 1308) simulate the packet loss rate, the packet loss distribution, or both. The simulated channel 1310 can also, or alternatively, modify the encoded data sample(s) 1308 in other ways in order to cause the modified encoded data sample(s) 1312 to have target characteristics relative to the encoded data sample(s) 1308, where the target characteristics are indicated by the channel condition data 144.

[0239] The modified encoded data sample(s) 1312 are provided as input to the decoder 138B, which dimensionally expands the modified encoded data sample(s) 1312 to generate decoded data sample(s) 1318. Due to losses introduced by encoding operation of the ML codec 134 and errors introduced by the modification applied by the simulated channel 1310, the decoded data sample(s) 1318 approximate, but are generally not identical to, the input data sample(s) 1302.

[0240] The error calculator 1320 determines an error metric 1322 based on differences between the decoded data sample(s) 1318 and corresponding input data samples 1302. The error metric 1322 is provided to the ML trainer 1314, which generates updated parameters 1316 (e.g., updated parameters 1316A, updated parameters 1316B, or both). For example, the ML trainer 1314 can use gradient decent operations and / or other optimization techniques to update various weights, biases, or other parameters of the ML codec 134 with a goal of reducing the error metric 1322.

[0241] The updated parameters 1316B correspond to decoder parameters that can be used to update the decoder 138B. The updated parameters 1316A can include encoder parameters that can be used to update the encoder 136, decoder parameters that can be used to update the decoder 138A, or both. For example, in some embodiments, the ML trainer 1314 is configured to only update the decoder 138B, in which case the ML trainer 1314 may omit generation of the updated parameters 1316A. In such embodiments, updating the decoder 138B enables the decoder 138B to generate decoded data sample(s) 1318 that more accurately reproduce the input data samples 1302 under the particular channel conditions represented by the channel condition data 144.

[0242] In other embodiments, the ML trainer 1314 is configured to update both the encoder 136 and the decoder 138 of the ML codec 134. In such embodiments, the updated parameters 1316B are used to update the decoder 138B, and the updated parameters 1316A are used to update the encoder 136, the bottleneck 1304, the decoder 138A, or a combination thereof. In such embodiments, updating the decoder 138B enables the decoder 138B to generate decoded data sample(s) 1318 that more accurately reproduce the input data samples 1302 under the particular channel conditions represented by the channel condition data 144. Additionally, updating the encoder 136, the bottleneck 1304, the decoder 138A, or a combination thereof, enables the ML codec 134 to generate encoded data sample(s) 1308 that are more resilient to the channel conditions.

[0243] The operations described above can be repeated iteratively (e.g., for two or more batches of input data samples 1302) to refine the training of the ML codec 134. For example, the operations can be repeated until each available set of input data samples 1302 has been processed to generate updated parameters 1316 or to perform validation testing. As another example, the operations can be repeated until another stop condition is reached, such as until the error metric 1322 has a particular value, until a rate of change of the error metric 1322 satisfies a specified rate, until a specified number of iterations have been performed, etc.

[0244] In a particular embodiment, after the parameters of the ML codec 134 are updated using the operations described above, the final parameters of the ML codec 134 can be stored for local use, can be transmitted to another device, or a combination thereof. For example, final decoder parameters resulting from the operations described above can be provided to a device associated with the channel conditions described by the channel condition data 144. To illustrate, in examples 200 and 300 of FIGS. 2 and 3, the same device that measures the channel conditions uses the codec updater 132 to update its ML codec 134, in which case, the final decoder parameter resulting from the operations described with reference to FIG. 13 are used to update the decoder 138 of the device.

[0245] In example 400 of FIG. 4 A, the first device 402 A measures the channel conditions and uses its codec updater 132 to update the decoder 138A of the ML codec 134A of the first device 402A. Further, in FIG. 4A, the first device 402A sends the parameter data 410, which indicates at least updated encoder parameters for the encoder 136B of the ML codec 134B. In some embodiments, the parameter data 410 can also indicate updated decoder parameters for a decoder of the ML codec 134B.

[0246] In the example 500, the channel condition data 144 represents channel conditions experienced by the first device 502A, and the codec updater 132 operates at the third device 502C. In this example, the third device 502C send the parameter data 510 to the first device 502A to indicate at least updated decoder parameters for the decoder 138A of the ML codec 134A of the first device 502A. Optionally, in some embodiments, the third device 502C can also send the parameter data 510 to the second device 502B to enable the second device 502B to update the ML codec 134B of the second device 502B. For example, the parameter data 510 sent to the second device 502B can indicate updated encoder parameters for the encoder 136B. In some embodiments, the parameter data 510 sent to the second device 502B can also indicate updated decoder parameters for a decoder of the ML codec 134B of the second device 502B.

[0247] In example 600 of FIG. 6, the first device 602 A measures the channel conditions and uses its codec updater 132 to update parameters 142 of the encoder, parameters ofthe decoder, or both, of the ML codec 134A of the first device 602A. The first device 602A also stores the parameters 142 to the mapping data 146 and can send the locationspecific parameter data 610 indicating the parameters 142 associated with a particular location to another device (e.g., the second device 602B) based on the location or an expected future location of the second device 602B. Additionally, or alternatively, the first device 602 A can broadcast the location-specific parameter data 610 for use by devices that are within a broadcast coverage area of the first device 602A.

[0248] In example 700 of FIG. 7, the codec updater 132 of the third device 702C determines the location-specific parameter data 708 based on channel conditions experienced by a first radio frontend (e.g., of a first device 702A) at a particular location. The third device 702C can send the location-specific parameter data 708A to the first device 702A to enable the first device 702A to update the ML codec 134A of the first device 702A. Further, based on location data 704B associated with a second device 702B, the third device 702C can send location-specific parameter data 708B to the second device 702B to enable the second device 702B to update the ML codec 134B of the second device 702B.

[0249] FIG. 14 illustrates an example 1400 of aspects of operations that can be performed by the device 102 of FIG. 1 A to generate parameter data representing parameters of an ML codec. In various embodiments, the operations described with reference to FIG. 14 can be performed by the codec updater 132 of FIG. 1A. The example 1400 illustrates the ML trainer 1314, a mapping generator 1410, and the mapping data 146. FIG. 14 also illustrates a parameter space 1420 associated with the mapping data 146.

[0250] The ML trainer 1314 in FIG. 14 is configured to perform operations as described with reference to FIG. 13. For example, the ML trainer 1314 is configured to obtain an error metric 1322 (e.g., from the error calculator 1320 of FIG. 13) that is indicative of differences between one or more input data samples and one or more decoded data samples based on encoded versions of the input data sample(s) as modified based on particular channel conditions. The ML trainer 1314 can use various ML optimization techniques to modify initial parameters 1406 of an ML codec with a goal of reducingthe error metric 1322. The process of obtaining the error metric 1322 and modifying the parameters 1406 is performed iteratively until a stop condition is reached, at which point the modified parameters are output as updated parameters 1408 of the ML codec.

[0251] The updated parameters 1408 are provided to the mapping generator 1410, which is configured to generate or update the mapping data 146 based on the updated parameters 1408. In particular, in FIG. 14, the mapping generator 1410 is configured to assign the updated parameters 1408 to a cluster of sets of parameters based on commonality with other parameters of the cluster. The parameter space 1420 illustrates an example of assigning the updated parameters 1408 to a cluster. In FIG. 14, the parameter space 1420 represents a multidimensional space, where each dimension corresponds to a parameter (or a set of parameters), and a location along a particular dimension corresponds to a value of the parameter. Although the parameter space 1420 is illustrated in two dimensions, it should be understood that the parameter space 1420 typically would include tens of dimensions to millions of dimensions.

[0252] In FIG. 14, a point 1422 represents a location of the updated parameters 1408 in the parameter space 1420. Further, in FIG. 14, the point 1422 is within a region corresponding to a cluster 1424 A. The cluster 1424 A represents a set of points (where each point represents a set of parameters of the ML codec) that are near to one another in the parameter space 1420. In FIG. 14, the parameter space 1420 includes three clusters, including the cluster 1424 A, a cluster 1424B, and a cluster 1424C. The clusters 1424 can be identified using any of various clustering techniques, such as hierarchical clustering, density-based clustering, k-means clustering, etc. In some embodiments, the clusters 1424 can be identified by the mapping generator 1410 based on a large number of sets of parameters determined for various channel conditions. In other embodiments, the clusters 1424 can be pre-determined and provided to the mapping generator 1410.

[0253] In FIG. 14, the mapping generator 1410 determines a cluster 1424 to which the updated parameters 1408 are assigned (e.g., the cluster 1424A in the example illustrated), and determines a centroid 1426 of the cluster 1424. The centroid 1426 can be determined based on distances, in the parameter space 1420 between the various points assigned to the cluster 1424. For example, a centroid 1426A of the cluster 1424Ais based on locations in the parameter space 1420 of the points associated with the cluster 1424A, a centroid 1426B of the cluster 1424B is based on locations in the parameter space 1420 of the points associated with the cluster 1424B, and a centroid 1426C of the cluster 1424C is based on locations in the parameter space 1420 of the points associated with the cluster 1424C. In some embodiments, the centroids are predetermined or fixed. For example, when the clusters 1424 are pre-determined based on a large number of sets of parameters, the centroids 1426 may also be pre-determined. In other embodiments, the centroid 1426 of a cluster 1424 is updated when a new point is associated with the cluster 1424. For example, the centroid 1426A may be determined based on the point 1422 representing the updated parameters 1408 as well as other points assigned to the cluster 1424 A.

[0254] Each centroid 1426 represents a particular location in the parameter space 1420, and thus corresponds to a set of parameters of the ML codec. Based on assigning the updated parameters 1408 to a particular cluster (e.g., the cluster 1424A in FIG. 14), the mapping generator 1410 determines or identifies the centroid 1426 A of the cluster 1424A and determines centroid parameters 1412 associated with the centroid 1426A. The mapping data 146 associates each set of centroid parameters 1412 with a codebook index (e.g., an index 1414). The index 1414 associated with the centroid parameters 1412 can be used as parameter data (e.g., the parameter data or the location-specific parameter data of any of FIGS. 4-7).

[0255] The index 1414 can thus be used as a compact representation of the centroid parameters 1412, and the centroid parameters 1412 are approximations of the updated parameters 1408. Thus, using the index 1414 as parameter data significantly reduces resources used to convey ML codec parameters between devices. For example, the index 1414 can be transmitted to another device that includes mapping data (e.g., another instance of the mapping data 146), and the other device can use the centroid parameters 1412 associated with the index 1414 as updated parameters of its ML codec. To illustrate, during set up of a communication session, two devices can exchange information, which may include one or more indexes 1414, and the devices can agree to use particular ML codec parameters based on the indexes 1414.

[0256] Although FIG. 14 shows the mapping data 146 storing the centroid parameters 1412, in other examples, the mapping data 146 can store other data associated with the centroids 1426 or the clusters 1424. For example, the mapping data 146 can store information specifying boundaries of a cluster 1424 or similar information that enables the mapping generator 1410 to assign the updated parameters 1408 to a cluster 1424. In such examples, any information identifying the clusters 1424 or centroids 1426 can be stored in the mapping data 146 and associated with corresponding index values.

[0257] FIG. 15 illustrates another example 1500 of aspects of operations that can be performed by the device 102 of FIG. 1 A to generate parameter data representing parameters of an ML codec. In various embodiments, the operations described with reference to FIG. 15 can be performed by the codec updater 132 of FIG. 1A. In the example 1500, the ML trainer 1314 is configured to constrain the parameter adaptation process based on sparsity constraints 1508.

[0258] The ML trainer 1314 in FIG. 15 is configured to perform operations as described with reference to FIG. 13. For example, the ML trainer 1314 is configured to obtain an error metric 1322 (e.g., from the error calculator 1320) that is indicative of differences between one or more input data samples and one or more decoded data samples based on encoded versions of the input data sample(s) as modified based on particular channel conditions. The ML trainer 1314 can use various ML optimization techniques to modify parameters 1506 of the ML codec with a goal of reducing the error metric 1322. The process of obtaining the error metric 1322 and modifying the parameters 1506 is performed iteratively until a stop condition is reached, at which point the modified parameters are output as updated parameters 1510 of the ML codec.

[0259] In FIG. 15, during one or more iterations of the ML optimization techniques, the ML trainer 1314 enforces the sparsity constraints 1508 to cause the parameters 1506 used in a subsequent iteration, or the updated parameters 1510 output by the ML trainer 1314 to be sparse. For example, enforcing the sparsity constraints 1508 can include determining difference parameters indicating differences between the current parameters (e.g., the initial parameters) and the parameters of the most recent training iteration. The difference parameters are then discretized and entropy coded under astrong parameter update prior that assigns a high probability to zero updates. Enforcing the sparsity constraints 1508 in this manner causes the parameter updates to be sparse (e.g., capable of being represented in fewer bits than if the sparsity constraints 1508 were not enforced, such as if the difference parameters were sent as the parameter data). The updated parameters 1510 representing the sparse parameter updates can be sent as parameter data, which significantly reduces resources used to convey ML codec parameters between devices (as compared to sending unconstrained parameters).

[0260] FIG. 16 illustrates an example 1600 of aspects of operations that can be performed by the device 102 of FIG. 1A in particular embodiments. In FIG. 16, the device 102 includes, is included within, or corresponds to a vehicle 1602. For example, instances of the device 102 can be included within any or all of a first vehicle 1602 A, a second vehicle 1602B, a third vehicle 1602C, and an Mth vehicle 1602M (where M is an integer greater than three).

[0261] In the example 1600, the vehicles 1602 are traveling along a thoroughfare 1604, such as a roadway, and each of the vehicles 1602 is at a respective location along the thoroughfare 1604 and is traveling in a respective direction at a respective speed. For example, the first vehicle 1602A is at a first location traveling in a first direction at a first speed, the second vehicle 1602B is at a second location traveling in a second direction at a second speed, the third vehicle 1602C is at a third location traveling in a third direction at a third speed, the Mth vehicle 1602M is at an Mth location traveling in an Mth direction at an Mth speed. The locations of the vehicles 1602 are different; however, the speeds and directions or travel can be the same for two or more of the vehicles 1602 or can be different. For example, a single lane of the thoroughfare 1604 is illustrated; thus, all of the vehicles 1602 are illustrated as moving along a prevailing traffic flow direction of the thoroughfare 1604. However, in other examples, the thoroughfare 1604 includes multiple lanes with different traffic flow directions, and the vehicles 1602 can be traveling along any of these lanes. In some examples, the vehicles 1602 can be traveling along different throughfares that pass through or near the first location.

[0262] In the example 1600, while at or near the first location, an RFE (e.g., the RFE 172 of FIG. 1 A) of the first vehicle 1602 A experiences first channel conditions and a codec updater (e.g., the codec updater 132 of FIG. 1 A) obtains updated parameters of an ML codec (e.g., the ML codec 134) of the first vehicle 1602A based on the first channel conditions. In this example, the codec updater can obtain the updated parameters of the ML codec using the operations described with reference to any of FIGS. 13-15. The updated parameters of the ML codec of the first vehicle 1602 A enable the ML codec of the first vehicle 1602 A to encode data for transmission via a channel, to decode data received via the channel, or both, in view of the channel conditions experienced by the RFE of the first vehicle 1602 A.

[0263] In FIG. 16, the first vehicle 1602 A sends the updated parameters of the ML codec to one or more other devices based on locations of the other devices, based on expected future locations of the other devices, based on other information (e.g., geofence data or identifiers of the other devices), or a combination thereof. For example, the first vehicle 1602 A can send parameter data 1606 indicating the updated parameters of the ML codec to the second vehicle 1602B and the Mth vehicle 1602M based on locations, travel directions, and / or speeds of the second vehicle 1602B and the Mth vehicle 1602M. To illustrate, the first vehicle 1602 A can determine, based on the locations, travel directions, and speeds of the second vehicle 1602B and the Mth vehicle 1602M, that within a threshold time period the second vehicle 1602B and the Mth vehicle 1602M will be within a threshold distance of the first location at which the first vehicle 1602 A experienced the channel conditions associated with the updated parameters. In this illustrative example, the first vehicle 1602A transmits the parameter data 1606 to the second vehicle 1602B and the Mth vehicle 1602M (e.g., using peer-to- peer or routed transmissions) based on the determination. Conversely, the first vehicle 1602 A can determine, based on the location, travel direction, and speed of the third vehicle 1602C, that the third vehicle 1602C will not be within the threshold distance of the first location within the threshold time period and can refrain from transmitting the parameter data 1606 to the third vehicle 1602C based on the determination.

[0264] In some embodiments, the first vehicle 1602 A can transmit the parameter data 1606 to particular other devices without making an explicit determination of the currentor future locations of the other devices. For example, the first vehicle 1602 A can broadcast the parameter data 1606. In this example, the broadcast may only be receivable by other vehicles that are within a broadcast coverage area of the broadcast. To illustrate, in the example 1600 of FIG. 16, the second vehicle 1602B and the Mth vehicle 1602M may be close enough to the first vehicle 1602A to receive the broadcast including the parameter data 1606. In some embodiments, the first vehicle 1602A can repeatedly broadcast the parameter data 1606 at a rate that is based on a travel speed of one or more of the vehicles 1602 (e.g., the first vehicle 1602A).

[0265] In another example, the first vehicle 1602 A can transmit the parameter data 1606 along with information about the first vehicle's location, direction of travel, speed, etc., such that the other vehicles 1602B, 1602C, and 1602M can receive the parameter data 1606 and determine whether to use the parameter data 1606 based on their respective locations, directions of travel, and / or speeds. To illustrate, the second vehicle 1602B and the Mth vehicle 1602M may determine to update their respective ML codecs based on the parameter data 1606 due to the proximity of the second vehicle 1602B and the Mth vehicle 1602M to the first vehicle 1602 A; whereas the third vehicle 1602C may receive and discard the parameter data 1606 based on the distance between the first vehicle 1602A and the third vehicle 1602C.

[0266] The first vehicle 1602 A determining updated ML codec parameters based on channel conditions at a first location and sending the parameter data 1606 indicating the updated ML codec parameters to one or more other devices enables the other devices to be prepared in advance for expected channel conditions, which can improve performance of the ML codecs of the other devices. Additionally, the other devices (e.g., the second vehicle 1602B and the Mth vehicle 1602M) can conserve resources that would otherwise be used to determine the updated ML codec parameters, such as computing time and power used to perform ML training operations.

[0267] FIG. 17 illustrates another example 1700 of aspects of operations that can be performed by the device 102 of FIG. 1A in particular embodiments. The example 1700 is similar to the example 1600 of FIG. 16 with the addition of one or more networkdevice(s) 1704 that facilitate communication of the parameter data 1606. The example 1700 can be described in terms of at least two use cases.

[0268] In a first use case, while at or near the first location, the RFE (e.g., the RFE 172 of FIG. 1 A) of the first vehicle 1602 A experiences first channel conditions and the codec updater (e.g., the codec updater 132 of FIG. 1 A) obtains updated parameters of an ML codec (e.g., the ML codec 134) of the first vehicle 1602A based on the first channel conditions. The first vehicle 1602 A sends the updated parameters of the ML codec to the network device(s) 1704 as location-specific data 1702. In some embodiments, the location-specific data 1702 includes information indicating the first location at which the first vehicle 1602A experienced the channel conditions. In other embodiments, the network device(s) 1704 know the location of the first vehicle 1602A based on the other information exchanged between the first vehicle 1602 A and the network device(s) 1704 or based on a portion of a service area of a network (e.g., a cell of the network) from which the first vehicle 1602A sent the location-specific data 1702.

[0269] The network device(s) 1704 store the location-specific data 1702 in mapping data (e.g., the mapping data 146 of FIG. 1A) that associates specific locations with corresponding channel conditions, ML codec parameters, or both. The network device(s) 1704 are configured to send parameter data 1606 indicating the locationspecific data 1702 to one or more other devices based on locations of the other devices, based on expected future locations of the other devices, or both. For example, the network device(s) 1704 can send the parameter data 1606 to the second vehicle 1602B and the Mth vehicle 1602M based on locations, travel directions, and / or speeds of the second vehicle 1602B and the Mth vehicle 1602M and can refrain from sending the parameter data 1606 to the third vehicle 1602C based on the location, travel direction, and speed of the third vehicle 1602C.

[0270] In some embodiments, the network device(s) 1704 can transmit the parameter data 1606 to particular other devices without making an explicit determination of the current or future locations of the other devices. For example, the network device(s) 1704 can cause the parameter data 1606 to be broadcast from a particular portion of the network (e.g., a network base station near the first location). In this example, thebroadcast may only be receivable by devices that are within a broadcast coverage area of the broadcast. Alternatively, the broadcast can include information to enable devices that receive the broadcast to determine whether to use the parameter data 1606. For example, the broadcast can include information about the location, direction of travel, speed, etc. of the first vehicle 1602 A associated with the parameter data 1606, such that the other vehicles 1602B, 1602C, and 1602M can receive the parameter data 1606 and determine whether to use the parameter data 1606 based on their respective locations, directions of travel, and / or speed.

[0271] The first vehicle 1602 A determining updated ML codec parameters based on channel conditions at a first location and sending the location-specific data 1702 indicating the updated ML codec parameters to the network device(s) 1704 allows the network device(s) 1704 to enable other devices (e.g., the other vehicles 1602) to be prepared in advance for expected channel conditions, which can improve performance of the ML codecs of the other devices. Additionally, the other devices (e.g., the second vehicle 1602B and the Mth vehicle 1602M) can conserve resources that would otherwise be used to determine the updated ML codec parameters, such as computing time and power used to perform ML training operations.

[0272] In a second use case, while at or near the first location, the RFE (e.g., the RFE 172 of FIG. 1 A) of the first vehicle 1602 A experiences first channel conditions, and the first vehicle 1602A sends location-specific data 1702 indicating the first channel conditions to the network device(s) 1704. A codec updater (e.g., the codec updater 132 of FIG. 1A) of the network device(s) 1704 obtains updated parameters of an ML codec (e.g., the ML codec 134) based on the first channel conditions. The network device(s) 1704 can store the updated parameters to the mapping data and can send parameter data 1606 indicating the updated parameters to the first vehicle 1602 A, to one or more other vehicles, or a combination thereof, using any of the techniques described above with reference to the first use case.

[0273] The network device(s) 1704 determining updated ML codec parameters based on channel conditions experienced by the first vehicle 1602 A and sending the parameter data 1606 indicating the updated ML codec parameters to one or more of the vehicles1602 enables the vehicles 1602 to conserve resources that would otherwise be used to determine the updated ML codec parameters, such as computing time and power used to perform ML training operations. Additionally, sending the parameter data 1606 to vehicles 1602 other than the first vehicle 1602 A enables the other vehicles to be prepared in advance for expected channel conditions, which can improve performance of the ML codecs of the other vehicles.

[0274] While FIGS. 16 and 17 have been illustrated and described in terms of vehicles 1602, the techniques described with reference to FIGS. 16 and 17 can be employed for other types of devices that include ML codecs. For example, any one or more of the vehicles 1602 can be replaced by a mobile communication device (e.g., a smart phone), a wearable electronics device (e.g., earbuds, a headset, a smart watch, etc.), a portable computing device (e.g., a notebook computer), etc. Further, in embodiments in which at least one device of FIGS. 16 or 17 is a vehicle, the vehicle need not be an automobile, as illustrated in FIGS. 16 and 17. For example, the vehicle can include or correspond to a motorcycle, a bicycle, a train, an aerial vehicle, a watercraft, etc.

[0275] FIG. 18 depicts an implementation 1800 of the device 102 as an integrated circuit 1802 that includes the one or more processors 190. In FIG. 18, the processor(s) 190 include the ML codec 134. Optionally, the processor(s) 190 may also include the channel condition estimator 130 and the codec updater 132.

[0276] The integrated circuit 1802 in FIG. 18 also includes input circuitry 1806, such as one or more bus interfaces, to enable the integrated circuit 1802 to receive signals representing input data 1804 for processing. The input data 1804 can include, for example, the channel metrics 152 of any of FIGS. 1A-12, the sensor data 118 of FIG. 1A, the channel condition data 144 of any of FIGS. 1A-12, encoded data received from another device via a channel, parameter data indicating parameters for the ML codec 134, data to be encoded using the ML codec 134, or combinations thereof.

[0277] The integrated circuit 1802 also includes output circuitry 1808, such as a bus interface, to enable the integrated circuit 1802 to output signals representing output data 1810. For example, the output data 1810 can correspond to or include the channelcondition data 144 of any of FIGS. 1 A- 12, parameter data indicating parameters for the ML codec 134, the encoded data 150 of FIG. 1 A to be sent to another device, data decoded using the ML codec 134, or a combination thereof.

[0278] The integrated circuit 1802 enables updating of parameters of an ML codec 134 based on channel conditions as a component in a system, such as a mobile phone or tablet as depicted in FIG. 19, a hearing aid device, as described with reference to FIG. 20, a headset as depicted in FIG. 21, a wearable electronic device as depicted in FIG. 22, a mixed reality or augmented reality glasses device, as described with reference to FIG. 23, earbuds, as described with reference to FIG. 24, a voice-controlled speaker system as depicted in FIG. 25, a camera as depicted in FIG. 26, a virtual reality, mixed reality, or augmented reality headset as depicted in FIG. 27, or a vehicle as depicted in FIG. 28 or FIG. 29.

[0279] FIG. 19 depicts an example 1900 in which the device 102 includes or is included within a mobile device 1902, such as a phone or tablet, as illustrative, non-limiting examples. The mobile device 1902 includes one or more microphones 1906, one or more speakers 1908, and a display screen 1904. Components of the processor 190 (illustrated using dashed lines to indicate internal components that are not generally visible to a user), such as the ML codec 134, the channel condition estimator 130, the codec updater 132, or a combination thereof, are integrated in the mobile device 1902.

[0280] In a particular example, the ML codec 134 is operable to encode and / or decode data using parameters updated based on specific channel conditions. To illustrate, in some embodiments, decoder parameters of the ML codec 134, which can be used to decode encoded data, can be updated based in part on channel conditions experienced at the mobile device 1902. As another illustrative example, in some embodiments, encoder parameters of the ML codec 134, which can be used to encode data for transmission to another device, can be updated based in part on channel conditions experienced at the other device. Updating parameters of the ML codec 134 based on specific channel conditions can enable the ML codec 134 to encode and decode data over a wide range of channel conditions.

[0281] FIG. 20 illustrates a hearing aid device 2000 that incorporates aspects of the device 102 of FIG. 1 A. The example illustrated in FIG. 20 is an in-ear hearing aid device 2000 that includes a housing 2002 with a molded portion configured to fit within a contour of one ear of a user. In other examples, the hearing aid device 2000 can include an over-ear portion configured to be worn over the ear of the user. An earpiece 2010 is coupled to the housing 2002 and includes one or more speakers 2008. The hearing aid device 2000 also includes one or more microphones 2006 disposed on the housing 2002.

[0282] In FIG. 20, components of the processor 190, such as the ML codec 134, the channel condition estimator 130, and / or the codec updater 132 of any of FIGS. 1A-15, are integrated in the hearing aid device 2000. In a particular example, the ML codec 134 is integrated with the hearing aid device 2000 and is operable to encode and / or decode data using parameters updated based on specific channel conditions. To illustrate, in some embodiments, decoder parameters of the ML codec 134, which can be used to decode encoded data, can be updated based in part on channel conditions experienced at the hearing aid device 2000. As another illustrative example, in some embodiments, encoder parameters of the ML codec 134, which can be used to encode data for transmission to another device, can be updated based in part on channel conditions experienced at the other device. Updating parameters of the ML codec 134 based on specific channel conditions can enable the hearing aid device 2000 to encode and decode data over a wide range of channel conditions.

[0283] FIG. 21 depicts an implementation 2100 in which the device 102 includes or is included within a headset device 2102. The headset device 2102 includes one or more microphones 2106 and one or more speakers 2108. Components of the processor 190, such as the ML codec 134, the channel condition estimator 130, and / or the codec updater 132 of any of FIGS. 1A-15, are integrated in the headset device 2102. In a particular example, the ML codec 134 is integrated with the headset device 2102 and is operable to encode and / or decode data using parameters updated based on specific channel conditions. To illustrate, in some embodiments, decoder parameters of the ML codec 134, which can be used to decode encoded data, can be updated based in part on channel conditions experienced at the headset device 2102. As another illustrativeexample, in some embodiments, encoder parameters of the ML codec 134, which can be used to encode data for transmission to another device, can be updated based in part on channel conditions experienced at the other device. Updating parameters of the ML codec 134 based on specific channel conditions can enable the headset device 2102 to encode and decode data over a wide range of channel conditions.

[0284] FIG. 22 depicts an implementation 2200 in which the device 102 includes or is included within a wearable electronic device 2202, illustrated as a "smart watch." The wearable electronic device 2202 includes a display screen 2204, one or more microphones 2206, and one or more speakers 2208. Components of the processor 190, such as the ML codec 134, the channel condition estimator 130, and / or the codec updater 132 of any of FIGS. 1A-15, are integrated in the wearable electronic device 2202. In a particular example, the ML codec 134 is integrated with the wearable electronic device 2202 and is operable to encode and / or decode data using parameters updated based on specific channel conditions. To illustrate, in some embodiments, decoder parameters of the ML codec 134, which can be used to decode encoded data, can be updated based in part on channel conditions experienced at the headset device 2102. As another illustrative example, in some embodiments, encoder parameters of the ML codec 134, which can be used to encode data for transmission to another device, can be updated based in part on channel conditions experienced at the other device.Updating parameters of the ML codec 134 based on specific channel conditions can enable the wearable electronic device 2202 to encode and decode data over a wide range of channel conditions.

[0285] In some embodiments, the wearable electronic device 2202 is configured to generate a notification based on content of data encoded or decoded by the ML codec 134. For example, the display screen 2204 can generate visual information based on the content of the data. As another example, the wearable electronic device 2202 can include a haptic device that provides a haptic notification (e.g., vibrates) based on content of the data. As another example, the display screen 2204 can be configured to display images or video received as encoded data in one or more transmissions and decoded by the ML codec 134 using parameters that are updated by the codec updater 132.

[0286] FIG. 23 depicts an implementation 2300 in which the device 102 includes or is included within a portable electronic device that corresponds to augmented reality or mixed reality glasses 2302. The glasses 2302 include a holographic projection unit 2310 configured to project visual data onto a surface of a lens 2312 or to reflect the visual data off of a surface of the lens 2312 and onto the wearer’s retina. The glasses 2302 also include one or more microphones 2306 and one or more speakers 2308.

[0287] Components of the processor 190, such as the ML codec 134, the channel condition estimator 130, and / or the codec updater 132 of any of FIGS. 1A-15, are integrated in the glasses 2302. In a particular example, the ML codec 134 is integrated with the glasses 2302 and is operable to encode and / or decode data using parameters updated based on specific channel conditions. To illustrate, in some embodiments, decoder parameters of the ML codec 134, which can be used to decode encoded data, can be updated based in part on channel conditions experienced at the glasses 2302. As another illustrative example, in some embodiments, encoder parameters of the ML codec 134, which can be used to encode data for transmission to another device, can be updated based in part on channel conditions experienced at the other device. Updating parameters of the ML codec 134 based on specific channel conditions can enable the glasses 2302 to encode and decode data over a wide range of channel conditions.

[0288] In a particular example, the holographic projection unit 2310 is configured to display a notification based on content of data encoded or decoded by the ML codec 134. As another example, the holographic projection unit 2310 can be configured to display images or video received as encoded data in one or more transmissions and decoded by the ML codec 134 using parameters that are updated by the codec updater 132.

[0289] FIG. 24 depicts an implementation 2400 in which the device 102 includes or is included within a portable electronic device that corresponds to a pair of earbuds 2406 that includes a first earbud 2402 and a second earbud 2404. Although earbuds are described, it should be understood that the present technology can be applied to other in- ear or over-ear audio devices.

[0290] The first earbud 2402 includes a first microphone 2420, such as a high signal-to- noise microphone positioned to capture the voice of a wearer of the first earbud 2402, an array of one or more other microphones configured to detect ambient sounds and spatially distributed to support beamforming, illustrated as microphones 2422A, 2422B, and 2422C, an "inner" microphone 2424 proximate to the wearer’s ear canal (e.g., to assist with active noise cancelling), and a self-speech microphone 2426, such as a bone conduction microphone configured to convert sound vibrations of the wearer’s ear bone or skull into an audio signal.

[0291] The second earbud 2404 can be configured in a substantially similar manner as the first earbud 2402. In some implementations, the first earbud 2402 is also configured to receive one or more audio signals generated by one or more microphones of the second earbud 2404, such as via wireless transmission between the earbuds 2402, 2404, or via wired transmission in implementations in which the earbuds 2402, 2404 are coupled via a transmission line.

[0292] In some implementations, the earbuds 2402, 2404 are configured to automatically switch between various operating modes, such as a passthrough mode in which ambient sound is played via a speaker 2430, a playback mode in which nonambient sound (e.g., streaming audio corresponding to a phone conversation, media playback, video game, etc.) is played back through the speaker 2430, and an audio zoom mode or beamforming mode in which one or more ambient sounds are emphasized and / or other ambient sounds are suppressed for playback at the speaker 2430. In other implementations, the earbuds 2402, 2404 may support fewer modes or may support one or more other modes in place of, or in addition to, the described modes.

[0293] In an illustrative example, the earbuds 2402, 2404 can automatically transition from the playback mode to the passthrough mode in response to detecting the wearer’s voice and may automatically transition back to the playback mode after the wearer has ceased speaking. In some examples, the earbuds 2402, 2404 can operate in two or more of the modes concurrently, such as by performing audio zoom on a particular ambient sound (e.g., a dog barking) and playing out the audio zoomed sound superimposed on the sound being played out while the wearer is listening to music (which can be reducedin volume while the audio zoomed sound is being played). In this example, the wearer can be alerted to the ambient sound associated with the audio event without halting playback of the music.

[0294] In FIG. 24, components of the processor 190, such as the ML codec 134, the channel condition estimator 130, and / or the codec updater 132 of any of FIGS. 1A-15, are integrated in at least one of the earbuds 2402, 2404. In a particular example, the ML codec 134 is integrated with the earbuds 2402, 2404 and is operable to encode and / or decode data using parameters updated based on specific channel conditions. To illustrate, in some embodiments, decoder parameters of the ML codec 134, which can be used to decode encoded data, can be updated based in part on channel conditions experienced at the earbuds 2402, 2404. As another illustrative example, in some embodiments, encoder parameters of the ML codec 134, which can be used to encode data for transmission to another device, can be updated based in part on channel conditions experienced at the other device. Updating parameters of the ML codec 134 based on specific channel conditions can enable the earbuds 2402, 2404 to encode and decode data over a wide range of channel conditions.

[0295] FIG. 25 is an implementation 2500 in which the device 102 includes a wireless speaker and voice activated device 2502. The wireless speaker and voice activated device 2502 can have wireless network connectivity and is configured to execute an assistant operation. The wireless speaker and voice activated device 2502 includes one or more microphones 2506 and one or more speakers 2508. Components of the processor 190, such as the ML codec 134, the channel condition estimator 130, and / or the codec updater 132 of any of FIGS. 1A-15, are integrated in the wireless speaker and voice activated device 2502. In a particular example, the ML codec 134 is integrated with the wireless speaker and voice activated device 2502 and is operable to encode and / or decode data using parameters updated based on specific channel conditions. To illustrate, in some embodiments, decoder parameters of the ML codec 134, which can be used to decode encoded data, can be updated based in part on channel conditions experienced at the wireless speaker and voice activated device 2502. As another illustrative example, in some embodiments, encoder parameters of the ML codec 134, which can be used to encode data for transmission to another device, can be updatedbased in part on channel conditions experienced at the other device. Updating parameters of the ML codec 134 based on specific channel conditions can enable the wireless speaker and voice activated device 2502 to encode and decode data over a wide range of channel conditions.

[0296] FIG. 26 depicts an implementation 2600 in which the device 102 includes or is included within a portable electronic device that corresponds to a camera device 2602. The camera device 2602 includes one or more microphones 2606, one or more speakers 2608, and an image sensor 2610. Components of the processor 190, such as the ML codec 134, the channel condition estimator 130, and / or the codec updater 132 of any of FIGS. 1A-15, are integrated in the camera device 2602. In a particular example, the ML codec 134 is integrated with the camera device 2602 and is operable to encode and / or decode data using parameters updated based on specific channel conditions. To illustrate, in some embodiments, decoder parameters of the ML codec 134, which can be used to decode encoded data, can be updated based in part on channel conditions experienced at the camera device 2602. As another illustrative example, in some embodiments, encoder parameters of the ML codec 134, which can be used to encode data for transmission to another device, can be updated based in part on channel conditions experienced at the other device. To illustrate, the image sensor 2610 of the camera device 2602 is configured to capture image data that can be encoded by the ML codec 134 using parameters that are updated by the codec updater 132. Updating parameters of the ML codec 134 based on specific channel conditions can enable the camera device 2602 to encode and decode data over a wide range of channel conditions.

[0297] FIG. 27 depicts an implementation 2700 in which the device 102 includes a portable electronic device that corresponds to a virtual reality, mixed reality, or augmented reality headset 2702. A visual interface device is positioned in front of the user's eyes to enable display of augmented reality, mixed reality, or virtual reality images or scenes to the user while the headset 2702 is worn. The headset 2702 also includes one or more microphones 2706, one or more speakers 2708. The headset 2702 also includes a display screen 2710 disposed to be positioned in front of a user's eyes when the headset 2702 is worn. Components of the processor 190, such as the ML codec 134, the channel condition estimator 130, and / or the codec updater 132 of any ofFIGS. 1A-15, are integrated in the headset 2702. In a particular example, the ML codec 134 is integrated with the headset 2702 and is operable to encode and / or decode data using parameters updated based on specific channel conditions. To illustrate, in some embodiments, decoder parameters of the ML codec 134, which can be used to decode encoded data, can be updated based in part on channel conditions experienced at the headset 2702. As an example, the display screen 2710 can be configured to display images or video based on data decoded by the ML codec 134 using parameters that are updated by the codec updater 132. As another illustrative example, in some embodiments, encoder parameters of the ML codec 134, which can be used to encode data for transmission to another device, can be updated based in part on channel conditions experienced at the other device. Updating parameters of the ML codec 134 based on specific channel conditions can enable the headset 2702 to encode and decode data over a wide range of channel conditions.

[0298] FIG. 28 depicts an implementation 2800 in which the device 102 corresponds to, or is integrated within, a vehicle 2802, illustrated as a manned or unmanned aerial device (e.g., a package delivery drone). The vehicle 2802 includes one or more microphones 2806, and one or more speakers 2808. Components of the processor 190, such as the ML codec 134, the channel condition estimator 130, and / or the codec updater 132 of any of FIGS. 1A-15, are integrated in the vehicle 2802. In a particular example, the ML codec 134 is integrated with the vehicle 2802 and is operable to encode and / or decode data using parameters updated based on specific channel conditions. To illustrate, in some embodiments, decoder parameters of the ML codec 134, which can be used to decode encoded data, can be updated based in part on channel conditions experienced at the vehicle 2802. As another illustrative example, in some embodiments, encoder parameters of the ML codec 134, which can be used to encode data for transmission to another device, can be updated based in part on channel conditions experienced at the other device. Updating parameters of the ML codec 134 based on specific channel conditions can enable the vehicle 2802 to encode and decode data over a wide range of channel conditions.

[0299] FIG. 29 depicts another implementation 2900 in which the device 102 corresponds to, or is integrated within, a vehicle 2902, illustrated as a car. The vehicle2902 includes a display screen 2910, one or more microphones 2906, and one or more speakers 2908. Components of the processor 190, such as the ML codec 134, the channel condition estimator 130, and / or the codec updater 132 of any of FIGS. 1A-15, are integrated in the vehicle 2902. In a particular example, the ML codec 134 is integrated with the vehicle 2902 and is operable to encode and / or decode data using parameters updated based on specific channel conditions. To illustrate, in some embodiments, decoder parameters of the ML codec 134, which can be used to decode encoded data, can be updated based in part on channel conditions experienced at the vehicle 2902. As another illustrative example, in some embodiments, encoder parameters of the ML codec 134, which can be used to encode data for transmission to another device, can be updated based in part on channel conditions experienced at the other device. Updating parameters of the ML codec 134 based on specific channel conditions can enable the vehicle 2902 to encode and decode data over a wide range of channel conditions.

[0300] Referring to FIG. 30, a particular implementation of a method 3000 of updating parameters of an ML codec based on channel conditions is shown. In a particular aspect, one or more operations of the method 3000 are performed by at least one of the RFE 172, the modem 170, the channel condition estimator 130, the codec updater 132, the ML codec 134, the processor(s) 190, the device 102, the system 100 of FIG. 1A, or a combination thereof. The ML codec can include or correspond to a data codec, an audio codec, a video codec, a graphics codec, or a combination thereof, and the parameters of the ML codec that are updated can include decoder parameters, encoder parameters, or both.

[0301] The method 3000 includes, at block 3002, obtaining, by one or more processors, channel condition data indicating channel conditions experienced by a first radio frontend during a first communication session. For example, the processor(s) 190 of FIG. 1A can obtain the channel metrics 152 from the RFE 172, the encoded data 150 from the modem 170, or both. In this example, the processor(s) 190 can determine the channel condition data 144 based on the channel metrics 152, the encoded data 150, or both. In this example, the device 102 corresponds to the first device that experiences the channel conditions during the first communication session. As another example, the firstdevice can be remote from the device 102, and the device 102 can receive the channel condition data (during or after the first communication session) via one or more transmissions 178 from the first device. The channel condition data include or are indicative of one or more data loss metrics associated with the first communication session, one or more data delay metrics associated with the first communication session, a temporal distribution of one or more data loss metrics associated with the first communication session, a temporal distribution of one or more data delay metrics associated with the first communication session, or a combination thereof.

[0302] The method 3000 also includes, at block 3004, updating, by the one or more processors, parameters of an ML codec associated with the first communication session based on the channel condition data to generate updated parameters of the ML codec. For example, the codec updater 132 can update the parameters 142 of the ML codec 134 based on the channel condition data 144.

[0303] In some embodiments, the ML codec parameters can be updated using one or more operations described with reference to FIG. 13. For example, in such embodiments, updating the parameters of the ML codec includes using an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; modifying the encoded data samples in a manner representative of the channel conditions to generate modified encoded data samples; using a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples; determining an error metric based on a difference between the set of input data samples and the decoded data samples; and generating the updated parameters by updating decoder parameters of the ML codec, encoder parameters of the ML codec, or both, to reduce the error metric.

[0304] The parameters of the ML codec can be updated during or after the first communication session and can be used during a portion of the first communication session or during a second communication session subsequent to the first communication session. In some embodiments, the method 3000 includes sending the updated parameters of the ML codec to the first device during or after the first communication session. For example, the device 102 can update the parameters 142 ofthe ML codec 134 based on channel conditions experienced at the first device and can send parameter data indicating the updated parameters to the first device.

[0305] In some embodiments, the method 3000 includes sending the updated parameters to another device for use during a second communication session. For example, the device 102 can update the parameters 142 of the ML codec 134 based on channel conditions experienced at the device 102 (e.g., the device 102 is the first device) or at a different device (e.g., the first device is one of the endpoint devices 180 or one of the network devices 182) and can send parameter data indicating the updated parameters to another device (e.g., one of the endpoint devices 180 or one of the network devices 182) for use during the second communication session.

[0306] In some embodiments, the method 3000 includes using the updated parameters during a second communication session. For example, the device 102 can update the parameters 142 of the ML codec 134 based on channel conditions experienced at the device 102 (e.g., the device 102 is the first device) and can use the updated parameters during the second communication session subsequent to the first communication session.

[0307] In some embodiments, the method 3000 includes determining parameter data indicating the updated parameters. For example, the method 3000 can include determining representative parameters based on the updated parameters and storing mapping data that associates the channel condition data with a codebook index, where the codebook index is associated with the representative parameters. For example, the representative parameters can include parameters associated with a centroid of a cluster of sets of parameters in a parameter space, as described with reference to FIG. 14.

[0308] Referring to FIG. 31, a particular implementation of a method 3100 of updating parameters of an ML codec based on channel conditions is shown. In a particular aspect, one or more operations of the method 3100 are performed by at least one of the RFE 172, the modem 170, the channel condition estimator 130, the codec updater 132, the ML codec 134, the processor(s) 190, the device 102, the system 100 of FIG. 1A, or a combination thereof. The ML codec can include or correspond to a data codec, an audiocodec, a video codec, a graphics codec, or a combination thereof, and the parameters of the ML codec that are updated can include decoder parameters, encoder parameters, or both.

[0309] The method 3100 includes, at block 3102, obtaining, by one or more processors, first channel condition data indicating first channel conditions experienced by a first radio frontend in a first location. For example, the processor(s) 190 of FIG. 1 A can obtain the channel metrics 152 from the RFE 172, the encoded data 150 from the modem 170, or both. In this example, the processor(s) 190 can determine the channel condition data 144 based on the channel metrics 152, the encoded data 150, or both. In this example, the device 102 corresponds to the first device that experiences the channel conditions at the first location. As another example, the first device can be remote from the device 102, and the device 102 can receive the channel condition data via one or more transmissions 178 from the first device. The channel condition data include or are indicative of one or more data loss metrics experienced by the first device at the first location, one or more data delay metrics experienced by the first device at the first location, a temporal distribution of one or more data loss metrics experienced by the first device at the first location, a temporal distribution of one or more data delay metrics experienced by the first device at the first location, or a combination thereof.

[0310] The method 3100 includes, at block 3104, obtaining, by the one or more processors and based on the first channel condition data, a first set of parameters of an ML codec for the first channel conditions. In some embodiments, obtaining the first set of parameters of the ML codec for the first channel conditions can include determining the first set of parameters using the codec updater 132. To illustrate, the ML codec parameters can be updated using one or more operations described with reference to FIG. 13. In such embodiments, obtaining the first set of parameters of the ML codec can include using an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; modifying the encoded data samples in a manner representative of the first channel conditions to generate modified encoded data samples; using a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples; determining an error metric based on a difference between the set of input data samples and the decoded data samples; and generating theupdated parameters by updating decoder parameters of the ML codec, encoder parameters of the ML codec, or both, to reduce the error metric.

[0311] In some embodiments, obtaining the first set of parameters of the ML codec for the first channel conditions can include sending the first channel condition data to a remote device and receiving data indicating the first set of parameters from the remote device. For example, in some such embodiments, the remote device can look up the first set of parameters in mapping data (e.g., the mapping data 146 of FIG. 1A) based on the first channel conditions, based on the first location, or both.

[0312] The method 3100 includes, at block 3106, causing data indicating the first set of parameters of the ML codec to be sent to a second device based on location data associated with the second device. For example, the RFE 172 of FIG. 1 A can send the data indicating the first set of parameters to one or more of the endpoint device(s) 180, one or more of the network device(s) 182, or both. The location data associated with the second device can indicate, for example, a detected location of the second device, a predicted future location of the second device, or both. As another example, the location data associated with the second device can indicate that the second device is proximate to the first location.

[0313] In some embodiments, the method 3100 includes identifying a cluster of devices based on locations of the devices and sending the data indicating the first set of parameters of the ML codec to one or more devices of the cluster of devices, where the cluster of devices includes at least the second device. In some such embodiments, the cluster of devices can be identified based on additional information, such as based on motion of at least one of the devices, geofence data that designates a boundary of the cluster of devices, identifiers associated with the devices, etc. As an example, the cluster of devices can include a group of devices that are moving along a thoroughfare. To illustrate, the cluster of devices can include the second vehicle 1602B and the Mth vehicle 1602M of FIGS. 16 and 17 based on proximity of the second vehicle 1602B and the Mth vehicle 1602M to one another, proximity of the second vehicle 1602B and the Mth vehicle 1602M to the vehicle 1602A, motion (e.g., a speed and / or direction) of the second vehicle 1602B and the Mth vehicle 1602M, geofence data designating aboundary in which parameters associated with channel conditions experienced by the first vehicle 1602 A are relevant, identifiers of the second vehicle 1602B and the Mth vehicle 1602M, etc. In this illustrative example, the identifiers of the second vehicle 1602B and the Mth vehicle 1602M can indicate, for example, whether the second vehicle 1602B and the Mth vehicle 1602M are associated with a system or service that provides ML parameter updates, whether the second vehicle 1602B and the Mth vehicle 1602M are known to the first vehicle 1602A or to the network device(s) 1704, etc. In some embodiments, the method 3100 includes sending updated data indicating parameters of the ML codec at an interval determined based on relative movement of two or more of the devices of the cluster of devices.

[0314] In some embodiments, the data indicating the first set of parameters of the ML codec is transmitted to the second device via a peer-to-peer communication link with the second device. For example, the first vehicle 1602 A of FIG. 16 can send the parameter data 1606 directly to the second vehicle 1602B via a peer-to-peer communication link. In some such embodiments, the data indicating the first set of parameters can be set via a broadcast, and the second device can receive the data from the broadcast. For example, the first vehicle 1602 A of FIG. 16 can broadcast the parameter data 1606, and the second vehicle 1602B can receive the parameter data 1606 if the second vehicle 1602B is sufficiently close to the first vehicle 1602A to receive the broadcast.

[0315] In some embodiments, the data indicating the first set of parameters of the ML codec is transmitted to the second device via a routed communication link with the second device. For example, the first vehicle 1602 A of FIG. 16 can send the parameter data 1606 to a base station or another network edge device and the base station or edge device can route the parameter data 1606 to the second vehicle 1602B.

[0316] In some embodiments, the data indicating the first set of parameters of the ML codec is transmitted to the second device indirectly. For example, in some such embodiments, the method 3100 includes transmitting the data indicating the first set of parameters of the ML codec and data identifying the first location to a network device (such as one of the network device(s) 1704 of FIG. 17). In this example, the network device is configured to send the data indicating the first set of parameters of the MLcodec to the second device based on the data identifying the first location and the location data associated with the second device.

[0317] In some embodiments, the data indicating the first set of parameters of the ML codec can include a first set of sparse weight updates to adapt parameters of the ML codec at the second device to the first set of parameters. In some embodiments, the data indicating the first set of parameters of the ML codec can include a codebook index associated with the first set of parameters.

[0318] Referring to FIG. 32, a particular implementation of a method 3200 of updating parameters of an ML codec based on channel conditions is shown. In a particular aspect, one or more operations of the method 3200 are performed by at least one of the RFE 172, the modem 170, the channel condition estimator 130, the codec updater 132, the ML codec 134, the processor(s) 190, the device 102, the system 100 of FIG. 1A, or a combination thereof. The ML codec can include or correspond to a data codec, an audio codec, a video codec, a graphics codec, or a combination thereof, and the parameters of the ML codec that are updated can include decoder parameters, encoder parameters, or both.

[0319] The method 3200 includes, at block 3202, obtaining first channel condition data associated with channel conditions experienced at a first radio frontend during one or more first communication sessions. For example, the processor(s) 190 of FIG. 1A can obtain the channel metrics 152 from the RFE 172, the encoded data 150 from the modem 170, or both. In this example, the processor(s) 190 can determine the channel condition data 144 (e.g., the first channel condition data) based on the channel metrics 152, the encoded data 150, or both. In this example, the device 102 corresponds to the first device that experiences the channel conditions during the one or more first communication sessions. As another example, the first device can be remote from the device 102, and the device 102 can receive the channel condition data (during or after the one or more first communication sessions) via one or more transmissions 178 from the first device. The first channel condition data include or are indicative of one or more data loss metrics associated with the one or more first communication sessions, one or more data delay metrics associated with the one or more first communication sessions, atemporal distribution of one or more data loss metrics associated with the one or more first communication sessions, a temporal distribution of one or more data delay metrics associated with the one or more first communication sessions, or a combination thereof.

[0320] The method 3200 includes, at block 3204, determining first parameters of the ML codec based on the first channel condition data and mapping data that associates channel condition data to parameters of the ML codec. For example, the processor(s) 190 can determine the first parameters (e.g., parameters 142) of the ML codec 134 based on the first channel condition data (e.g., the channel condition data 144) and the mapping data 146. In this example, the mapping data 146 can associate particular parameters 142 of the ML codec 134 with corresponding channel condition data 144, location data, or both.

[0321] The method 3200 includes, at block 3206, causing data indicating the first parameters to be sent to a first device. For example, the data indicating the first parameters can be transmitted to the first device via a peer-to-peer communication link with the first device. To illustrate, the first vehicle 1602 A of FIG. 16 can send the parameter data 1606 directly to the second vehicle 1602B via a peer-to-peer communication link. In some embodiments, the data indicating the first parameters can be broadcast, and the first device can receive the data indicating the first parameters from the broadcast. For example, the first vehicle 1602 A of FIG. 16 can broadcast the parameter data 1606, and the second vehicle 1602B can receive the parameter data 1606 if the second vehicle 1602B is sufficiently close to the first vehicle 1602A to receive the broadcast.

[0322] In some embodiments, the data indicating the first parameters is transmitted to the first device via a routed communication link with the first device. For example, the first vehicle 1602 A of FIG. 16 can send the parameter data 1606 to a base station or another network edge device and the base station or edge device can route the parameter data 1606 to the second vehicle 1602B.

[0323] In some embodiments, the data indicating the first parameters is transmitted to the first device indirectly. For example, in some such embodiments, the method 3200includes transmitting the data indicating the first parameters to a network device (such as one of the network device(s) 1704 of FIG. 17). In this example, the network device is configured to send the data indicating the first parameters to the second device based on a determination that the first parameters are relevant to the first device.

[0324] In some embodiments, the data indicating the first parameters sent to the first device includes a first codebook index associated with the first parameters. In some embodiments, the data indicating the first parameters sent to the first device includes a first set of sparse weight updates to adapt parameters of the ML codec at the first device to the first parameters.

[0325] In some embodiments, before determining first parameters of the ML codec based on the first channel condition data and the mapping data, the method 3200 includes generating the mapping data. For example, in some such embodiments, the method 3200 includes obtaining, from one or more remote devices, second channel condition data associated with channel conditions experienced at the one or more remote devices during one or more second communication sessions and generating the mapping data based on the second channel condition data. As another example, in some such embodiments, the method 3200 includes obtaining, from the one or more remote devices, updated parameters of the ML codec generated by the one or more remote devices based on the second channel condition data and storing the updated parameters of the ML codec in association with the second channel condition data to generate the mapping data.

[0326] As another example, in some such embodiments, the method 3200 includes updating the parameters of the ML codec based on the second channel condition data to generate updated parameters of the ML codec and storing the updated parameters of the ML codec in association with the second channel condition data to generate the mapping data. To illustrate, updating the parameters of the ML codec can include using an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; modifying the encoded data samples based on the second channel condition data to generate modified encoded data samples; using a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples;determining an error metric based on a difference between the set of input data samples and the decoded data samples; generating updated parameters of the ML codec to reduce the error metric; and storing the updated parameters of the ML codec in association with the second channel condition data to generate the mapping data. In some such embodiments, the values of the updated parameters of the ML codec can be constrained to generate sparse weight updates, as described with reference to FIG. 15.

[0327] As another example, in some such embodiments, the method 3200 includes determining, based on multiple sets of updated parameters for multiple sets of channel condition data, representative parameters of the ML codec and storing an entry in the mapping data. In this example, the entry assigns a codebook index to the representative parameters and associates the codebook index with representative channel condition data based on the multiple sets of channel condition data. For example, the mapping generator 1410 of FIG. 14 can generate or update the mapping data 146 by storing an entry that assigns a codebook index to representative parameters (e.g., the centroid parameters 1412) and associates the codebook index with representative channel condition data based on the multiple sets of channel condition data. In some embodiments, the method 3200 includes determining the representative parameters. For example, determining the representative parameters can include identifying clusters of sets of parameters of the ML codec, identifying a centroid of a cluster of the clusters, and assigning parameters corresponding to the centroid of the cluster as the representative parameters of the ML codec for the cluster, as described with reference to FIG. 14.

[0328] Referring to FIG. 33, a particular implementation of a method 3300 of updating parameters of an ML codec based on channel conditions is shown. In a particular aspect, one or more operations of the method 3300 are performed by at least one of the RFE 172, the modem 170, the channel condition estimator 130, the codec updater 132, the ML codec 134, the processor(s) 190, the device 102, the system 100 of FIG. 1A, or a combination thereof. The ML codec can include or correspond to a data codec, an audio codec, a video codec, a graphics codec, or a combination thereof, and the parameters of the ML codec that are updated can include decoder parameters, encoder parameters, or both.

[0329] The method 3300 includes, at block 3302, obtaining bit error data indicative of bit errors associated with a first communication session. The bit error data can be estimated or calculated. For example, in some embodiments, the bit error data includes or is based on soft bit probability estimates for a plurality of bits received during the first communication session. For example, the LDPC decoder 806 of FIG. 8 can generate the soft bit data 808 which includes soft bit probability estimates for a plurality of bits received via the channel 176 during a communication session. In this example, the soft bit probability estimates can include log-likelihood ratios representing posterior probabilities of bit states for the plurality of bits received during the first communication session.

[0330] In some embodiments, obtaining bit error data includes obtaining received bits based on signals received at a first device during the first communication session, obtaining transmitted bits representing a bitstream transmitted by a second device via the signals, and determining the bit error data based on a comparison of the received bits and the transmitted bits. To illustrate, in the example 900 of FIG. 9, the RFE 172 of the first device 102A determines the received bits 908 based on symbols received via the channel 176 from the second device 102B, where the symbols 904 represent bits transmitted by the second device 102B. The channel condition estimator 130 of the first device 102 A obtains the transmitted bits 910 and determines bit error data 912 based on a comparison of the received bits 908 and the transmitted bits 910. In some such embodiments, the bitstream transmitted via the signals corresponds to a sequence of bits known in advance by the first device and the second device. To illustrate, in the example 900 of FIG. 9, data representing the transmitted bits 910 can be stored at a memory of the first device 102A before the second device 102B sends a bitstream (e.g., the modulated bits 902) corresponding to the transmitted bits 910.

[0331] In some such embodiments, the bitstream transmitted via the signals corresponds to a randomized sequence of bits determined at the second device using a seed value that is known by the first device, and obtaining the transmitted bits includes generating a bit sequence using a randomization process based on the seed value. To illustrate, in the example 1000 of FIG. 10, the second device 102B generates a randomized sequence of bits using the seed 1006 and transmits the modulated bits 1008 representing therandomized sequence of bits. The RFE 172 of the first device 102 A determines the received bits 1012 based on the symbols 1010 received via the channel 176 from the second device 102B and determines the randomized bits 1014 using the seed 1006. In the example 1000, the randomized bits 1014 correspond to the transmitted bits (e.g., are identical to the bit sequence generated by the second device 102B), which are compared to the received bits 1012 to determine the bit error data 1016.

[0332] In some such embodiments, the bitstream transmitted via the signals include multiple repetitions of the bitstream, and the method 3300 includes processing the multiple repetitions jointly to determine the transmitted bits and processing the multiple repetitions individually to determine the received bits. To illustrate, in the example 1100 of FIG. 11, the second device 102B transmits multiple repetitions of the bit sequence 1104, and the RFE 172 of the first device 102 A determines the received bits 1108 based on the symbols 1010 received via the channel 176 from the second device 102B. The joint decoder 1110 processes the multiple repetitions of the bitstream in the received bits 1108 jointly to determine the jointly decoded bits 1112 representing the transmitted bits. The individual decoder 1114 processes the multiple repetitions of the bitstream in the received bits 1108 individually to determine the individually decoded bits 1116 representing the received bits.

[0333] In some embodiments, obtaining the bit error data includes obtaining block error rate (BLER) data indicative of a block error rate associated with the first communication session, obtaining a bit error distribution based on the BLER data, and estimating the bit errors associated with the first communication session based on the bit error distribution. To illustrate, in the example 1200 of FIG. 12, the second device 102B transmits multiple data blocks 1202, and the RFE 172 of the first device 102 A determines the received bits 1206 based on the symbols 1010 received via the channel 176 from the second device 102B. The BLER estimator 1210 determines the BLER data 1212 indicating a block error rate associated with the receive bits 1206. The bit error estimator 1218 obtains a bit error distribution 1216 based on the BLER data 1212 and estimates the bit error data 1220 indicating the bit errors associated with the first communication session based on the bit error distribution 1216.

[0334] The method 3300 also includes, at block 3304, obtaining updated parameters of the ML codec based on the bit error data to generate updated parameters of the ML codec. In some embodiments, the parameters of the ML codec can be updated using one or more operations described with reference to FIG. 13. For example, in such embodiments, updating the parameters of the ML codec based on the bit error data includes using an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; modifying the encoded data samples to introduce bit errors based on the bit error data to generate modified encoded data samples; using a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples; determining an error metric based on a difference between the set of input data samples and the decoded data samples; and generating the updated parameters by updating decoder parameters of the ML codec, encoder parameters of the ML codec, or both, to reduce the error metric.

[0335] In some embodiments, the method 3300 includes obtaining additional channel condition data indicating other channel conditions experienced by a first radio frontend during the first communication session and updating the parameters of the ML codec based on the additional channel condition data and the bit error data to generate the updated parameters of the ML codec. For example, the additional channel condition data can include signal-to-noise metrics, packet losses, block error metrics, packet delays, or temporal distributions of any of these.

[0336] The parameters of the ML codec can be updated during or after the first communication session and can be used (e.g., to encode or decode data) during a portion of the first communication session or during a second communication session subsequent to the first communication session. In some embodiments, the method 3300 includes sending the updated parameters of the ML codec to another device for use during the first communication session or during a second communication session subsequent to the first communication session. For example, the bit errors can be experienced by a first radio frontend during the first communication session. In this example, the first device can transmit bit error data indicating the bit errors to the device 102, and the device 102 can update the parameters 142 of the ML codec 134 based onbit error data experienced at the first device and can send parameter data indicating the updated parameters to the first device.

[0337] In some embodiments, the method 3300 includes determining parameter data indicating the updated parameters. For example, the method 3300 can include determining representative parameters based on the updated parameters and storing mapping data that associates the bit error data with a codebook index, where the codebook index is associated with the representative parameters. For example, the representative parameters can include parameters associated with a centroid of a cluster of sets of parameters in a parameter space, as described with reference to FIG. 14.

[0338] In some embodiments, the method 3300 includes receiving transmissions including encoded data and decoding the encoded data using the ML codec. For example, the device 102 can receive the encoded data 150 via the transmissions 178 and can use the decoder 138 of the ML codec 134 to decode the encoded data 150.

[0339] Referring to FIG. 34, a particular implementation of a method 3400 of updating parameters of an ML codec based on channel conditions is shown. In a particular aspect, one or more operations of the method 3400 are performed by at least one of the RFE 172, the modem 170, the channel condition estimator 130, the codec updater 132, the ML codec 134, the processor(s) 190, the device 102, the system 100 of FIG. 1A, or a combination thereof. The ML codec can include or correspond to a data codec, an audio codec, a video codec, a graphics codec, or a combination thereof, and the parameters of the ML codec that are updated can include decoder parameters, encoder parameters, or both.

[0340] The method 3400 includes, at block 3402, obtaining, at one or more processors of a first device, channel condition data indicating channel conditions experienced at a radio frontend of a second device. For example, the processor(s) 190 of FIG. 1A can obtain the channel metrics 152 from an RFE of a second device (e.g. the second device 452B of FIG. 4B). In this example, the processor(s) 190 can determine the channel condition data 144 based on the channel metrics 152. In this example, the second device is remote from the device 102. The channel condition data include or are indicative ofone or more data loss metrics associated with the one or more communication sessions, one or more data delay metrics associated with the one or more communication sessions, a temporal distribution of one or more data loss metrics associated with the one or more communication sessions, a temporal distribution of one or more data delay metrics associated with the one or more communication sessions, or a combination thereof. The communication session(s) associated with the channel conditions can include communications between the first device and the second device, between the second device and one or more other devices, or both.

[0341] The method 3400 includes, at block 3404, obtaining updated parameters of an ML codec based on the channel condition data. For example, the processor(s) 190 can determine updated parameters (e.g., the parameters 142 of FIG. 1 A) of the ML codec 134 based on the channel condition data (e.g., the channel condition data 144) as described with reference to any of FIGS. 13-15.

[0342] The method 3400 includes, at block 3406, causing data indicating the updated parameters of the ML codec to be sent to the second device. For example, the data indicating the updated parameters can be transmitted to the second device via a peer-to- peer communication link with the first device or via a routed communication link. The data indicating the updated parameters can include the parameters, representative parameters, a codebook index associated with the updated parameters or the representative parameters, or other data identifying the update parameters.

[0343] Referring to FIG. 35, a particular implementation of a method 3500 of updating parameters of an ML codec based on channel conditions is shown. In a particular aspect, one or more operations of the method 3500 are performed by at least one of the RFE 172, the modem 170, the channel condition estimator 130, the codec updater 132, the ML codec 134, the processor(s) 190, the device 102, the system 100 of FIG. 1A, or a combination thereof. The ML codec can include or correspond to a data codec, an audio codec, a video codec, a graphics codec, or a combination thereof, and the parameters of the ML codec that are updated can include decoder parameters, encoder parameters, or both.

[0344] The method 3500 includes, at block 3502, obtaining, at one or more processors, channel condition data indicating channel conditions experienced by a radio frontend associated with the one or more processors. For example, the processor(s) 190 of FIG. 1A can obtain the channel metrics 152 from the RFE 172 associated with the processor(s) 190. In this example, the processor(s) 190 can determine the channel condition data 144 based on the channel metrics 152. The channel condition data include or are indicative of one or more data loss metrics associated with the one or more communication sessions, one or more data delay metrics associated with the one or more communication sessions, a temporal distribution of one or more data loss metrics associated with the one or more communication sessions, a temporal distribution of one or more data delay metrics associated with the one or more communication sessions, or a combination thereof. The method 3500 includes, at block 3504, causing data the channel condition data to be sent to a second device. For example, the channel condition data can correspond to, include, or be indicative of the channel metrics 152 of FIG. 4B, which are transmitted to another device. The communication session(s) associated with the channel conditions can include communications between a device that includes the RFE and the second device or between the device that includes the RFE and one or more other devices.

[0345] The method 3500 includes, at block 3506, receiving, from the second device, data indicating updated parameters of a machine-learning (ML) codec based on the channel condition data. For example, the second device can send updated parameters for an encoder of the ML codec, update parameters for a decoder of the ML codec, or both. The data indicating the updated parameters can include the parameters, representative parameters, a codebook index associated with the updated parameters or the representative parameters, or other data identifying the update parameters.

[0346] Any of the methods 3000, 3100, 3200, 3300, 3400, 3500 of FIG. 30-35 may be implemented by a field-programmable gate array (FPGA) device, an applicationspecific integrated circuit (ASIC), a processing unit such as a central processing unit (CPU), a DSP, a controller, another hardware device, firmware device, or any combination thereof. As an example, the any of the methods 3000, 3100, 3200, 3300,3400, 3500 of FIG. 30-35 may be performed by a processor that executes instructions, such as described with reference to FIG. 36.

[0347] Referring to FIG. 36, a block diagram of a particular illustrative implementation of a device is depicted and generally designated 3600. In various implementations, the device 3600 may have more or fewer components than illustrated in FIG. 36. In an illustrative implementation, the device 3600 may correspond to the device 102. In an illustrative implementation, the device 3600 may perform one or more operations described with reference to FIGS. 1 A-35.

[0348] In a particular implementation, the device 3600 includes a processor 3606 (e.g., a central processing unit (CPU)). The device 3600 of FIG. 36 also include one or more additional processors 3610 (e.g., one or more DSPs). In a particular aspect, the processor(s) 190 of FIG. 1 A corresponds to the processor 3606, the processors 3610, or a combination thereof. The processors 3610 may include a speech and music coderdecoder (CODEC) 3608 that includes a voice coder ("vocoder") encoder 3636, a vocoder decoder 3638, the channel condition estimator 130, the codec updater 132, the ML codec 134, or a combination thereof. In some embodiments, the vocoder encoder 3636 includes or corresponds to the encoder 136 of the ML codec 134, the vocoder decoder 3638 includes or corresponds to the decoder 138 of the ML codec 134, or both.

[0349] In this context, the term "processor" refers to an integrated circuit consisting of logic cells, interconnects, input / output blocks, clock management components, memory, and optionally other special purpose hardware components, designed to execute instructions and perform various computational tasks. Examples of processors include, without limitation, central processing units (CPUs), digital signal processors (DSPs), neural processing units (NPU), graphics processing units (GPUs), field programmable gate arrays (FPGAs), microcontrollers, quantum processors, coprocessors, vector processors, other similar circuits, and variants and combinations thereof. In some cases, a processor can be integrated with other components, such as communication components, input / output components, etc. to form a system on a chip (SOC) device or a packaged electronic device.

[0350] Taking CPUs as a starting point, a CPU typically includes one or more processor cores, each of which includes a complex, interconnected network of transistors and other circuit components defining logic gates, memory elements, etc. A core is responsible for executing instructions to, for example, perform arithmetic and logical operations. Typically, a CPU includes an Arithmetic Logic Unit (ALU) that handles mathematical operations and a Control Unit that generates signals to coordinate the operation of other CPU components, such as to manage operations of a fetch-decode- execute cycle.

[0351] CPUs and / or individual processor cores generally include local memory circuits, such as registers and cache to temporarily store data during operations. Registers include high-speed, small-sized memory units intimately connected to the logic cells of a CPU. Often registers include transistors arranged as groups of flip-flops, which are configured to store binary data. Caches include fast, on-chip memory circuits used to store frequently accessed data. Caches can be implemented, for example, using Static Random-Access Memory (SRAM) circuits.

[0352] Operations of a CPU (e.g., arithmetic operations, logic operations, and flow control operations) are directed by software and firmware. At the lowest level, the CPU includes an instruction set architecture (ISA) that specifies how individual operations are performed using hardware resources (e.g., registers, arithmetic units, etc.). Higher level software and firmware is translated into various combinations of ISA operations to cause the CPU to perform specific higher-level operations. For example, an ISA typically specifies how the hardware components of the CPU move and modify data to perform operations such as addition, multiplication, and subtraction, and high-level software is translated into sets of such operations to accomplish larger tasks, such as adding two columns in a spreadsheet. Generally, a CPU operates on various levels of software, including a kernel, an operating system, applications, and so forth, with each higher level of software generally being more abstracted from the ISA and usually more readily understandable by human users.

[0353] GPUs, NPUs, DSPs, microcontrollers, coprocessors, FPGAs, ASICS, and vector processors include components similar to those described above for CPUs. Thedifferences among these various types of processors are generally related to the use of specialized interconnection schemes and ISAs to improve a processor's ability to perform particular types of operations. For example, the logic gates, local memory circuits, and the interconnects therebetween of a GPU are specifically designed to improve parallel processing, sharing of data between processor cores, and vector operations, and the ISA of the GPU may define operations that take advantage of these structures. As another example, ASICs are highly specialized processors that include similar circuitry arranged and interconnected for a particular task, such as encryption or signal processing. As yet another example, FPGAs are programmable devices that include an array of configurable logic blocks (e.g., interconnect sets of transistors and memory elements) that can be configured (often on the fly) to perform customizable logic functions.

[0354] A processor can be configured to perform a specific task by including, within the processor, specialized hardware to perform the task. Additionally, or alternatively, the processor can be configured to perform a specific task by loading and / or executing instructions (e.g., computer code) that, when executed, cause the processor to perform the specific task. Loading executable instructions to perform the task causes an internal configuration change in the processor that transforms what may otherwise be a general- purpose processor into a special purpose processor for performing the task.

[0355] In FIG. 36, the device 3600 include the memory 140 and a CODEC 3634. The memory 140 may include instructions 3656, that are executable by the one or more additional processors 3610 (or the processor 3606) to implement the functionality described with reference to the channel condition estimator 130, the codec updater 132, the ML codec 134, or a combination thereof. In FIG. 36, the memory 140 also includes the parameters 142 of the ML codec 134, the channel condition data 144, the mapping data 146, or a combination thereof. The device 3600 also includes the modem 170 coupled, via the RFE 172 to the antenna 174.

[0356] The device 3600 may include a display 3628 coupled to a display controller 3626. One or more speakers 3692 and the microphone(s) 114 may be coupled to the CODEC 3634. The CODEC 3634 may include a digital-to-analog converter (DAC)3602, an analog-to-digital converter (ADC) 3604, or both. In a particular implementation, the CODEC 3634 may receive analog signals from the microphone(s) 114, convert the analog signals to digital signals using the analog-to-digital converter 3604, and provide the digital signals to the speech and music codec 3608. The speech and music codec 3608 may process the digital signals (e.g., using the ML codec 134). In a particular implementation, the speech and music codec 3608 may provide digital signals to the CODEC 3634. The CODEC 3634 may convert the digital signals to analog signals using the digital-to-analog converter 3602 and may provide the analog signals to the speaker(s) 3692.

[0357] In a particular implementation, the device 3600 may be included in a system -in- package or system-on-chip device 3622. In a particular implementation, the memory 140, the processor 3606, the processors 3610, the display controller 3626, the CODEC 3634, the modem 170, the RFE 172, or a combination thereof, are included in the system-in-package or system-on-chip device 3622. In a particular implementation, an input device 3630 and a power supply 3644 are coupled to the system-in-package or the system-on-chip device 3622. Moreover, in a particular implementation, as illustrated in FIG. 36, the display 3628, the input device 3630, the speaker(s) 3692, the microphone(s) 114, the antenna 174, and the power supply 3644 are external to the system-in-package or the system-on-chip device 3622. In a particular implementation, each of the display 3628, the input device 3630, the speaker(s) 3692, the microphone(s) 114, the antenna 174, and the power supply 3644 may be coupled to a component of the system-in-package or the system-on-chip device 3622, such as an interface or a controller.

[0358] The device 3600 may include a smart speaker, a speaker bar, a mobile communication device, a smart phone, a cellular phone, a laptop computer, a computer, a tablet, a personal digital assistant, a display device, a television, a gaming console, a music player, a radio, a digital video player, a digital video disc (DVD) player, a tuner, a camera, a navigation device, a vehicle, a headset, an augmented reality headset, a mixed reality headset, a virtual reality headset, an aerial vehicle, a home automation system, a voice-activated device, a wireless speaker and voice activated device, a portable electronic device, a car, a computing device, a communication device, an internet-of-things (loT) device, a virtual reality (VR) device, a base station, a mobile device, or any combination thereof.

[0359] In conjunction with the described implementations, an apparatus includes means for obtaining channel condition data indicating channel conditions experienced by a first radio frontend during a first communication session. For example, the means for obtaining the channel condition data can include the device 102, the modem 170, the RFE 172, the antenna 174, the channel condition estimator 130, the processor(s) 190, the integrated circuit 1802, the input circuitry 1806, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to obtain channel condition data, or a combination thereof.

[0360] The apparatus also includes means for updating parameters of an ML codec associated with the first communication session based on the channel condition data to generate updated parameters of the ML codec. For example, the means for updating parameters of an ML codec can include the device 102, the processor(s) 190, the codec updater 132, the ML trainer 1314, the integrated circuit 1802, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to update parameters of an ML codec, or a combination thereof.

[0361] In conjunction with the described implementations, an apparatus includes means for obtaining channel condition data indicating channel conditions experienced by a first radio frontend during a first communication session. For example, the means for obtaining the channel condition data can include the device 102, the modem 170, the RFE 172, the antenna 174, the channel condition estimator 130, the processor(s) 190, the integrated circuit 1802, the input circuitry 1806, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to obtain channel condition data, or a combination thereof.

[0362] The apparatus also includes means for updating parameters of an ML codec associated with the first communication session based on the channel condition data to generate updated parameters of the ML codec. For example, the means for updatingparameters of an ML codec can include the device 102, the processor(s) 190, codec updater 132, the ML trainer 1314, the integrated circuit 1802, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to update parameters of an ML codec, or a combination thereof.

[0363] In conjunction with the described implementations, an apparatus includes means for obtaining bit error data indicative of bit errors associated with a first communication session. For example, the means for obtaining the bit error data can include the device 102, the modem 170, the RFE 172, the antenna 174, the channel condition estimator 130, the processor(s) 190, the integrated circuit 1802, the input circuitry 1806, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to obtain bit error data, or a combination thereof.

[0364] The apparatus also includes means for updating parameters of an ML codec based on the bit error data to generate updated parameters of the ML codec. For example, the means for updating parameters of an ML codec can include the device 102, the processor(s) 190, the codec updater 132, the ML trainer 1314, the integrated circuit 1802, the processor 3606, the processor(s) 3610, the system -in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to update parameters of an ML codec, or a combination thereof.

[0365] In conjunction with the described implementations, an apparatus includes means for obtaining first channel condition data associated with channel conditions experienced at a first radio frontend during one or more first communication sessions. For example, the means for obtaining first channel condition data can include the device 102, the modem 170, the RFE 172, the antenna 174, the channel condition estimator 130, the processor(s) 190, the integrated circuit 1802, the input circuitry 1806, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to obtain channel condition data, or a combination thereof.

[0366] The apparatus also includes means for determining first parameters of an ML codec based on the first channel condition data and mapping data that associates channel condition data to parameters of the ML codec. For example, the means for determining parameters of an ML codec based on channel condition data and mapping data can include the device 102, the processor(s) 190, the codec updater 132, the ML trainer 1314, the integrated circuit 1802, the processor 3606, the processor(s) 3610, the system- in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to determine parameters of an ML codec, or a combination thereof.

[0367] The apparatus also includes means for causing data indicating the first parameters to be sent to a first device. For example, the means for causing data indicating the first parameters to be sent to the first device can include the device 102, the modem 170, the RFE 172, the antenna 174, the processor(s) 190, the integrated circuit 1802, the output circuitry 1808, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to cause data indicating parameters of an ML codec to be sent to another device, or a combination thereof.

[0368] In conjunction with the described implementations, an apparatus includes means for obtaining, by one or more processors of a first device, channel condition data indicating channel conditions experienced by a radio frontend of a second device. For example, the means for obtaining the channel condition data can include the device 102, the modem 170, the RFE 172, the antenna 174, the channel condition estimator 130, the processor(s) 190, the integrated circuit 1802, the input circuitry 1806, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to obtain channel condition data, or a combination thereof.

[0369] The apparatus also includes means for obtaining updated parameters of an ML codec based on the channel condition data. For example, the means for obtaining the updated parameters of the ML codec can include the device 102, the processor(s) 190, the codec updater 132, the ML trainer 1314, the integrated circuit 1802, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622,- I l l - the device 3600, other circuitry configured to obtain updated parameters of an ML codec, or a combination thereof.

[0370] The apparatus also includes means for causing data indicating the updated parameters of the ML codec to be sent to the second device. For example, the means for causing data indicating the updated parameters to be sent to the second device can include the device 102, the modem 170, the RFE 172, the antenna 174, the processor(s) 190, the integrated circuit 1802, the output circuitry 1808, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to cause data indicating parameters of an ML codec to be sent to another device, or a combination thereof.

[0371] In conjunction with the described implementations, an apparatus includes means for obtaining, at one or more processors, channel condition data indicating channel conditions experienced by a radio frontend associated with the one or more processors. For example, the means for obtaining the channel condition data can include the device 102, the modem 170, the RFE 172, the antenna 174, the channel condition estimator 130, the processor(s) 190, the integrated circuit 1802, the input circuitry 1806, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to obtain channel condition data, or a combination thereof.

[0372] The apparatus also includes means for causing data the channel condition data to be sent to a second device. For example, the means for causing data the channel condition data to be sent to the second device can include the device 102, the modem 170, the RFE 172, the antenna 174, the processor(s) 190, the integrated circuit 1802, the output circuitry 1808, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to cause channel condition data to be sent to another device, or a combination thereof.

[0373] The apparatus also includes means for receiving, from the second device, data indicating updated parameters of an ML codec based on the channel condition data. For example, the means for receiving updated parameters from the second device caninclude the device 102, the modem 170, the RFE 172, the antenna 174, the processor(s) 190, the integrated circuit 1802, the output circuitry 1808, the processor 3606, the processor(s) 3610, the system-in-package or the system-on-chip device 3622, the device 3600, other circuitry configured to receive updated parameters of an ML codec from another device, or a combination thereof.

[0374] In some implementations, a non-transitory computer-readable medium (e.g., a computer-readable storage device, such as the memoryl40) includes instructions (e.g., the instructions 3656) that, when executed by one or more processors (e.g., the one or more processors 3610 or the processor 3606), cause the one or more processors to obtain channel condition data indicating channel conditions experienced by a first radio frontend during a first communication session and obtain updated parameters of an ML codec based on the channel condition data.

[0375] In some implementations, a non-transitory computer-readable medium (e.g., a computer-readable storage device, such as the memoryl40) includes instructions (e.g., the instructions 3656) that, when executed by one or more processors (e.g., the one or more processors 3610 or the processor 3606), cause the one or more processors to obtain first channel condition data indicating first channel conditions experienced by a first radio frontend in a first location; obtain, based on the first channel condition data, a first set of parameters of an ML codec for the first channel conditions; and cause data indicating the first set of parameters of the ML codec to be sent to a second device based on location data associated with the second device.

[0376] In some implementations, a non-transitory computer-readable medium (e.g., a computer-readable storage device, such as the memoryl40) includes instructions (e.g., the instructions 3656) that, when executed by one or more processors (e.g., the one or more processors 3610 or the processor 3606), cause the one or more processors to obtain first channel condition data associated with channel conditions experienced at a first radio frontend during one or more first communication sessions; determine first parameters of an ML codec based on the first channel condition data and mapping data that associates channel condition data to parameters of the ML codec; and send data indicating the first parameters to a first device.

[0377] In some implementations, a non-transitory computer-readable medium (e.g., a computer-readable storage device, such as the memoryl40) includes instructions (e.g., the instructions 3656) that, when executed by one or more processors (e.g., the one or more processors 3610 or the processor 3606), cause the one or more processors to obtain bit error data indicative of bit errors associated with a first communication session and obtain updated parameters of a machine-learning (ML) codec based on the bit error data.

[0378] In some implementations, a non-transitory computer-readable medium (e.g., a computer-readable storage device, such as the memory 140) includes instructions (e.g., the instructions 3656) that, when executed by one or more processors (e.g., the one or more processors 3610 or the processor 3606), cause the one or more processors to obtain channel condition data indicating channel conditions experienced by a radio frontend of a second device, obtain updated parameters of the ML codec based on the channel condition data, and cause data indicating the updated parameters of the ML codec to be sent to the second device.

[0379] In some implementations, a non-transitory computer-readable medium (e.g., a computer-readable storage device, such as the memory 140) includes instructions (e.g., the instructions 3656) that, when executed by one or more processors (e.g., the one or more processors 3610 or the processor 3606), cause the one or more processors to obtain channel condition data indicating channel conditions experienced by a radio frontend associated with the one or more processors, cause the one or more processors to cause data the channel condition data to be sent to a second device, and receive, from the second device, data indicating updated parameters of an ML codec based on the channel condition data.

[0380] Particular aspects of the disclosure are described below in sets of interrelated Examples:

[0381] According to Example 1, a device includes a memory configured to store parameters of an ML codec; and one or more processors configured to obtain channel condition data indicating channel conditions experienced by a first radio frontend duringa first communication session; and obtain updated parameters of the ML codec based on the channel condition data.

[0382] Example 2 includes the device of Example 1, wherein, to obtain the updated parameters of the ML codec, the one or more processors are configured to use an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; modify the encoded data samples in a manner representative of the channel conditions to generate modified encoded data samples; use a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples; determine an error metric based on a difference between the set of input data samples and the decoded data samples; and generate the updated parameters by adapting decoder parameters of the ML codec, encoder parameters of the ML codec, or both, to reduce the error metric.

[0383] Example 3 includes the device of Example 1 or Example 2, wherein the one or more processors are configured to obtain the updated parameters of the ML codec during the first communication session.

[0384] Example 4 includes the device of any of Examples 1 to 2, wherein the one or more processors are configured to obtain the updated parameters of the ML codec after the first communication session.

[0385] Example 5 includes the device of any of Examples 1 to 4, wherein the one or more processors are integrated within the first device.

[0386] Example 6 includes the device of any of Examples 1 to 4, wherein the one or more processors are integrated within a second device distinct from the first device.

[0387] Example 7 includes the device of any of Examples 1 to 6, wherein the ML codec includes a data codec, an audio codec, a video codec, a graphics codec, or a combination thereof.

[0388] Example 8 includes the device of any of Examples 1 to 7, wherein the channel condition data include or are indicative of one or more data loss metrics associated with the first communication session, one or more data delay metrics associated with the firstcommunication session, a temporal distribution of one or more data loss metrics associated with the first communication session, a temporal distribution of one or more data delay metrics associated with the first communication session, or a combination thereof.

[0389] Example 9 includes the device of any of Examples 1 to 8, wherein the updated parameters based on the channel condition data correspond to parameters of a decoder of the ML codec.

[0390] Example 10 includes the device of any of Examples 1 to 9, wherein the one or more processors are configured to send the updated parameters to another device for use during a second communication session.

[0391] Example 11 includes the device of any of Examples 1 to 10, wherein the one or more processors are configured to use the updated parameters during a second communication session.

[0392] Example 12 includes the device of any of Examples 1 to 11, wherein the one or more processors are configured to obtain the channel condition data via a transmission from the first device during or after the first communication session.

[0393] Example 13 includes the device of any of Examples 1 to 12, wherein the one or more processors are configured to send the updated parameters of the ML codec to the first device during or after the first communication session.

[0394] Example 14 includes the device of any of Examples 1 to 13, wherein the one or more processors are configured to determine representative parameters based on the updated parameters; and store, at the memory, mapping data that associates the channel condition data with a codebook index, wherein the codebook index is associated with the representative parameters.

[0395] Example 15 includes the device of any of Examples 1 to 14 and further includes a modem coupled to the one or more processors and configured to receive transmissions including encoded data, wherein the one or more processors are configured to decode the encoded data using the ML codec.

[0396] According to Example 16, a method includes obtaining, by one or more processors, channel condition data indicating channel conditions experienced by a first radio frontend during a first communication session; and obtaining, by the one or more processors, updated parameters of an ML codec associated with the first communication session based on the channel condition data.

[0397] Example 17 includes the method of Example 16, wherein obtaining the updated parameters of the ML codec includes using an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; modifying the encoded data samples in a manner representative of the channel conditions to generate modified encoded data samples; using a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples; determining an error metric based on a difference between the set of input data samples and the decoded data samples; and generating the updated parameters by updating decoder parameters of the ML codec, encoder parameters of the ML codec, or both, to reduce the error metric.

[0398] Example 18 includes the method of Example 16 or Example 17, wherein the parameters of the ML codec are updated during the first communication session.

[0399] Example 19 includes the method of any of Examples 16 to 17, wherein the parameters of the ML codec are updated after the first communication session.

[0400] Example 20 includes the method of any of Examples 16 to 19, wherein the ML codec includes a data codec, an audio codec, a video codec, a graphics codec, or a combination thereof.

[0401] Example 21 includes the method of any of Examples 16 to 20, wherein the channel condition data include or are indicative of one or more data loss metrics associated with the first communication session, one or more data delay metrics associated with the first communication session, a temporal distribution of one or more data loss metrics associated with the first communication session, a temporal distribution of one or more data delay metrics associated with the first communication session, or a combination thereof.

[0402] Example 22 includes the method of any of Examples 16 to 21, wherein the updated parameters of the ML codec correspond to parameters of a decoder of the ML codec.

[0403] Example 23 includes the method of any of Examples 16 to 22 and further includes sending the updated parameters to another device for use during a second communication session.

[0404] Example 24 includes the method of any of Examples 16 to 23 and further includes using the updated parameters during a second communication session.

[0405] Example 25 includes the method of any of Examples 16 to 24 and further includes obtaining the channel condition data via a transmission from the first device during or after the first communication session.

[0406] Example 26 includes the method of any of Examples 16 to 25 and further includes sending the updated parameters of the ML codec to the first device during or after the first communication session.

[0407] Example 27 includes the method of any of Examples 16 to 26, further includes determining representative parameters based on the updated parameters; and storing mapping data that associates the channel condition data with a codebook index, wherein the codebook index is associated with the representative parameters.

[0408] According to Example 28, a non-transitory computer-readable medium stores instructions that are executable by one or more processors to cause the one or more processors to obtain channel condition data indicating channel conditions experienced by a first radio frontend during a first communication session; and obtain update parameters of an ML codec based on the channel condition data.

[0409] Example 29 includes the non-transitory computer-readable medium of Example 28, wherein, to obtain the updated parameters of the ML codec, the instructions cause the one or more processors to use an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; modify the encoded data samples in a manner representative of the channel conditions to generate modified encoded datasamples; use a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples; determine an error metric based on a difference between the set of input data samples and the decoded data samples; and generate the updated parameters by updating decoder parameters of the ML codec, encoder parameters of the ML codec, or both, to reduce the error metric.

[0410] Example 30 includes the non-transitory computer-readable medium of Example 28 or Example 29, wherein the instructions cause the one or more processors to obtain the updated parameters of the ML codec during the first communication session.

[0411] Example 31 includes the non-transitory computer-readable medium of any of Examples 28 to 30, wherein the instructions cause the one or more processors to obtain the updated parameters of the ML codec after the first communication session.

[0412] Example 32 includes the non-transitory computer-readable medium of any of Examples 28 to 31, wherein the ML codec includes a data codec, an audio codec, a video codec, a graphics codec, or a combination thereof.

[0413] Example 33 includes the non-transitory computer-readable medium of any of Examples 28 to 32, wherein the channel condition data include or are indicative of one or more data loss metrics associated with the first communication session, one or more data delay metrics associated with the first communication session, a temporal distribution of one or more data loss metrics associated with the first communication session, a temporal distribution of one or more data delay metrics associated with the first communication session, or a combination thereof.

[0414] Example 36 includes the non-transitory computer-readable medium of any of Examples 28 to 33, wherein the updated parameters of the ML codec correspond to parameters of a decoder of the ML codec.

[0415] Example 35 includes the non-transitory computer-readable medium of any of Examples 28 to 36, wherein the instructions cause the one or more processors to send the updated parameters to another device for use during a second communication session.

[0416] Example 36 includes the non-transitory computer-readable medium of any of Examples 28 to 35, wherein the instructions cause the one or more processors to use the updated parameters during a second communication session.

[0417] Example 37 includes the non-transitory computer-readable medium of any of Examples 28 to 36, wherein the instructions cause the one or more processors to obtain the channel condition data via a transmission from the first device during or after the first communication session.

[0418] Example 38 includes the non-transitory computer-readable medium of any of Examples 28 to 37, wherein the instructions cause the one or more processors to send the updated parameters of the ML codec to the first device during or after the first communication session.

[0419] Example 39 includes the non-transitory computer-readable medium of any of Examples 28 to 38, wherein the instructions cause one or more processors to determine representative parameters based on the updated parameters; and store mapping data that associates the channel condition data with a codebook index, wherein the codebook index is associated with the representative parameters.

[0420] According to Example 40, an apparatus includes means for obtaining channel condition data indicating channel conditions experienced by a first radio frontend during a first communication session; and means for obtaining updated parameters of an ML codec associated with the first communication session based on the channel condition data.

[0421] Example 41 includes the apparatus of Example 40, wherein the means for obtaining the updated parameters of the ML codec include means for using an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; means for modifying the encoded data samples in a manner representative of the channel conditions to generate modified encoded data samples; means for using a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples; means for determining an error metric based on a difference between the set of input data samples and the decoded data samples; and means forgenerating the updated parameters by updating decoder parameters of the ML codec, encoder parameters of the ML codec, or both, to reduce the error metric.

[0422] Example 42 includes the apparatus of Example 40 or Example 41, wherein the means for obtaining the updated parameters of the ML codec are configured to update the parameters of the ML codec during the first communication session.

[0423] Example 43 includes the apparatus of any of Examples 40 to 42, wherein the means for obtaining the updated parameters of the ML codec are configured to update the parameters of the ML codec after the first communication session.

[0424] Example 44 includes the apparatus of any of Examples 40 to 43, wherein the ML codec includes a data codec, an audio codec, a video codec, a graphics codec, or a combination thereof.

[0425] Example 45 includes the apparatus of any of Examples 40 to 44, wherein the channel condition data include or are indicative of one or more data loss metrics associated with the first communication session, one or more data delay metrics associated with the first communication session, a temporal distribution of one or more data loss metrics associated with the first communication session, a temporal distribution of one or more data delay metrics associated with the first communication session, or a combination thereof.

[0426] Example 46 includes the apparatus of any of Examples 40 to 45, wherein the updated parameters of the ML codec correspond to parameters of a decoder of the ML codec.

[0427] Example 47 includes the apparatus of any of Examples 40 to 46 and further includes means for sending the updated parameters to another device for use during a second communication session.

[0428] Example 48 includes the apparatus of any of Examples 40 to 47 and further includes means for using the updated parameters during a second communication session.

[0429] Example 49 includes the apparatus of any of Examples 40 to 48 and further includes means for obtaining the channel condition data via a transmission from the first device during or after the first communication session.

[0430] Example 50 includes the apparatus of any of Examples 40 to 49 and further includes means for sending the updated parameters of the ML codec to the first device during or after the first communication session.

[0431] Example 51 includes the apparatus of any of Examples 40 to 50, further includes means for determining representative parameters based on the updated parameters; and means for storing mapping data that associates the channel condition data with a codebook index, wherein the codebook index is associated with the representative parameters.

[0432] According to Example 52, a device includes a memory configured to store channel condition data; and one or more processors configured to obtain first channel condition data indicating first channel conditions experienced by a first radio frontend in a first location; obtain, based on the first channel condition data, a first set of parameters of a machine-learning (ML) codec for the first channel conditions; and based on location data associated with a second device that is associated with a second radio frontend, cause data indicating the first set of parameters of the ML codec to be sent to the second device.

[0433] Example 53 includes the device of Example 52, wherein the location data associated with the second device indicates a detected location of the second device.

[0434] Example 54 includes the device of Example 52, wherein the location data associated with the second device indicates a predicted future location of the second device.

[0435] Example 55 includes the device of any of Examples 52 to 54, wherein the location data associated with the second device indicates that the second device is proximate to the first location.

[0436] Example 56 includes the device of any of Examples 52 to 55, wherein the one or more processors are integrated in a vehicle.

[0437] Example 57 includes the device of any of Examples 52 to 55, wherein the one or more processors are integrated in a mobile communication device.

[0438] Example 58 includes the device of any of Examples 52 to 55, wherein the one or more processors are integrated in the first device.

[0439] Example 59 includes the device of any of Examples 52 to 55, wherein the one or more processors are integrated in a network device.

[0440] Example 60 includes the device of any of Examples 52 to 59, wherein the one or more processors are configured to identify a cluster of devices based on locations of the devices; and send the data indicating the first set of parameters of the ML codec to one or more devices of the cluster of devices, wherein the cluster of devices includes at least the second device.

[0441] Example 61 includes the device of Example 60, wherein the one or more processors are configured to identify the cluster of devices further based on motion of at least one of the devices.

[0442] Example 62 includes the device of Example 60 or Example 61, wherein the one or more processors are configured to identify the cluster of devices further based on geofence data that designates a boundary of the cluster of devices.

[0443] Example 63 includes the device of any of Examples 60 to 62, wherein the one or more processors are configured to identify the cluster of devices further based on identifiers associated with the devices.

[0444] Example 64 includes the device of any of Examples 60 to 63, wherein the one or more processors are configured to send updated data indicating parameters of the ML codec at an interval determined based on relative movement of two or more of the devices of the cluster of devices.

[0445] Example 65 includes the device of any of Examples 60 to 64, wherein the devices of the cluster of devices are moving along a thoroughfare.

[0446] Example 66 includes the device of any of Examples 52 to 65 and further includes a transmitter coupled to the one or more processors, wherein the transmitter is configured to transmit the data indicating the first set of parameters of the ML codec to the second device via a peer-to-peer communication link with the second device.

[0447] Example 67 includes the device of any of Examples 52 to 65 and further includes a transmitter coupled to the one or more processors, wherein the transmitter is configured to transmit the data indicating the first set of parameters of the ML codec to the second device via a routed communication link with the second device.

[0448] Example 68 includes the device of any of Examples 52 to 65 and further includes a transmitter coupled to the one or more processors, wherein the transmitter is configured to transmit the data indicating the first set of parameters of the ML codec and data identifying the first location to a network device, and wherein the network device is configured to send the data indicating the first set of parameters of the ML codec to the second device based on the data identifying the first location and the location data associated with the second device.

[0449] Example 69 includes the device of any of Examples 52 to 65 and further includes a transmitter coupled to the one or more processors, wherein the transmitter is configured to broadcast the data indicating the first set of parameters of the ML codec.

[0450] Example 70 includes the device of any of Examples 52 to 69, wherein, to obtain the first set of parameters of the ML codec for the first channel conditions, the one or more processors are configured to send the first channel condition data to a remote device; and receive data indicating the first set of parameters from the remote device.

[0451] Example 71 includes the device of any of Examples 52 to 69, wherein, to obtain the first set of parameters of the ML codec for the first channel conditions, the one or more processors are configured to use an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; modify the encoded data samplesbased on the first channel condition data to generate modified encoded data samples; use a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples; determine an error metric based on a difference between the set of input data samples and the decoded data samples; and generate updated parameters by updating decoder parameters of the ML codec, encoder parameters of the ML codec, or both, to reduce the error metric.

[0452] Example 72 includes the device of any of Examples 52 to 71, wherein the data indicating the first set of parameters of the ML codec includes a codebook index identifying the first set of parameters.

[0453] Example 73 includes the device of any of Examples 52 to 69, wherein, to obtain the first set of parameters of the ML codec for the first channel conditions, the one or more processors are configured to access mapping data that associates the first channel condition data with a codebook index, and wherein the codebook index is associated with the first set of parameters of the ML codec.

[0454] Example 74 includes the device of any of Examples 52 to 73, wherein the data indicating the first set of parameters of the ML codec includes a first set of sparse weight updates to update parameters of the ML codec at the second device to the first set of parameters.

[0455] Example 75 includes the device of any of Examples 52 to 74, wherein the first set of parameters of the ML codec correspond to parameters of a decoder of the ML codec.

[0456] Example 76 includes the device of any of Examples 52 to 74, wherein the first set of parameters of the ML codec include parameters of a decoder of the ML codec and parameters of an encoder of the ML codec.

[0457] According to Example 77, a method includes obtaining, by one or more processors, first channel condition data indicating first channel conditions experienced by a first radio frontend in a first location; obtaining, by the one or more processors and based on the first channel condition data, a first set of parameters of a machine-learning(ML) codec for the first channel conditions; and based on location data associated with a second device that is associated with a second radio frontend, causing data indicating the first set of parameters of the ML codec to be sent to the second device.

[0458] Example 78 includes the method of Example 77, wherein the location data associated with the second device indicates a detected location of the second device.

[0459] Example 79 includes the method of Example 77, wherein the location data associated with the second device indicates a predicted future location of the second device.

[0460] Example 80 includes the method of any of Examples 77 to 79, wherein the location data associated with the second device indicates that the second device is proximate to the first location.

[0461] Example 81 includes the method of any of Examples 77 to 80, further includes identifying a cluster of devices based on locations of the devices; and sending the data indicating the first set of parameters of the ML codec to one or more devices of the cluster of devices, wherein the cluster of devices includes at least the second device.

[0462] Example 82 includes the method of Example 81, wherein the cluster of devices are identified further based on motion of at least one of the devices.

[0463] Example 83 includes the method of Example 81 or Example 82, wherein the cluster of devices are identified further based on geofence data that designates a boundary of the cluster of devices.

[0464] Example 84 includes the method of any of Examples 81 to 83, wherein the cluster of devices are identified further based on identifiers associated with the devices.

[0465] Example 85 includes the method of any of Examples 81 to 84 and further includes sending updated data indicating parameters of the ML codec at an interval determined based on relative movement of two or more of the devices of the cluster of devices.

[0466] Example 86 includes the method of any of Examples 81 to 85, wherein the devices of the cluster of devices are moving along a thoroughfare.

[0467] Example 87 includes the method of any of Examples 77 to 86 and further includes transmitting the data indicating the first set of parameters of the ML codec to the second device via a peer-to-peer communication link with the second device.

[0468] Example 88 includes the method of any of Examples 77 to 86 and further includes transmitting the data indicating the first set of parameters of the ML codec to the second device via a routed communication link with the second device.

[0469] Example 89 includes the method of any of Examples 77 to 86 and further includes transmitting the data indicating the first set of parameters of the ML codec and data identifying the first location to a network device, and wherein the network device is configured to send the data indicating the first set of parameters of the ML codec to the second device based on the data identifying the first location and the location data associated with the second device.

[0470] Example 90 includes the method of any of Examples 77 to 86 and further includes broadcasting the data indicating the first set of parameters of the ML codec.

[0471] Example 91 includes the method of any of Examples 77 to 90, wherein obtaining the first set of parameters of the ML codec for the first channel conditions includes sending the first channel condition data to a remote device; and receiving data indicating the first set of parameters from the remote device.

[0472] Example 92 includes the method of any of Examples 77 to 90, wherein obtaining the first set of parameters of the ML codec for the first channel conditions includes using an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; modifying the encoded data samples based on the first channel condition data to generate modified encoded data samples; using a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples; determining an error metric based on a difference between the set of input data samples and the decoded data samples; and generating updated parameters by updating decoderparameters of the ML codec, encoder parameters of the ML codec, or both, to reduce the error metric.

[0473] Example 93 includes the method of any of Examples 77 to 92, wherein the data indicating the first set of parameters of the ML codec includes a codebook index identifying the first set of parameters.

[0474] Example 94 includes the method of any of Examples 77 to 90, wherein obtaining the first set of parameters of the ML codec for the first channel conditions comprises accessing mapping data that associates the first channel condition data with a codebook index, and wherein the codebook index is associated with the first set of parameters of the ML codec.

[0475] Example 95 includes the method of any of Examples 77 to 94, wherein the data indicating the first set of parameters of the ML codec includes a first set of sparse weight updates to update parameters of the ML codec at the second device to the first set of parameters.

[0476] Example 96 includes the method of any of Examples 77 to 95, wherein the first set of parameters of the ML codec correspond to parameters of a decoder of the ML codec.

[0477] Example 97 includes the method of any of Examples 77 to 95, wherein the first set of parameters of the ML codec include parameters of a decoder of the ML codec and parameters of an encoder of the ML codec.

[0478] According to Example 98, a non-transitory computer-readable medium storing instructions that are executable by one or more processors to cause the one or more processors to obtain first channel condition data indicating first channel conditions experienced by a first radio frontend in a first location; obtain, based on the first channel condition data, a first set of parameters of a machine-learning (ML) codec for the first channel conditions; and based on location data associated with a second device that is associated with a second radio frontend, cause data indicating the first set of parameters of the ML codec to be sent to the second device.

[0479] Example 99 includes the non-transitory computer-readable medium of Example 98, wherein the location data associated with the second device indicates a detected location of the second device.

[0480] Example 100 includes the non-transitory computer-readable medium of Example 98, wherein the location data associated with the second device indicates a predicted future location of the second device.

[0481] Example 101 includes the non-transitory computer-readable medium of any of Examples 98 to 100, wherein the location data associated with the second device indicates that the second device is proximate to the first location.

[0482] Example 102 includes the non-transitory computer-readable medium of any of Examples 98 to 101, wherein the instructions cause the one or more processors to identify a cluster of devices based on locations of the devices; and send the data indicating the first set of parameters of the ML codec to one or more devices of the cluster of devices, wherein the cluster of devices includes at least the second device.

[0483] Example 103 includes the non-transitory computer-readable medium of Example 102, wherein the instructions cause the one or more processors to identify the cluster of devices further based on motion of at least one of the devices.

[0484] Example 104 includes the non-transitory computer-readable medium of Example 102 or Example 103, wherein the instructions cause the one or more processors to identify the cluster of devices further based on geofence data that designates a boundary of the cluster of devices.

[0485] Example 105 includes the non-transitory computer-readable medium of any of Examples 102 to 104, wherein the instructions cause the one or more processors to identify the cluster of devices further based on identifiers associated with the devices.

[0486] Example 106 includes the non-transitory computer-readable medium of any of Examples 102 to 105, wherein the instructions cause the one or more processors to send updated data indicating parameters of the ML codec at an interval determined based on relative movement of two or more of the devices of the cluster of devices.

[0487] Example 107 includes the non-transitory computer-readable medium of any of Examples 102 to 106, wherein the devices of the cluster of devices are moving along a thoroughfare.

[0488] Example 108 includes the non-transitory computer-readable medium of any of Examples 98 to 107, wherein the instructions cause the one or more processors to transmit the data indicating the first set of parameters of the ML codec to the second device via a peer-to-peer communication link with the second device.

[0489] Example 109 includes the non-transitory computer-readable medium of any of Examples 98 to 107, wherein the instructions cause the one or more processors to transmit the data indicating the first set of parameters of the ML codec to the second device via a routed communication link with the second device.

[0490] Example 110 includes the non-transitory computer-readable medium of any of Examples 98 to 107, wherein the instructions cause the one or more processors to transmit the data indicating the first set of parameters of the ML codec and data identifying the first location to a network device, and wherein the network device is configured to send the data indicating the first set of parameters of the ML codec to the second device based on the data identifying the first location and the location data associate...

Claims

WHAT IS CLAIMED IS:

1. A first device comprising: a memory configured to store parameters for a machine-learning (ML) codec; and one or more processors configured to: obtain channel condition data indicating channel conditions experienced by a radio frontend of a second device; obtain updated parameters of the ML codec based on the channel condition data; and cause data indicating the updated parameters of the ML codec to be sent to the second device.

2. The first device of claim 1, wherein, to obtain the updated parameters of the ML codec, the one or more processors are configured to: use an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; modify the encoded data samples in a manner representative of the channel conditions to generate modified encoded data samples; use a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples; determine an error metric based on a difference between the set of input data samples and the decoded data samples; and generate the updated parameters by updating decoder parameters of the ML codec, encoder parameters of the ML codec, or both, to reduce the error metric.

3. The first device of claim 1, wherein the ML codec includes a data codec, an audio codec, a video codec, a graphics codec, or a combination thereof.

4. The first device of claim 1, wherein the channel condition data include or are indicative of one or more data loss metrics associated with a communication session, one or more data delay metrics associated with the communication session, a temporal distribution of one or more data loss metrics associated with the communication session, a temporal distribution of one or more data delay metrics associated with the communication session, or a combination thereof.

5. The first device of claim 1, wherein the updated parameters based on the channel condition data correspond to parameters of a decoder of the ML codec.

6. The first device of claim 1, wherein the channel condition data are associated with a communication session, and wherein the one or more processors are configured to cause the updated parameters to be sent to the second device for use during or after the communication session.

7. The first device of claim 1, wherein the channel condition data are associated with a communication session, and wherein the one or more processors are configured to obtain the channel condition data via a transmission from the second device during or after the communication session.

8. The first device of claim 1, wherein the one or more processors are configured to: determine representative parameters based on the updated parameters; and store, at the memory, mapping data that associates the channel condition data with a codebook index, wherein the codebook index is associated with the representative parameters.

9. The first device of claim 1, wherein the one or more processors are configured to retrieve the updated parameters from mapping data that associates particular channel conditions with corresponding parameters of the ML codec.

10. The first device of claim 1, wherein the one or more processors are configured to use the updated parameters to encode data for transmission to the second device during a communication session with the second device.

11. The first device of claim 1, wherein the data indicating the updated parameters include a codebook index associated with the updated parameters.

12. The first device of claim 1, further comprising a modem coupled to the one or more processors and configured to receive transmissions including channel condition data.

13. The first device of claim 1, wherein the one or more processors are integrated in a vehicle.

14. The first device of claim 1, wherein the one or more processors are integrated in a mobile communication device.

15. The first device of claim 1, wherein the one or more processors are integrated in a server.

16. A method comprising: obtaining, by one or more processors of a first device, channel condition data indicating channel conditions experienced by a radio frontend of a second device; obtaining, by the one or more processors, updated parameters of an ML codec based on the channel condition data; and causing, by the one or more processors, data indicating the updated parameters of the ML codec to be sent to the second device.

17. The method of claim 16, wherein obtaining the updated parameters of the ML codec includes: using an encoder of the ML codec to encode a set of input data samples to generate encoded data samples; modifying the encoded data samples in a manner representative of the channel conditions to generate modified encoded data samples; using a decoder of the ML codec to decode the modified encoded data samples to generate decoded data samples; determining an error metric based on a difference between the set of input data samples and the decoded data samples; and generating the updated parameters by updating decoder parameters of the ML codec, encoder parameters of the ML codec, or both, to reduce the error metric.

18. The method of claim 16, further comprising using the updated parameters to encode data for transmission to the second device during a communication session with the second device.

19. The method of claim 16, obtaining the updated parameters of the ML codec includes retrieving the updated parameters from mapping data that associates particular channel conditions with corresponding parameters of the ML codec.

20. A first device comprising: a memory configured to store parameters for a machine-learning (ML) codec; and one or more processors configured to: obtain channel condition data indicating channel conditions experienced by a radio frontend associated with the one or more processors; cause data the channel condition data to be sent to a second device; and receive, from the second device, data indicating updated parameters of the ML codec based on the channel condition data.

21. The first device of claim 20, wherein the one or more processors are configured to use the updated parameters to encode data for transmission to the second device during a communication session with the second device.

22. The first device of claim 20, wherein the channel condition data include or are indicative of one or more data loss metrics associated with a communication session, one or more data delay metrics associated with the communication session, a temporal distribution of one or more data loss metrics associated with the communication session, a temporal distribution of one or more data delay metrics associated with the communication session, or a combination thereof.

23. The first device of claim 20, wherein the channel condition data are associated with a communication session, and wherein the one or more processors are configured to obtain the channel condition data via a transmission from the second device during the communication session.

24. The first device of claim 20, wherein the data indicating the updated parameters include a codebook index associated with the updated parameters, and wherein the one or more processors are configured to retrieve the updated parameters from mapping data that associates codebook indices with corresponding parameters of the ML codec.

25. The first device of claim 20, further comprising a modem coupled to the one or more processors and configured to facilitate transmission of the channel condition data and receipt of the data indicating the updated parameters.

26. The first device of claim 20, wherein the one or more processors are integrated in a vehicle.

27. The first device of claim 20, wherein the one or more processors are integrated in a mobile communication device.

28. The first device of claim 20, wherein the one or more processors are integrated in an extended reality device.

29. A method comprising: obtaining, at one or more processors, channel condition data indicating channel conditions experienced by a radio frontend associated with the one or more processors; causing data the channel condition data to be sent to a second device; and receiving, from the second device, data indicating updated parameters of a machinelearning (ML) codec based on the channel condition data.

30. The method of claim 29, further comprising: receiving encoded data via one or more transmissions during a communication session; and using the updated parameters to decode the encoded data.

Images