Codec configuration adaptation based on packet loss rate

Abstract

A method of communication includes receiving, at a first device, configuration data from a configuration server, the configuration data indicating a first packet loss rate threshold associated with a first codec configuration. The method includes determining, at a first device, a packet loss rate associated with one or more first packets received at the first device from a second device via a network. The method includes sending a request to a second device to change a codec configuration of the second device based on determining that a decoder of the first device has a first codec configuration and a packet loss rate satisfies a first packet loss rate threshold. The method further includes receiving, at the first device, a second packet from a second device via the network, the second packet encoded based on a second codec configuration.

Description

[0001] This application is a divisional application of the invention patent application with the application date of May 5, 2020, application number 202080032872.X, and name “Codec configuration adaptation based on packet loss rate”.

[0002] Claiming priority

[0003] This application claims the benefit of priority from the commonly owned U.S. Provisional Patent Application No. 62 / 843,826 filed on May 6, 2019, U.S. Provisional Patent Application No. 62 / 866,728 filed on June 26, 2019, and U.S. Non-Provisional Patent Application No. 16 / 865,579 filed on May 4, 2020, the contents of each of which are expressly incorporated herein by reference in their entirety. Technical Field

[0004] Generally speaking, the present disclosure relates to adjusting the configuration of a coder-decoder (codec) based on a packet loss rate. Background Art

[0005] Advances in technology have led to smaller and more powerful computing devices. For example, there are currently various portable personal computing devices, including small, lightweight and easily carried by users of wireless phones (such as mobile and smart phones, tablet devices and laptop computers). These devices can transmit voice and data packets on wireless networks. In addition, many such devices incorporate additional functions, such as digital cameras, digital video cameras, digital recorders and audio file players. In addition, such devices can process executable instructions, including software applications (such as web browser applications) that can be used to access the Internet. As such, these devices can include significant computing power.

[0006] The transmission of data to such devices (such as encoded audio data sent to a mobile phone device during a phone call) may be affected based on the packet loss rate associated with the transmitted data. For example, the encoded audio data may be transmitted as a packet stream from a transmitting device to a mobile phone device via a wireless network. One or more packets of the audio data stream may be "lost", such as packets discarded due to buffer overflow at a network switch, or packets that are delayed so that the audio data of the packet is not available for playback at the mobile phone device in a timely manner. When packets are lost at a high enough rate, a perceptible loss of audio quality may result, thereby impairing the user experience. Summary of the invention

[0007] In certain aspects, a method of communication includes receiving, at a first device, configuration data from a configuration server, the configuration data indicating a first packet loss rate threshold associated with a first codec configuration. The method includes determining, at the first device, a packet loss rate associated with one or more first packets received at the first device from a second device via a network. The method includes sending, to the second device, a request to change the codec configuration of the second device based on determining that a decoder of the first device has the first codec configuration and the packet loss rate satisfies the first packet loss rate threshold. The method also includes receiving, at the first device, from the second device via the network, a second packet, the second packet being encoded based on the second codec configuration.

[0008] In another specific aspect, a device includes a memory and one or more processors. The memory is configured to store configuration data received from a configuration server. The configuration data indicates a first packet loss rate threshold associated with a first codec configuration. The one or more processors are configured to determine a packet loss rate associated with one or more first packets received from a second device via a network. The one or more processors are configured to send a request to the second device to change the codec configuration of the second device based on determining that a decoder has the first codec configuration and the packet loss rate satisfies the first packet loss rate threshold. The one or more processors are also configured to receive a second packet encoded based on a second codec configuration from the second device via the network.

[0009] In another specific aspect, a non-transitory computer-readable medium includes instructions that, when executed by one or more processors of a device, cause the one or more processors to perform operations for communication. The operations include: receiving configuration data from a configuration server at a first device. The configuration data indicates a first packet loss rate threshold associated with a first codec configuration. The operations include: determining a packet loss rate at the first device. The packet loss rate is associated with one or more first packets received at the first device from a second device via a network. The operations include: sending a request to the second device to change the codec configuration of the second device based on determining that the decoder of the first device has the first codec configuration and the packet loss rate satisfies the first packet loss rate threshold. The operations also include: receiving a second packet from the second device via the network at the first device. The second packet is encoded based on the second codec configuration.

[0010] In another specific aspect, an apparatus includes: a unit for receiving configuration data from a configuration server at a first device. The configuration data indicates a first packet loss rate threshold associated with a first codec configuration. The apparatus includes: a unit for determining a packet loss rate at the first device. The packet loss rate is associated with one or more first packets received at the first device from a second device via a network. The apparatus includes: a unit for sending a request to the second device for changing the codec configuration of the second device. The request is sent based on determining that a decoder of the first device has the first codec configuration and the packet loss rate satisfies the first packet loss rate threshold. The apparatus also includes: a unit for receiving a second packet from the second device via the network at the first device. The second packet is encoded based on the second codec configuration.

[0011] Other aspects, advantages, and features of the present disclosure will become apparent after reading the entire application, including the following sections: Brief Description of the Drawings, Detailed Description, and Claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a block diagram of certain illustrative aspects of a system operable to adapt a codec configuration based on a packet loss rate;

[0013] Figure 2 Is Figure 1 A table of examples of descriptions and formats of configuration data generated by the system;

[0014] Figure 3 It can be done by Figure 1 a diagram of an illustrative example of configuration data generated by a system;

[0015] Figure 4 It can be done by Figure 1 FIGURES of illustrative examples of codec configuration adaptation performed by a system of FIG.

[0016] Figure 5 is a flow chart illustrating a particular method of codec configuration adaptation based on packet loss rate;

[0017] Figure 6 is a diagram of another example of a system operable to adapt a codec configuration based on a packet loss rate;

[0018] Figure 7 Is Figure 6 A table of examples of descriptions and formats of configuration data generated by the system;

[0019] Figure 8is a block diagram of a specific illustrative example of a device operable to perform codec configuration adaptation based on packet loss rate; and

[0020] Fig. 9 is a block diagram of a base station operable to perform codec configuration adaptation based on a packet loss rate. DETAILED DESCRIPTION

[0021] Audio data transmitted from a transmitting device to a receiving device may be affected based on the packet loss rate associated with the transmission of the data. For example, audio data may be transmitted as a packet stream over a wireless network. When packets are lost at a high enough rate, it may result in a perceptible loss in audio quality, thereby impairing the user experience.

[0022] The impact of packet loss can be at least partially mitigated by adjusting the codec mode associated with encoding audio data at the transmitting device and decoding audio data at the receiving device. For example, some codec modes may include a coding technique that provides a lower "robustness" to packet loss (e.g., a relatively small packet loss rate can be tolerated), while other codec modes may include another coding technique that provides a higher robustness to packet loss (e.g., a relatively large packet loss rate can be tolerated). Therefore, when the packet loss rate becomes too high for a specific codec mode, each of the transmitting device and the receiving device can adjust its respective codec to operate in a more robust mode. Similarly, when the packet loss rate is low enough, the codec at the transmitting device and the receiving device can be adjusted to operate in a more unrobust codec mode, and the more unrobust codec mode can use less bandwidth, consume less power, achieve higher audio quality (e.g., bandwidth for data redundancy can be reallocated to provide enhanced audio information), or a combination thereof.

[0023] However, if the sending device and the receiving device fail to adjust the codec configuration in sync with each other, transmission errors may result. In one illustrative example, if the sending device and the receiving device are from different manufacturers and have different settings regarding what an acceptable packet loss rate is for a particular codec configuration, the devices may not be able to efficiently negotiate when to switch from a first codec configuration to a second, more robust codec configuration. As another example, the devices may not be able to efficiently negotiate which codec configuration to use as the second, more robust codec configuration.

[0024] According to various implementations disclosed herein, a transmitting device and a receiving device receive codec configuration data from a third device, such as a configuration server of an operator of a network. The codec configuration data indicates a plurality of allowable codec configurations and a packet loss rate threshold associated with each of the codec configurations. The transmitting device and the receiving device can access the codec configuration data to determine when to adjust the codec mode based on comparing a determined packet loss rate with the packet loss rate threshold in the configuration data, and select the next codec configuration mode to be used. Therefore, the transmitting device and the receiving device can more efficiently adapt to changing network conditions to provide enhanced audio transmission compared to the following systems: In these systems, inefficient or invalid negotiations about changing codec configurations result in continued use of codec configurations that are no longer suitable for changing network conditions.

[0025] The following describes specific aspects of the present disclosure with reference to the accompanying drawings. In this description, common features are specified by common reference numerals. As used herein, various terms are only used for the purpose of describing a specific implementation, and are not intended to limit the implementation. For example, the singular "a", "an" and "the" are also intended to include plural forms, unless the context clearly indicates otherwise. It can also be understood that the term "comprise, comprises and comprising" can be used interchangeably with "include, includes or including". In addition, it will be understood that the term "wherein" can be used interchangeably with "wherein". As used herein, "exemplary" can indicate examples, implementations and / or aspects, and should not be interpreted as limiting or indicating a preferred or preferred implementation. As used herein, ordinal numbers (e.g., "first", "second", "third", etc.) used to modify elements such as structures, components, operations, etc. do not indicate any priority or order of the element relative to another element, but only distinguish the element from another element with the same name (if no ordinal number is used). As used herein, the term "set" refers to one or more of a particular element, and the term "plurality" refers to a plurality (eg, two or more) of the particular element.

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

[0027] In the present disclosure, terms such as "determine," "calculate," "estimate," "shift," "adjust," and the like may be used to describe how to perform one or more operations. It should be noted that such terms should not be construed as limiting, and other techniques may be utilized to perform similar operations. Additionally, as referenced herein, "generate," "calculate," "estimate," "use," "select," "access," and "determine" may be used interchangeably. For example, "generating," "calculating," "estimating," or "determining" a parameter (or signal) may refer to actively generating, estimating, calculating, or determining a parameter (or signal), or may refer to using, selecting, or accessing a parameter (or signal) that has already been generated, for example, by another component or device.

[0028] refer to Figure 1 , certain illustrative aspects of a system are disclosed and generally designated as 100. System 100 includes a configuration server 142 that is communicatively coupled to one or more devices (such as device 102 and device 122) via a network 150. In certain aspects, device 102 (or device 122) may enter, exit, or move within the coverage area of ​​network 150 at different times. Network 150 includes a wired network, a wireless network, or both. Configuration server 142 is configured to send configuration data 107 to device 102, device 122, or both to facilitate codec configuration changes at device 102 and device 122.

[0029] Device 102 includes codec 140, codec configuration adaptation circuit 137, memory 105, receiver 106, transmitter 108, or a combination thereof. Codec 140 includes encoder 114, decoder (not shown), or both. Encoder 114 is configured to generate encoded packets based on codec configuration 116. Transmitter 108 is configured to send encoded packets to device 122 via network 150. Receiver 106 is configured to receive request 192 from device 122 via network 150. As described herein, codec configuration adaptation circuit 137 is configured to update codec configuration 116 based on configuration data 107 in response to receiving request 192. Memory 105 is configured to store configuration data 107.

[0030] Device 122 includes codec 130, codec configuration adaptation circuit 139, memory 125, receiver 126, transmitter 128, or a combination thereof. Codec 130 includes an encoder (not shown), a decoder 134, or both. Receiver 126 is configured to receive encoded packets from device 102 via network 150. Decoder 134 is configured to generate decoded packets by decoding the encoded packets based on codec configuration 136. As described herein, codec configuration adaptation circuit 137 is configured to determine a packet loss rate (PLR) 129. Codec configuration adaptation circuit 137 is configured to generate a request 192 for changing the codec configuration based on PLR 129 and configuration data 107. Transmitter 128 is configured to send request 192 to device 102 via network 150. Memory 105 is configured to store configuration data 107, PLR 129, or both.

[0031] During operation, configuration server 142 generates configuration data 107. In certain aspects, configuration data 107 is based on default data, user input, configuration settings or a combination thereof. Configuration data 107 includes PLR average window duration 162, codec configuration list 164, high PLR threshold list 166, low PLR threshold list 168, high PLR adaptation request type list 172, low PLR adaptation request type list 174 or a combination thereof. Configuration data 107 including lists is provided as an illustrative example. In other examples, configuration data 107 includes other data structures such as sets, tables, arrays or a combination thereof. In certain aspects, configuration data 107 includes one or more open mobile alliance (OMA) device management (DM) standardized objects to specify one or more of the following: PLR average window duration 162, codec configuration list 164, high PLR threshold list 166, low PLR threshold list 168, high PLR adaptation request type list 172 or low PLR adaptation request type list 174. exist Figure 2-4Descriptions, formats, and examples of elements of configuration data 107 are provided in .

[0032] exist Figure 2 , table 200 includes a description column 202 and a format column 204. Description column 202 includes an example of a description of an element of configuration data 107. Format column 204 includes an example of a format of an element of configuration data 107. For example, PLR averaging window duration 162 indicates the duration of a sliding averaging window within which the PLR ​​is to be measured. In a particular aspect, configuration data 107 indicates PLR averaging window duration 162 in milliseconds. Figure 3 , codec configuration list 164 includes codec configurations 302-312, high PLR threshold list 166 includes high PLR thresholds 324-332, low PLR threshold list 168 includes low PLR thresholds 342-350, high PLR adaptation request type list 172 includes high PLR adaptation request types 364-372, and low PLR adaptation request type list 174 includes low PLR adaptation request types 382-390.

[0033] The codec configuration list 164 includes an ordered sequence (e.g., an ordered list) of codec configurations. In certain aspects, the ordered list includes codec configurations supported for a specific media type (e.g., audio or video). In certain aspects, the codec configuration includes the type of codec, the codec mode, the application layer redundancy level (e.g., 0% to 300%), or a combination thereof. In a specific example, the codec configuration includes one or more of the following: an adaptive multi-rate wideband (AMR-WB) codec configuration, an AMR-WB / G.718 interoperable (IO) codec configuration, an enhanced voice service (EVS) AMR-WB IO codec configuration, an EVS wideband (WB), ultra-wideband (SWB) codec configuration, or an EVS WB, SWB channel-aware codec configuration.

[0034] In certain aspects, the codec configuration list 164 is sorted based on the robustness of the codec configuration to packet loss. For example, the EVS WB, SWB channel-aware codec configuration, the EVS WB, SWB codec configuration, the EVSAMR-WB IO codec configuration, and the AMR-WB codec configuration have a first ordinal position, a second ordinal position, a third ordinal position, and a fourth ordinal position, respectively, in the codec configuration list 164. In certain aspects, the codec configuration list 164 is sorted based on decreasing robustness, increasing quality, decreasing power consumption, decreasing bandwidth usage, or a combination thereof. For example, the first ordinal position (e.g., 0) of the EVS-WB, SWB channel-aware codec configuration is lower (e.g., less than) the second ordinal position (e.g., 1) of the EVS-WB, SWB codec configuration, indicating that the EVS-WB, SWB channel-aware codec configuration is more robust to packet loss than the EVS-WB, SWB (e.g., non-channel-aware) codec configuration. For example, the EVS WB, SWB channel-aware codec configuration is associated with a first maximum supported end-to-end PLR (e.g., 9%), which is higher than a second maximum supported end-to-end PLR (e.g., 6%) associated with the EVS WB, SWB codec configuration. In certain aspects, the EVS WB, SWB (e.g., non-channel-aware) codec configuration corresponds to higher media quality, lower bandwidth consumption, lower power consumption, or a combination thereof, compared to the EVS WB, SWB channel-aware codec configuration.

[0035] The high PLR threshold list 166 indicates first PLR thresholds associated with the codec configurations included in the codec configuration list 164. In a particular example, the first PLR thresholds indicate PLR ​​values ​​at or above which a codec configuration of higher robustness (or lower ordinal position) is requested. In a particular aspect, each codec configuration (except the codec configuration in the first ordinal position) is associated with a first PLR threshold in the high PLR threshold list 166. For example (e.g., Figure 3 ), the high PLR threshold list 166 includes the high PLR thresholds 324 associated with the codec configuration 304 in the codec configuration list 164. The high PLR threshold list 166 does not include any high PLR thresholds associated with the codec configuration 302 that has the first order position in the codec configuration list 164 (e.g., is the most robust supported codec configuration).

[0036] The high PLR adaptation request type list 172 indicates high PLR adaptation request types associated with high PLR thresholds included in the high PLR threshold list 166. In a specific example, the high PLR adaptation request type indicates a type of request to be sent when the corresponding high PLR threshold is met. For example, the high PLR adaptation request type list 172 includes a high PLR adaptation request type 364 associated with the high PLR threshold 324, and the high PLR adaptation request type 364 indicates that a request of the high PLR adaptation request type 364 will be sent in response to determining that the PLR ​​meets the high PLR threshold 324. In a specific example, the codec configuration 302 includes an EVS WB, SWB channel-aware codec configuration, the codec configuration 304 includes an EVS WB, SWB codec configuration, and the high PLR adaptation request type 364 is associated with the high PLR threshold 324 of the EVS WB, SWB codec configuration (e.g., the codec configuration 304). In this example, the high PLR adaptation request type 364 indicates a change to the EVS WB, SWB channel-aware codec configuration request type. In another example, the high PLR adaptation request type 364 indicates a change to a specific application layer redundancy level (e.g., 200%) or a specific change to the application layer redundancy level (e.g., increase by 50%).

[0037] The low PLR threshold list 168 indicates a second PLR threshold associated with the codec configurations included in the codec configuration list 164. In a specific example, the second PLR threshold indicates the following PLR values: at or below these PLR ​​values, a codec configuration of lower robustness (or higher order position) will be requested. In a specific aspect, a codec with lower robustness can support higher media quality, lower bandwidth consumption, lower power consumption, or a combination thereof. In a specific aspect, each codec configuration (except the codec configuration in the highest order position) is associated with a second PLR threshold in the low PLR threshold list 168. For example, the low PLR threshold list 168 includes a low PLR threshold 342 associated with the codec configuration 302 in the codec configuration list 164. The low PLR threshold list 168 does not include any low PLR threshold associated with the codec configuration 312, which has the last order position (e.g., the least robust supported codec configuration) in the codec configuration list 164.

[0038] The low PLR adaptation request type list 174 indicates the low PLR adaptation request types associated with the low PLR thresholds included in the low PLR threshold list 168. In a specific example, the low PLR adaptation request type indicates the type of request to be sent when the corresponding low PLR threshold is met. For example, the low PLR adaptation request type list 174 includes a low PLR adaptation request type 382 associated with the low PLR threshold 342, and the low PLR adaptation request type 382 indicates that a request of the low PLR adaptation request type 382 will be sent in response to determining that the PLR ​​meets the low PLR threshold 342.

[0039] exist Figure 4 , a graph 400 has a horizontal axis (e.g., x-axis) corresponding to increasing PLR values ​​and a vertical axis (e.g., y-axis) corresponding to increasing robustness (or decreasing ordinal position) of codec configurations. Graph 400 shows examples of PLR thresholds corresponding to various codec configurations. Figure 4 In one implementation, a low PLR threshold (e.g., low PLR threshold 342) of a codec configuration (e.g., codec configuration 302) is lower than a high PLR threshold (e.g., high PLR threshold 324) of a next less robust codec configuration (e.g., codec configuration 304). Having a low PLR threshold for a codec configuration lower than a high PLR threshold for the next less robust codec configuration reduces the likelihood of oscillations between the codec configuration and the next codec configuration for small fluctuations in the PLR ​​129. In another implementation, the low PLR threshold for a codec configuration is the same as the high PLR threshold for the next less robust codec configuration.

[0040] Back to Figure 1 , configuration server 142 sends configuration data 107 to device 102, device 122, or both. For example, configuration server 142 sends configuration data 107 to device 122 in response to detecting that device 122 has entered the coverage area of ​​network 150. In another example, configuration server 142 sends configuration data 107 to device 122 in response to receiving a request from device 122.

[0041] In certain aspects, device 122 establishes a session (e.g., a data communication session) with device 102. For example, device 102 and device 122 exchange negotiation messages indicating codecs supported at each device. By way of example, device 102 sends a first negotiation message to device 122, and device 122 sends a second negotiation message. The first negotiation message indicates one or more first codec configurations supported by codec 140 of device 102. The second negotiation message indicates one or more second codec configurations supported by codec 130 of device 122. Device 102 and device 122 may use various negotiation techniques to select a first codec configuration supported by each of codecs 130 and 140. Codec configuration adaptation circuit 137 sets codec configuration 116 of encoder 114 to a first codec configuration. Codec configuration adaptation circuit 139 sets codec configuration 136 of decoder 134 to a first codec configuration.

[0042] During the session, the receiver 126 receives one or more packets 152 from the device 102 via the network 150. In a particular example, the encoder 114 encodes the packets 152 based on a first codec configuration indicated by the codec configuration 116. The transmitter 108 sends the packets 152 to the device 122 via the network 150. In a particular aspect, the packets 152 received by the receiver 126 are a subset of the packets sent by the transmitter 108. For example, due to a network problem, one or more of the sent packets were not received.

[0043] The codec configuration adaptation circuit 139 determines a PLR 129 associated with a specific duration. The PLR ​​129 is an indication of how many packets sent by the device 102 were not received as packets 152 at the device 122 in time for use by the device 122. In a specific implementation, the PLR ​​129 is determined based on a lost packet (LP) counter. For example, a count of lost packets within a specific duration indicated by the LP counter can be used to calculate the PLR ​​129. The LP counter can be reset from time to time. Alternatively, the LP counter can maintain a count of lost packets associated with a sliding window of a specific duration. The specific duration is indicated by the PLR ​​average window duration 162. When a lost packet is detected, the codec configuration adaptation circuit 139 increments the LP counter. For example, when the specific packet is not available for playback (e.g., not in the de-jitter buffer) when the time to play the specific packet is reached, a lost packet can be detected.

[0044] The codec configuration adaptation circuit 139 determines that the configuration data 107 indicates that the first codec configuration (e.g., codec configuration 306 indicated by codec configuration 136) is associated with a high PLR threshold (e.g., high PLR threshold 326), a low PLR threshold (e.g., low PLR threshold 346), or both.

[0045] The codec configuration adaptation circuit 139, in response to determining that the PLR ​​129 satisfies (e.g., is greater than) the high PLR threshold, identifies a next more robust supported codec configuration in the codec configuration list 164. The next more robust supported codec configuration has a lower ordinal position (e.g., second) than an ordinal position (e.g., third) of the first codec configuration (e.g., codec configuration 306) in the codec configuration list 164, is included in the first codec configuration supported by the codec 140, is included in the second codec configuration supported by the codec 130, is either not associated with any high PLR threshold or is associated with a high PLR threshold greater than or equal to the PLR ​​129, or a combination thereof. In a particular aspect, the first codec configuration includes the codec configuration 306, and the next more robust supported codec configuration includes the codec configuration 304. In a particular example, codec configuration 304 is skipped because codec 130 does not support codec configuration 304, codec 140 does not support codec configuration 304, PLR 129 is greater than high PLR threshold 324 associated with codec configuration 304, or a combination thereof. In this example, the next more robust supported codec configuration includes codec configuration 302.

[0046] The codec configuration adaptation circuit 139 generates the request 192 in response to determining that the PLR ​​129 satisfies (e.g., is greater than) a high PLR threshold (e.g., the high PLR threshold 326) associated with the first codec configuration (e.g., the codec configuration 306) and identifying a next more robust supported codec configuration. Alternatively, the codec configuration adaptation circuit 139 refrains from generating the request 192 in response to determining that the PLR ​​129 satisfies (e.g., is greater than) a high PLR threshold (e.g., the high PLR threshold 326) associated with the first codec configuration (e.g., the codec configuration 306) and the codec configuration list 164 does not include the next more robust supported codec configuration.

[0047] In certain aspects, the type of request 192 indicates that the codec configuration is to be changed to a more robust (e.g., or lower ordinal position) codec configuration. In certain aspects, the request 192 indicates the identified next more robust supported codec configuration (e.g., codec configuration 302 or codec configuration 304). In certain aspects, the request 192 includes the PLR ​​129 to enable the codec configuration adaptation circuitry 137 to identify the next more robust supported codec configuration (e.g., codec configuration 302 or codec configuration 304) based on the configuration data 107.

[0048] In certain aspects, the type of the request 192 is based on the high PLR adaptation request type list 172. For example, the codec configuration adaptation circuit 139 generates the request 192 of the first high PLR adaptation request type in response to determining that the high PLR adaptation request type list 172 indicates that the first codec configuration (e.g., the codec configuration 306) is associated with a first high PLR adaptation request type (e.g., the high PLR adaptation request type 366). The codec configuration adaptation circuit 139 initiates transmission of the request 192 to the device 102 via the transmitter 128 and the network 150.

[0049] In certain aspects, the codec configuration adaptation circuit 139, in response to determining that the PLR ​​129 satisfies (e.g., is less than) the low PLR threshold, identifies a next less robust supported codec configuration in the codec configuration list 164. The next less robust supported codec configuration has an ordinal position (e.g., fourth) higher than (e.g., greater than) the ordinal position (e.g., third) of the first codec configuration (e.g., codec configuration 306) in the codec configuration list 164, is included in the first codec configuration supported by the codec 140, is included in the second codec configuration supported by the codec 130, is either not associated with any low PLR threshold or is associated with a low PLR threshold less than or equal to the PLR ​​129, or a combination thereof. In certain aspects, the first codec configuration includes the codec configuration 306, and the next less robust supported codec configuration includes the codec configuration 308. In a particular example, codec configuration 308 is skipped because codec 130 does not support codec configuration 308, codec 140 does not support codec configuration 308, PLR 129 is less than low PLR threshold 348 associated with codec configuration 308, or a combination thereof. In this example, the next less robust supported codec configuration includes codec configuration 310.

[0050] The codec configuration adaptation circuit 139 generates the request 192 in response to determining that the PLR ​​129 satisfies (e.g., is less than) a low PLR threshold (e.g., the low PLR threshold 346) associated with the first codec configuration (e.g., the codec configuration 306) and identifying the next less robust supported codec configuration. Alternatively, the codec configuration adaptation circuit 139 refrains from generating the request 192 in response to determining that the PLR ​​129 satisfies (e.g., is less than) a low PLR threshold (e.g., the low PLR threshold 346) associated with the first codec configuration (e.g., the codec configuration 306) and the codec configuration list 164 does not include the next less robust supported codec configuration.

[0051] In certain aspects, the type of request 192 indicates that the codec configuration is to be changed to a less robust (or higher order position) codec configuration. In certain aspects, the request 192 indicates the identified next less robust supported codec configuration (e.g., codec configuration 308 or codec configuration 310). In certain aspects, the request 192 includes the PLR ​​129 to enable the codec configuration adaptation circuitry 137 to identify the next less robust supported codec configuration (e.g., codec configuration 308 or codec configuration 310) based on the configuration data 107.

[0052] In certain aspects, the type of the request 192 is based on the low PLR adaptation request type list 174. For example, the codec configuration adaptation circuit 139 generates the request 192 of a first low PLR adaptation request type in response to determining that the low PLR adaptation request type list 174 indicates that the first codec configuration (e.g., the codec configuration 306) is associated with a first low PLR adaptation request type (e.g., the low PLR adaptation request type 386). The codec configuration adaptation circuit 139 initiates transmission of the request 192 to the device 102 via the transmitter 128 and the network 150.

[0053] At the device 102 that receives the request 192, in response to determining that the type of the request 192 indicates that the codec configuration is to be changed to a more robust (or lower ordinal position) codec configuration and identifying a next more robust supported codec configuration, the codec configuration adaptation circuitry 137 sets the codec configuration 116 of the encoder 114 to the identified next more robust supported codec configuration. Alternatively, the codec configuration adaptation circuitry 137 refrains from updating the codec configuration 116 in response to determining that the type of the request 192 indicates that the codec configuration is to be changed to a more robust (or lower ordinal position) codec configuration and that the codec configuration list 164 does not include any next more robust supported codec configuration relative to the first codec configuration (e.g., indicated by the codec configuration 116).

[0054] For example, the receiver 106 receives the request 192 from the device 122 via the network 150. The codec configuration adaptation circuit 137 updates the codec configuration 116 of the encoder 114 in response to receiving the request 192. In an example where the PLR ​​129 is too high, the codec configuration adaptation circuit 137 identifies the next more robust supported codec configuration in the codec configuration list 164 relative to the first codec configuration (indicated by the codec configuration 116) in response to determining that the type of request 192 indicates that the codec configuration is to be changed to a more robust (or lower sequence position) codec configuration. The next more robust supported codec configuration has a lower order position (e.g., third) than the ordinal position of the first codec configuration (e.g., codec configuration 306) in codec configuration list 164, is included in the first codec configuration supported by codec 140, is included in the second codec configuration supported by codec 130, is either not associated with any high PLR threshold or is associated with a high PLR threshold greater than or equal to PLR 129, or a combination thereof. In a particular aspect, request 192 does not indicate PLR ​​129. In this regard, the next more robust supported codec configuration has a lower order position (e.g., third) than the ordinal position of the first codec configuration (e.g., codec configuration 306) in codec configuration list 164, is included in the first codec configuration supported by codec 140, is included in the second codec configuration supported by codec 130, or a combination thereof.

[0055] In another example, at the device 102, in response to determining that the type of the request 192 indicates that the codec configuration is to be changed to a less robust (or higher order position) codec configuration and identifying a next less robust supported codec configuration, the codec configuration adaptation circuit 137 sets the codec configuration 116 of the encoder 114 to the identified next less robust supported codec configuration. Alternatively, the codec configuration adaptation circuit 137 avoids updating the codec configuration 116 in response to determining that the type of the request 192 indicates that the codec configuration is to be changed to a less robust (or higher order position) codec configuration and the codec configuration list 164 does not include any next less robust supported codec configuration relative to the first codec configuration (e.g., indicated by the codec configuration 116).

[0056] For example, when PLR 129 is low, the codec configuration adaptation circuit 137 identifies a next less robust supported codec configuration relative to the first codec configuration (indicated by codec configuration 116) in the codec configuration list 164 in response to determining that the type of request 192 indicates that the codec configuration is to be changed to a less robust (or higher order position) codec configuration. The next less robust supported codec configuration has a higher order position (e.g., third) than the order position of the first codec configuration (e.g., codec configuration 306) in the codec configuration list 164, is included in the first codec configuration supported by the codec 140, is included in the second codec configuration supported by the codec 130, is either not associated with any low PLR threshold or is associated with a low PLR threshold less than or equal to PLR 129, or a combination thereof. In a particular aspect, the request 192 does not indicate PLR ​​129. In this regard, the next less robust supported codec configuration has a higher ordinal position (e.g., third) in the codec configuration list 164 than the ordinal position of the first codec configuration (e.g., codec configuration 306), is included in the first codec configuration supported by the codec 140, is included in the second codec configuration supported by the codec 130, or a combination thereof.

[0057] In other implementations, the request 192 may indicate a specific codec configuration. In such implementations, the codec configuration adaptation circuit 137 sets the codec configuration 116 to the specific codec configuration in response to determining that the specific codec configuration is included in the first codec configuration supported by the codec 140.

[0058] After sending the request 192, the receiver 126 at the device 122 receives one or more packets 154 from the device 102 via the network 150. The packets 154 are encoded based on a second codec configuration (e.g., a next more robust supported codec configuration, a next less robust supported codec configuration, or a specific codec configuration). For example, the encoder 114 encodes the one or more second packets based on the second codec configuration indicated by the codec configuration 116. The encoder 114 initiates transmission of the one or more second packets via the transmitter 108. The packets 154 received by the receiver 126 are a subset of the second packets sent by the transmitter 108 (e.g., one or more of the second packets may be lost during transmission to the device 122).

[0059] Thus, system 100 enables codec configuration 116 of device 102 to adapt based on PLR 129 experienced by device 122. For example, when device 122 is experiencing a high PLR (e.g., above a threshold PLR), device 102 and device 122 may move to a more robust codec configuration. Alternatively, when device 122 is experiencing a low PLR (e.g., below a threshold PLR), device 102 and device 122 may move to a codec configuration with higher media quality, lower bandwidth consumption, lower power consumption, or a combination thereof.

[0060] refer to Figure 5 , a method for codec configuration adaptation based on packet loss is shown and generally designated as 500. In certain aspects, one or more operations of method 500 are performed by Figure 1 The method may be performed by the receiver 126, the transmitter 128, the codec configuration adaptation circuit 139, the device 122, the receiver 106, the transmitter 108, the codec configuration adaptation circuit 137, the device 102, the system 100, or a combination thereof.

[0061] Method 500 includes: at 502, receiving configuration data from a configuration server at a first device. Figure 1 As described, Figure 1 The receiver 126 receives the configuration data 107 from the configuration server 142. In certain aspects, as shown in FIG. Figure 3 As depicted, configuration data 107 indicates high PLR threshold 326 and low PLR threshold 346 associated with codec configuration 306 .

[0062] The method 500 also includes, at 504, determining a packet loss rate at the first device. Figure 1 As described, Figure 1 The codec configuration adaptation circuit 139 determines the PLR ​​129. The PLR ​​129 is associated with one or more packets 152 received at the device 122 from the device 102 via the network 150.

[0063] The method 500 also includes, at 506, sending a request to the second device for changing the codec configuration of the second device based on determining that the decoder of the first device has the first codec configuration and the packet loss rate satisfies the first packet loss rate threshold. Figure 1 As described, Figure 1 The codec configuration adaptation circuit 139 sends a request 192 to the device 102 to change the codec configuration of the device 102 based on determining that the decoder 134 has the first codec configuration (indicated by the codec configuration 136).

[0064] The method 500 also includes, at 508, receiving, at the first device, a second packet from the second device via the network. For example, the receiver 126 receives one or more packets 154 from the device 102 via the network 150. Figure 1 As depicted, packet 154 is encoded based on a second codec configuration (eg, the updated codec configuration indicated by codec configuration 116).

[0065] Thus, method 500 enables codec configuration 116 of device 102 to adapt based on PLR 129 experienced by device 122. For example, when device 122 is experiencing a high PLR (e.g., above a threshold PLR), device 102 and device 122 may move to a more robust codec configuration. Alternatively, when device 122 is experiencing a low PLR (e.g., below a threshold PLR), device 102 and device 122 may move to a codec configuration that is less robust but provides other advantages, such as higher media quality, lower bandwidth usage, or power savings.

[0066] Figure 1 The components of are provided as examples. In other implementations, the system 100 may include Figure 1 . In some examples, one or more of the PLR ​​averaging window duration 162, the high PLR adaptation request type list 172, or the low PLR adaptation request type list 174 are omitted from the configuration data 107. In some examples, the information of the codec configuration list 164, the high PLR threshold list 166, and the low PLR threshold list 168 can be combined, for example, each entry of the codec configuration list 164 can also indicate the high PLR threshold, the low PLR threshold, or both for the entry. Although the codec configuration list 164 is shown as including six codec configurations, in other implementations, the codec configuration list 164 has less than six codec configurations (e.g., as few as one or two codec configurations) or has more than six codec configurations (e.g., 7, 10, 50, or any other number of codec configurations).

[0067] refer to Figure 6 , a specific example of a system is disclosed and generally designated as 600. Figure 1 Compared to system 100, system 600 includes a de-jitter buffer 670 and a de-jitter buffer PLR indicator 672. For example, device 122 includes a de-jitter buffer 670, and configuration data 107 includes a de-jitter buffer PLR indicator 672. Figure 6In the example shown in , the configuration data 107 does not include the high PLR adaptation request type list 172 and the low PLR adaptation request type list 174. In some other examples, the configuration data 107 also includes a de-jitter buffer PLR indicator 672 in addition to the high PLR adaptation request type list 172, the low PLR adaptation request type list 174, or both. Figure 7 Descriptions, formats, and examples of elements of configuration data 107 are provided in .

[0068] exist Figure 7 In FIG. 7 , table 700 includes a description column 702 and a format column 704. Description column 702 and format column 704 are Figure 2 The description column 202 and the format column 204 of FIG. 60 are different in that a description and a format of a de-jitter buffer PLR indicator 672 are added, respectively. For example, a first value (e.g., 0) of the de-jitter buffer PLR indicator 672 indicates that a PLR estimate (e.g., PLR 129) for comparison with a threshold indicated in the high PLR threshold list 166 or the low PLR threshold list 168 will be measured before the de-jitter buffer. As another example, a second value (e.g., 1) of the de-jitter buffer PLR indicator 672 indicates that a PLR estimate (e.g., PLR 129) will be measured after the de-jitter buffer.

[0069] return Figure 6, the codec configuration adaptation circuit 139 is configured to determine the PLR ​​129 based on a count of pre-de-jitter buffer packet loss events in response to determining that the de-jitter buffer PLR indicator 672 has a first value (e.g., 0). In a particular aspect, the codec configuration adaptation circuit 139 detects a pre-de-jitter packet loss event in response to determining that an expected packet has not been received at the device 122 (e.g., the expected packet has not been received within an expected time). For example, the codec configuration adaptation circuit 139 determines that the packet 152 includes a first packet received at the receiver 126 at a first time. The codec configuration adaptation circuit 139 determines that a second packet is expected to be received at the receiver 126 after the first packet. For example, the first packet indicates a first sequence number, and a second packet having a second sequence number is expected to be received at the receiver 126. The codec configuration adaptation circuit 139 detects that the expected packet has not been received within the expected time in response to determining that the packet having the second sequence number has not been received at the receiver 126 within a threshold duration at the first time. The codec configuration adaptation circuit 139 increments a count of pre-de-jitter buffer packet loss events (e.g., indicated by the LP counter) in response to detecting that an expected packet has not been received within an expected time. The PLR ​​129 is based on the value of the LP counter. In a particular aspect, the PLR ​​129 is based on a comparison of a first count of packets 152 received at the device 122 and the value of the LP counter (e.g., PLR 129=LP counter value / (first count+LP counter value)).

[0070] In certain aspects, the codec configuration adaptation circuit 139 is configured to determine the PLR ​​129 based on the count of post-de-jitter buffer packet loss events in response to determining that the de-jitter buffer PLR indicator 672 has a second value (e.g., 1). In certain aspects, the codec configuration adaptation circuit 139 detects the post-de-jitter buffer packet loss event in response to determining that the particular packet is not available for playback (e.g., not in the de-jitter buffer 670) when the time for playing the particular packet is reached. The codec configuration adaptation circuit 139 updates the count of post-de-jitter buffer packet loss events (e.g., indicated by the LP counter) in response to detecting the post-de-jitter buffer packet loss event. The PLR ​​129 is based on the value of the LP counter. In certain aspects, the PLR ​​129 is based on a comparison of a first count of a subset of packets 152 available in the de-jitter buffer at the corresponding playback time and the value of the LP counter (e.g., PLR 129=LP counter value / (first count+LP counter value)).

[0071] In some aspects, compared with the pre-de-jitter buffer packet loss event, the first PLR based on the post-de-jitter buffer packet loss event is more representative of the user experience. For example, the post-de-jitter buffer packet loss event includes a packet received at the device 122 after the play time of the packet. The packet is not played (e.g., not added to the de-jitter buffer 670), and not playing the packet may have an adverse effect on the user experience (e.g., reduced audio / voice quality). Compared with the pre-de-jitter buffer packet loss event, the codec configuration adaptation based on the PLR ​​of the post-de-jitter buffer packet loss event can improve the user experience. The operator of the network can use the de-jitter buffer PLR indicator 672 so that various devices of the network use the same metric for codec configuration adaptation, and the user of the device has a similar user experience. For example, the first network operator can specify the first value (e.g., 0) of the de-jitter buffer PLR indicator 672 to use a more traditional estimate of the PLR ​​based on the pre-de-jitter buffer packet loss event (e.g., the count of the expected packet not received at the device). A second network operator can specify a second value (e.g., 1) of the de-jitter buffer PLR indicator 672 to use an estimate of the PLR ​​based on post-de-jitter buffer packet loss events (e.g., a count of packets unavailable for playback) to improve the user experience for users of devices in the network.

[0072] refer to Figure 8 , a block diagram of a particular illustrative example of a device (e.g., a wireless communication device) is depicted and generally designated as 800. In various aspects, the device 800 may have a plurality of Figure 8 In illustrative aspects, the device 800 may correspond to Figure 1 Device 102, device 122, configuration server 142, or a combination thereof. In illustrative aspects, device 800 may execute reference Figure 1-7 One or more operations of the systems and methods described.

[0073] In certain aspects, the device 800 includes a processor 806 (e.g., a central processing unit (CPU)). The device 800 may include one or more additional processors 810 (e.g., one or more digital signal processors (DSPs)). The processor 810 may include a decoder 818, an encoder 814, a codec configuration adaptation circuit 819, or a combination thereof. The encoder 814 may include Figure 1 The decoder 818 may include Figure 1 The codec configuration adaptation circuit 819 may include Figure 1 The codec configuration adaptation circuit 137, the codec configuration adaptation circuit 139 or both.

[0074] The device 800 may include a memory 852 and a codec 834. Although the encoder 814, the decoder 818, and the codec configuration adaptation circuit 819 are illustrated as components (e.g., dedicated circuits and / or executable programming code) of the processor 810, in other aspects, one or more of the encoder 814, the decoder 818, the codec configuration adaptation circuit 819, or a combination thereof, may be included in the processor 806, the codec 834, another processing component, or a combination thereof.

[0075] The device 800 may include a transceiver 850 coupled to an antenna 842. The transceiver 850 may include a receiver 807, a transmitter 808, or both. The receiver 807 may include Figure 1 The transmitter 808 may include the receiver 106, the receiver 126, or both. Figure 1 The processor 810 is coupled to the transceiver 850 via the wireless controller 840.

[0076] Device 800 may include a display 828 coupled to a display controller 826. One or more speakers 848 may be coupled to codec 834. One or more microphones 846 may be coupled to codec 834 via one or more input interfaces. Codec 834 may include a digital-to-analog converter (DAC) 802 and an analog-to-digital converter (ADC) 804.

[0077] Memory 852 may include instructions 856 executable by processor 806, processor 810, codec 834, another processing unit of device 800, or a combination thereof, to perform the reference Figure 1-7 One or more operations described. The memory 852 may store reference Figure 1-7 The one or more signals, one or more parameters, one or more thresholds, one or more indicators, or a combination thereof described herein. For example, the memory 852 is configured to store Figure 1 configuration data 107, PLR 129, or both.

[0078] One or more components of device 800 may be implemented via dedicated hardware (e.g., circuitry), by a processor executing instructions to perform one or more tasks, or a combination thereof. As an example, processor 806, processor 810, and / or one or more components of codec 834 or memory 852 may be a memory device (e.g., a computer-readable storage device) such as a random access memory (RAM), magnetoresistive random access memory (MRAM), spin torque transfer MRAM (STT-MRAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, a hard disk, a removable disk, or a compact disc read-only memory (CD-ROM). The memory device may include (e.g., store) instructions (e.g., instructions 856) that, when executed by a computer (e.g., one or more processors, such as a processor in codec 834, processor 806, and / or processor 810), may cause the computer to perform a reference to the present invention. Figure 1-7 As an example, one or more components of processor 806, processor 810, and / or codec 834 or memory 852 may be a non-transitory computer-readable medium including instructions (e.g., instructions 856) that, when executed by a computer (e.g., one or more processors, such as a processor in codec 834, processor 806, and / or processor 810), cause the computer to perform the operations described above. Figure 1-7 Describes one or more operations.

[0079] In certain aspects, the device 800 can be included in a system-in-package or system-on-chip device (e.g., a mobile station modem (MSM)) 822. In certain aspects, the processor 806, the processor 810, the display controller 826, the memory 852, the codec 834, and the transceiver 850 are included in the system-in-package or system-on-chip device 822. In certain aspects, an input device 830 such as a touch screen and / or a keypad and a power supply 844 are coupled to the system-on-chip device 822. In addition, in certain aspects, the system-in-package or system-on-chip device 822 may be configured to receive the input device 830, such as a touch screen and / or a keypad, and the power supply 844. Figure 8 As shown, the display 828, input device 830, speaker 848, microphone 846, antenna 842, and power supply 844 are located external to the system-on-chip device 822. However, each of the display 828, input device 830, speaker 848, microphone 846, antenna 842, and power supply 844 may be coupled to a component of the system-on-chip device 822, such as an interface or controller.

[0080] Device 800 may include a wireless telephone, a mobile communication device, a mobile device, a mobile phone, a smart phone, a cellular phone, a virtual reality headset, an augmented reality headset, a vehicle (e.g., a car), a laptop computer, a desktop computer, a computer, a tablet computer, a set-top box, a personal digital assistant (PDA), a display device, a television, a game console, a music player, a radio unit, a video player, an entertainment unit, a communication device, a fixed location data unit, a personal media player, a digital video player, a digital video disc (DVD) player, a tuner, a camera, a navigation device, a decoder system, an encoder system, or any combination thereof.

[0081] In certain aspects, reference Figure 1-7 One or more components of the described system and device 800 may be integrated into a decoding system or device (e.g., an electronic device, a codec, or a processor therein), an encoding system or device, or both. Figure 1-7 One or more components of the described system and device 800 may be integrated into a mobile device, a wireless telephone, a tablet computer, a desktop computer, a virtual reality headset, an augmented reality headset, a vehicle (e.g., an automobile), a laptop computer, a set-top box, a music player, a video player, an entertainment unit, a television, a game console, a navigation device, a communication device, a personal digital assistant (PDA), a fixed location data unit, a personal media player, or another type of device.

[0082] It should be noted that by reference Figure 1-7 Various functions performed by one or more components of the described system and device 800 are described as being performed by certain components or modules. This division of components and modules is for illustration only. In alternative aspects, the functions performed by a particular component or module may be divided among multiple components or modules. In addition, in alternative aspects, reference Figure 1-7 Two or more components or modules described may be integrated into a single component or module. Figure 1-7 Each component or module described may be implemented using hardware (e.g., a field programmable gate array (FPGA) device, an application specific integrated circuit (ASIC), a DSP, a controller, etc.), software (e.g., instructions executable by a processor), or any combination thereof.

[0083] In conjunction with the described aspects, an apparatus includes means for receiving configuration data from a configuration server at a first device. For example, the means for receiving configuration data may include Figure 1 Receiver 126, receiver 106, Figure 8The receiver 807, the transceiver 850, one or more structures, devices or circuits configured to receive configuration data from a configuration server at the first device, or a combination thereof. The configuration data indicates a first packet loss rate threshold associated with a first codec configuration.

[0084] The apparatus also includes a unit for determining a packet loss rate at the first device. For example, the unit for determining the packet loss rate may include Figure 1 Codec configuration adaptation circuit 137, codec configuration adaptation circuit 139, device 102, device 122, Figure 8 The processor 810, the codec configuration adaptation circuit 819, one or more structures, devices or circuits configured to determine a packet loss rate at the first device, or a combination thereof. The packet loss rate is associated with one or more first packets received at the first device from the second device via the network. For example, the packet loss rate is associated with a comparison of a count of first packets and a count of second packets expected and not received at the first device. As another example, the packet loss rate is associated with a count of a subset of first packets available in the de-jitter buffer at the corresponding playback time and a count of second packets that are not available in the de-jitter buffer at the corresponding playback time.

[0085] The apparatus also includes a unit for sending a request to the second device for changing the codec configuration of the second device. For example, the unit for sending the request may include Figure 1 Transmitter 108, transmitter 128, Figure 8 A transmitter 808, a transceiver 850, one or more structures, devices or circuits configured to send a request for changing the codec configuration to the second device based on determining that the decoder of the first device has the first codec configuration and the packet loss rate meets the first packet loss threshold, or a combination thereof. The request is sent based on determining that the decoder of the first device has the first codec configuration and the packet loss rate meets the first packet loss rate threshold.

[0086] The apparatus also includes a unit for receiving a second packet from a second device via a network at the first device. For example, the unit for receiving the second packet may include Figure 1 Receiver 126, receiver 106, Figure 8 The receiver 807, the transceiver 850, one or more structures, devices or circuits configured to receive the second packet from the second device via the network at the first device, or a combination thereof. The second packet is encoded based on the second codec configuration.

[0087] refer to Fig. 9 , depicts a block diagram of a specific illustrative example of a base station 900. In various implementations, the base station 900 may have a Fig. 9In the illustrative example, base station 900 may include more or fewer components as shown. Figure 1 In the illustrative example, the base station 900 may perform the reference Figure 1-7 One or more operations described.

[0088] Base station 900 may be part of a wireless communication system. A wireless communication system may include multiple base stations and multiple wireless devices. The wireless communication system may be a long term evolution (LTE) system, a code division multiple access (CDMA) system, a global system for mobile communications (GSM) system, a wireless local area network (WLAN) system, or some other wireless system. A CDMA system may implement Wideband CDMA (WCDMA), CDMA 1X, Evolution Data Optimized (EVDO), Time Division Synchronous CDMA (TD-SCDMA), or some other version of CDMA.

[0089] Wireless devices may also be referred to as user equipment (UE), mobile stations, terminals, access terminals, subscriber units, stations, etc. Wireless devices may include cellular phones, smart phones, tablet devices, wireless modems, personal digital assistants (PDAs), handheld devices, laptop computers, smart books, netbooks, tablet devices, cordless phones, wireless local loop (WLL) stations, Bluetooth devices, etc. Wireless devices may include or correspond to Figure 8 800 of the device.

[0090] Various functions may be performed by one or more components of the base station 900 (and / or in other components not shown), such as sending and receiving messages and data (e.g., audio data). In a specific example, the base station 900 includes a processor 906 (e.g., a CPU). In a specific aspect, the processor 906 includes a plurality of processors. The base station 900 may include a transcoder 910. The transcoder 910 may include an audio codec 908. For example, the transcoder 910 may include one or more components (e.g., circuits) configured to perform the operation of the audio codec 908. As another example, the transcoder 910 may be configured to execute one or more computer-readable instructions to perform the operation of the audio codec 908. Although the audio codec 908 is shown as a component of the transcoder 910, in other examples, one or more components of the audio codec 908 may be included in the processor 906, another processing component, or a combination thereof. For example, a decoder 938 (e.g., a vocoder decoder) may be included in a receiver data processor 964. As another example, the encoder 936 (eg, a vocoder encoder) may be included in the transmit data processor 982 .

[0091] Transcoder 910 can be used to transcode messages and data between two or more networks. Transcoder 910 can be configured to convert messages and audio data from a first format (e.g., digital format) to a second format. For example, decoder 938 can decode the encoded signal with a first format, and encoder 936 can encode the decoded signal into an encoded signal with a second format. Additionally or alternatively, transcoder 910 can be configured to perform data rate adaptation. For example, transcoder 910 can down-convert the data rate or up-convert the data rate without changing the format of the audio data. For example, transcoder 910 can down-convert a 64kbit / s signal to a 16kbit / s signal.

[0092] In certain aspects, the transcoder 910 is configured to perform codec configuration adaptation. For example, the transcoder 910 includes Figure 1 The audio codec 908 may include an encoder 936 and a decoder 938. The encoder 936 may include Figure 1 The decoder 938 may include Figure 1 Decoder 134.

[0093] The base station 900 may include a memory 932. The memory 932, such as a computer-readable storage device, may include instructions. The instructions may include one or more instructions executable by the processor 906, the transcoder 910, or a combination thereof to perform the reference Figure 1-7 In certain aspects, the memory 932 is configured to store Figure 1 Configuration data 107, PLR 129, or both. Base station 900 may include multiple transmitters and receivers (e.g., transceivers) coupled to an antenna array, such as a first transceiver 952 and a second transceiver 954. The antenna array may include a first antenna 942 and a second antenna 944. The antenna array may be configured to communicate with one or more wireless devices (such as Figure 8 The second antenna 944 may be configured to perform wireless communication with the wireless device 800. For example, the second antenna 944 may receive a data stream 914 (eg, a bit stream) from the wireless device. The data stream 914 may include a message, data (eg, encoded voice data), or a combination thereof.

[0094] The base station 900 may include a network connection 960, such as a backhaul connection. The network connection 960 may be configured to communicate with one or more base stations of a core network or a wireless communication network. For example, the base station 900 may receive a second data stream (e.g., a message or audio data) from the core network via the network connection 960. The base station 900 may process the second data stream to generate a message or audio data, and provide the message or audio data to one or more wireless devices via one or more antennas of an antenna array, or provide it to another base station via the network connection 960. In a specific implementation, as an illustrative, non-limiting example, the network connection 960 may be a wide area network (WAN) connection. In some implementations, the core network may include or correspond to a public switched telephone network (PSTN), a packet backbone network, or both.

[0095] Base station 900 may include a media gateway 970 coupled to network connection 960 and processor 906. Media gateway 970 may be configured to convert between media streams of different telecommunication technologies. For example, media gateway 970 may convert between different transport protocols, different encoding schemes, or both. For example, media gateway 970 may convert from PCM signals to real-time transport protocol (RTP) signals, as an illustrative, non-limiting example. Media gateway 970 may convert data between packet switching networks (e.g., voice over Internet protocol (VoIP) networks, IP multimedia subsystems (IMS), fourth generation (4G) wireless networks (such as LTE, WiMax, and UMB, etc.), circuit switching networks (e.g., PSTN), and hybrid networks (e.g., second generation (2G) wireless networks (such as GSM, GPRS, and EDGE), third generation (3G) wireless networks (such as WCDMA, EV-DO, and HSPA, etc.)).

[0096] In addition, the media gateway 970 may include a transcoder (such as transcoder 910) and may be configured to transcode data when the codec is incompatible. For example, as an illustrative, non-limiting example, the media gateway 970 may transcode between an adaptive multi-rate (AMR) codec and a G.711 codec. The media gateway 970 may include a router and a plurality of physical interfaces. In some implementations, the media gateway 970 may also include a controller (not shown). In a specific implementation, the media gateway controller may be outside the media gateway 970, outside the base station 900, or both. The media gateway controller may control and coordinate the operation of a plurality of media gateways. The media gateway 970 may receive a control signal from the media gateway controller and may be used to bridge between different transmission technologies and may add services to end-user capabilities and connections.

[0097] The base station 900 may include a demodulator 962 coupled to the transceivers 952, 954, a receiver data processor 964, and the processor 906, and the receiver data processor 964 may be coupled to the processor 906. The demodulator 962 may be configured to demodulate modulated signals received from the transceivers 952, 954 and provide demodulated data to the receiver data processor 964. The receiver data processor 964 may be configured to extract a message or audio data from the demodulated data and send the message or audio data to the processor 906.

[0098] The base station 900 may include a transmit data processor 982 and a transmit multiple input multiple output (MIMO) processor 984. The transmit data processor 982 may be coupled to the processor 906 and the transmit MIMO processor 984. The transmit MIMO processor 984 may be coupled to the transceivers 952, 954 and the processor 906. In some implementations, the transmit MIMO processor 984 may be coupled to the media gateway 970. The transmit data processor 982 may be configured to receive a message or audio data from the processor 906 and encode the message or audio data based on a coding scheme such as CDMA or orthogonal frequency division multiplexing (OFDM) (as illustrative, non-limiting examples). The transmit data processor 982 may provide the encoded data to the transmit MIMO processor 984.

[0099] The coded data may be multiplexed with other data (such as pilot data) using CDMA or OFDM techniques to generate multiplexed data. The multiplexed data may then be modulated (i.e., symbol mapped) by the transmit data processor 982 based on a specific modulation scheme (e.g., binary phase shift keying ("BPSK"), quadrature phase shift keying ("QSPK"), M-ary phase shift keying ("M-PSK"), M-ary quadrature amplitude modulation ("M-QAM"), etc.) to generate modulation symbols. In a specific implementation, the coded data and other data may be modulated using different modulation schemes. The data rate, coding, and modulation used for each data stream may be determined by instructions executed by the processor 906.

[0100] The transmit MIMO processor 984 may be configured to receive the modulation symbols from the transmit data processor 982 and may further process the modulation symbols and may perform beamforming on the data. For example, the transmit MIMO processor 984 may apply beamforming weights to the modulation symbols. The beamforming weights may correspond to one or more antennas of the antenna array from which the modulation symbol is being transmitted.

[0101] During operation, the second antenna 944 of the base station 900 can receive the data stream 914. The second transceiver 954 can receive the data stream 914 from the second antenna 944 and can provide the data stream 914 to the demodulator 962. The demodulator 962 can demodulate the modulated signal of the data stream 914 and provide the demodulated data to the receiver data processor 964. The receiver data processor 964 can extract audio data from the demodulated data and provide the extracted audio data to the processor 906.

[0102] Processor 906 can provide audio data to transcoder 910 for transcoding. Decoder 938 of transcoder 910 can decode audio data from a first format into decoded audio data, and encoder 936 can encode decoded audio data into a second format. In some implementations, encoder 936 can use a higher data rate (e.g., up conversion) or a lower data rate (e.g., down conversion) than received from a wireless device to encode audio data. In other implementations, audio data may not be transcoded. Although transcoding (e.g., decoding and encoding) is shown as being performed by transcoder 910, transcoding operations (e.g., decoding and encoding) can be performed by multiple components of base station 900. For example, decoding can be performed by receiver data processor 964, and encoding can be performed by send data processor 982. In other implementations, processor 906 can provide audio data to media gateway 970 for conversion to another transport protocol, coding scheme, or both. Media gateway 970 can provide converted data to another base station or core network via network connection 960.

[0103] In certain aspects, the transcoder 910 responds to receiving Figure 1 Request 192 to update the codec configuration of encoder 936. Encoder 936 can generate encoded audio data based on the updated codec configuration. The encoded audio data (e.g., transcoded data) generated at encoder 936 can be provided to transmit data processor 982 or network connection 960 via processor 906.

[0104] The transcoded audio data from the transcoder 910 may be provided to a transmit data processor 982 for encoding according to a modulation scheme such as OFDM to generate modulation symbols. The transmit data processor 982 may provide the modulation symbols to a transmit MIMO processor 984 for further processing and beamforming. The transmit MIMO processor 984 may apply beamforming weights and may provide the modulation symbols to one or more antennas of an antenna array, such as the first antenna 942, via the first transceiver 952. Thus, the base station 900 may provide a transcoded data stream 916 corresponding to a data stream 914 received from a wireless device to another wireless device. The transcoded data stream 916 may have a different coding format, data rate, or both than the data stream 914. In other implementations, the transcoded data stream 916 may be provided to a network connection 960 for transmission to another base station or a core network.

[0105] Thus, the base station 900 may include a computer-readable storage medium (e.g., memory 932) storing instructions that, when executed by one or more processors (e.g., processor 906, transcoder 910, or both), cause the processor to perform operations for communication. These operations include receiving configuration data from a configuration server. The configuration data indicates a first packet loss rate threshold associated with a first codec configuration. These operations include determining a packet loss rate associated with one or more first packets received from a second device via a network at the base station 900. These operations include: sending a request to the second device to change the codec configuration of the second device based on determining that the decoder of the base station 900 has a first codec configuration and the packet loss rate satisfies the first packet loss threshold. These operations also include: receiving a second packet from the second device via the network. The second packet is encoded based on the second codec configuration.

[0106] An example is provided that describes the details of the codec configuration. In a specific implementation, a global list based on media type is used. The global list arranges examples of codec configurations for media types in order of robustness. If a subset of codecs or configurations for a session is negotiated, the terminal adapts between the negotiated subsets that use the same robustness ordering from the global list. Each entry in the global list includes a codec name field (e.g., MIME type), a codec rate field (e.g., in bits / second), a redundancy field, or a combination thereof. The following fields may be used for each entry in the global list:

[0107]

[0108]

[0109] In a specific implementation, a list by codec type is used. The list by codec type arranges examples of codec configurations for a specific codec type in order of robustness. If a subset of codec configurations for a session is negotiated, the terminal adapts between the negotiated subsets using the same robustness order from the list by codec type. The following fields may be used for each entry in the list that is specific to a codec type.

[0110] For codec 1:

[0111]

[0112] For codec 2:

[0113]

[0114]

[0115] The previous description of the disclosed aspects is provided to enable those skilled in the art to implement or use the disclosed aspects. Various modifications to these aspects will be readily apparent to those skilled in the art, and the principles defined herein may be applied to other aspects without departing from the scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the aspects shown herein, but to be given the widest possible scope consistent with the principles and novel features defined by the appended claims.

Claims

1. A device comprising: One or more processors configured to: determining, at a first device, a packet loss rate associated with one or more first packets encoded by a decoder based on a first codec configuration and received at the first device from a second device; as well as Based on determining that the packet loss rate satisfies a first packet loss rate threshold and a second codec configuration is available for the first device, sending a request to the second device to receive packets based on the second codec configuration from the second device.

2. The device according to claim 1, further comprising: the decoder; as well as A receiver configured to receive configuration data, wherein the configuration data comprises an ordered list of codec configurations, and wherein, in the ordered list of codec configurations, the first codec configuration has a first ordinal position and the second codec configuration has a second ordinal position.

3. The device according to claim 1, wherein: The one or more processors are integrated into the mobile device.

4. The device according to claim 1, wherein: The one or more processors are integrated into the base station.

5. A method of communication, comprising: determining, at a first device, a packet loss rate associated with one or more first packets encoded based on a first codec configuration and received at the first device from a second device; as well as Based on determining that the packet loss rate satisfies a first packet loss rate threshold and a second codec configuration is available for the first device, sending a request to the second device to receive packets based on the second codec configuration from the second device.

6. The method according to claim 5, further comprising: The first packet loss rate threshold is obtained from configuration data, wherein the configuration data comprises an ordered list of codec configurations, and wherein, in the ordered list of codec configurations, the first codec configuration has a first ordinal position and the second codec configuration has a second ordinal position.

7. The method according to claim 6, wherein: The ordered list of codec configurations is ordered based on robustness of the codec configurations to packet losses.

8. The method according to claim 6, wherein: The configuration data comprises a list of first packet loss rate thresholds associated with the ordered list of codec configurations, and wherein a first high packet loss rate threshold of the first packet loss rate thresholds is associated with the first codec configuration.

9. The method according to claim 8, further comprising: In response to determining that the packet loss rate is greater than the first high packet loss rate threshold, it is determined that the packet loss rate satisfies the first packet loss rate threshold.

10. The method according to claim 9, wherein: The configuration data comprises a list of first request types associated with a list of the first packet loss rate thresholds, wherein a first request type of the first request types is associated with the first high packet loss rate threshold, and wherein the request is of the first request type.

11. The method according to claim 6, wherein: The configuration data comprises a list of second packet loss rate thresholds associated with the ordered list of codec configurations, and wherein a first low packet loss rate threshold of the second packet loss rate thresholds is associated with the first codec configuration.

12. The method according to claim 11, further comprising: In response to determining that the packet loss rate is less than the first low packet loss rate threshold, it is determined that the packet loss rate satisfies the first packet loss rate threshold.

13. The method according to claim 12, wherein: The configuration data comprises a list of second request types associated with a list of the second packet loss rate thresholds, wherein a second one of the second request types is associated with the first low packet loss rate threshold, and wherein the request is of the second request type.

14. The method according to claim 6, wherein: The configuration data indicates an ordered sequence of codec configurations, and further comprising: before sending the request to the second device: receiving, from the second device, a message indicating one or more codec configurations supported by the second device; and The request for indicating the second codec configuration is generated based on determining that the second codec configuration has a second ordinal position in the ordered sequence of the codec configurations that is greater than the first ordinal position of the first codec configuration, the one or more codec configurations supported by the second device include the second codec configuration, and the first device supports the second codec configuration.

15. The method according to claim 6, wherein: The configuration data comprises a packet loss rate averaging window duration, and wherein the packet loss rate is based on a sliding window of the packet loss rate averaging window duration.

16. The method according to claim 6, wherein: The configuration data includes a de-jitter buffer packet loss rate indicator, and wherein, in response to determining that the de-jitter buffer packet loss rate indicator has a first value, the packet loss rate is based on a count of pre-de-jitter buffer packet loss events.

17. The method according to claim 6, wherein: The configuration data includes a de-jitter buffer packet loss rate indicator, and wherein, in response to determining that the de-jitter buffer packet loss rate indicator has a second value, the packet loss rate is based on a count of post-de-jitter buffer packet loss events.

18. The method according to claim 5, wherein: The first codec configuration includes an adaptive multi-rate wideband (AMR-WB) codec configuration, an AMR-WB / G.718 interoperable (IO) codec configuration, an enhanced voice service (EVS) AMR-WB IO codec configuration, an EVS wideband (WB), super wideband (SWB) codec configuration, or an EVS WB, SWB channel-aware codec configuration.

19. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors of a device, cause the one or more processors to: determining a packet loss rate associated with one or more first packets encoded based on a first codec configuration and received at the device from a second device; and Based on determining that the packet loss rate satisfies a first packet loss rate threshold and a second codec configuration is available for the device, a request is sent to the second device to receive packets based on the second codec configuration from the second device.

20. The non-transitory computer readable medium of claim 19, wherein: The instructions, when executed by the one or more processors, cause the one or more processors to perform the following operations: in response to determining that a de-jitter buffer packet loss rate indicator has a specific value, determine the packet loss rate based on a count of pre-de-jitter buffer packet loss events.

21. An apparatus comprising: means for determining, at a first device, a packet loss rate associated with one or more first packets encoded by a decoder based on a first codec configuration and received at the first device from a second device; as well as Means for sending, to the second device, a request to receive packets based on a second codec configuration from the second device based on determining that the packet loss rate satisfies a first packet loss rate threshold and a second codec configuration is available for the first device.

22. The device according to claim 21, wherein In response to the de-jitter buffer packet loss rate indicator having a particular value, the packet loss rate is based on a count of post-de-jitter buffer packet loss events.

Images