Dynamic codec negotiation

A method, a device, and a non-transitory storage medium having instructions to store data that provides mappings between criteria information and lists of codecs; receive an indication that one of an audio session, a video session, or an audio and video session is to be initiated with another device; obtain one or more criteria metric values in response to a receipt of the indication; select one of the lists of codecs from the data based on one of the mappings and the one or more criteria metric values; transmit the one of the lists of codecs to the other device via a wireless network; receive a response, via the wireless network, from the other device, wherein the response indicates one of the codecs; and use the one of the codecs during the one of the audio session, the video session, or the audio and video session.

BACKGROUND

An enhanced voice services (EVS) codec has been finalized for voice services over Long Term Evolution (LTE) and other radio access technologies standardized by the 3rdGeneration Partnership Group (3GPP). The EVS codec includes various features such as a multi-rate audio codec and a channel-aware mode. Additionally, the EVS codec provides interoperation with the Adaptive Multi-Rate Wideband (AMR-WB) codec.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

According to one approach, a wireless device, such as a user equipment (UE), will negotiate codec settings with another UE via a wireless network (e.g., LTE). For example, the UE (e.g., a mobile originated (MO) device) transmits a Session Initiation Protocol (SIP) INVITE and a Session Description Protocol (SDP) offer to the other UE (e.g., a mobile terminated (MT) device). The SIP INVITE and SDP offer may include a list of preferred codecs settings. Typically, the list of preferred codec settings is a static list. That is, the list includes a pre-defined set of codecs that are the same regardless of wireless conditions (e.g., channel conditions, etc.), wireless network state (e.g., congestion level, etc.), etc. In response to receiving the SIP INVITE and SDP offer, the other UE has the option to select one codec from the list or end the negotiation when the other UE cannot support any of the codecs listed.

When the other UE selects one of the codecs from the list, the wireless network will honor the channel capacity pertaining to the negotiated codec setting. When wireless network conditions degrade, for example, there is an option that a lower bit rate of the codec may be used. The wireless network will try to ensure a channel condition sufficient to not have a dropped session (e.g., a dropped call) by using various techniques, such as Transmission Time Interval (TTI) bundling at a cell edge. However, depending on the characteristics of the change of condition (e.g., rate of change, degree of change, etc.), the session may drop before a different bit rate can be used.

Also according to one approach, the wireless network may override a codec selection in the case of a UE that is roaming and interoperating with another carrier. However, the wireless network may select a particular codec according to a pre-configured network policy.

While such an approach provides a framework to initiate and maintain a session using a particular codec, this type of approach may not be optimal since the list of codecs negotiated is static and wireless conditions in the wireless network and relative to the UE are not. Additionally, when the wireless network selects the codec, similar issues may arise due to the static policy of codec selection.

The term “codec” is intended to include an audio codec, a video codec, and/or an audio and video codec. While particular codec standards are mentioned in this description, an exhaustive treatment of available codecs is beyond the scope of this description. In this regard, exemplary embodiments of dynamic codec negotiation, as described herein, may be implemented using codecs which may not have been specifically described herein. Additionally, while exemplary embodiments described may be implemented based on the use of a particular protocol and/or message, such implementations are not intended to be restrictive or provide an exhaustive treatment, as such. In other words, the embodiments described herein may be implemented using other suitable protocols and/or messages which may not be specifically described herein.

According to an exemplary embodiment, a UE selects a list of codecs based on one or multiple criteria. According to an exemplary implementation, the list of codecs is selected based on a state of the wireless network state. According to an exemplary implementation, a wireless station (e.g., evolved Node B (eNB)) transmits the congestion state of the wireless network, which is carried by a System Information Block (SIB) notification, to the UE.

Additionally, or alternatively, according to an exemplary embodiment, the UE selects the list of codecs based on wireless conditions between the UE and the wireless network. For example, the UE measures the connection state (e.g., downlink conditions) between the wireless station and the UE, such as power (e.g., Received Signal Strength Indicator (RSSI), Reference Signal Received Power (RSRP)), quality (e.g., Reference Signal Received Quality (RSRQ), etc.), and error rate (e.g., Frame Error Rate (FER), Block Error Rate (BLER), Speech Error Rate (SER), etc.).

Additionally, or alternatively, according to an exemplary embodiment, the UE selects the list of codecs based on wireless conditions between the wireless network and the UE. According to an exemplary implementation, the UE estimates the connection state (e.g., uplink conditions) based on the connection state between the UE and the wireless network (e.g., downlink conditions) and downlink control information (DCI) (e.g., a power control command; uplink modulation and coding scheme (MCS), etc.) from a network device of the wireless network. According to another exemplary implementation, the UE receives an uplink metric value (e.g., a signal-to-interference-plus-noise ratio (SINR), a received signal strength indicator (RRSI), etc.) from the network device of the wireless network.

Additionally, or alternatively, according to an exemplary embodiment, the UE selects the list of codecs based on a codec preference of the wireless network(s) to which an originating UE and/or a terminating UE is/are attached. For example, an originating UE may store a list of codecs pertaining to one or multiple network types (e.g., a Long Term Evolution (LTE) network, a Code Division Multiple Access (CDMA) network, a Wideband CDMA network, etc.) and/or one or multiple wireless network service providers (e.g., Verizon, AT&T, etc.). Additionally, or alternatively, the originating UE obtains a codec preference of the wireless network to which the terminating UE. Additionally, or alternatively, the originating UE obtains other criteria from the terminating UE perspective (e.g., downlink conditions, network state, etc.).

As previously described, according to an exemplary embodiment, the UE selects the list of codecs based on various criteria, such as wireless network state, uplink connection state, downlink connection state, and/or network preference. According to an exemplary embodiment, the UE selects the list of codecs based on a mapping between the criteria and a set of codec lists. Additionally, since one codec may have a different set of characteristics compared to another codec, the granularity of the mapping of criteria and lists may vary between different codec standards (Adaptive Multi-Rate (AMR), Enhanced Voice Services (EVS), etc.), modes provided and/or characteristics afforded by a particular codec standard, such as bandwidth (e.g., wideband, narrowband, super wideband, etc.), bitrate, error rate, frequency range, sampling rate, etc.

According to an exemplary embodiment, the mapping of the criteria to a codec list is based on an evaluation process. For example, according to an exemplary implementation, the UE compares the value of each criteria to a threshold value pertaining to that criteria. For example, the UE obtains an RSRP value through measurement and compares that RSRP value to a threshold RSRP value (e.g., a single value or a range of values) with respect to one or multiple entries. Additionally, the UE obtains other values pertaining to other downlink metrics. Based on the results of the comparisons, the UE selects a codec list that is mapped to the results of the comparisons. According to an exemplary embodiment, the codec list indicates multiple codecs and their corresponding attributes (e.g., bandwidth, etc.).

According to an exemplary embodiment, the UE selects the codec list based on other criteria not previously mentioned. According to an exemplary embodiment, the UE selects the codec list based on the category of the session. For example, depending on whether the UE is initiating an audio session, a video session, or an audio and video session, the UE selects a codec based on the category of the session. Additionally, or alternatively, the UE selects the codec list based on a type of session within a category. For example, depending on whether the audio session is a voice session or a music session, the UE may select one codec list over another codec list. By way of example, the bandwidth of the codec may be narrow for a voice session compared to music session. Additionally, or alternatively, other characteristics of the codec (e.g., error correction, etc.) may be preferred depending on whether the audio session is a voice session versus a music session.

FIG. 1is a diagram illustrating an exemplary environment100in which exemplary embodiments of dynamic codec negotiation may be implemented. As illustrated, environment100includes a wireless network105and an external network125. As further illustrated, environment100includes a wireless device150-1and a wireless device150-2(also referred to collectively as wireless devices150and generally or individually as wireless device150).

Environment100may be implemented to include wireless connections between wireless devices150and wireless network105. A connection may be direct or indirect and may involve an intermediary device and/or an intermediary network not illustrated inFIG. 1. Additionally, the number and the arrangement of the connection between wireless device150and wireless network105are exemplary.

Wireless network105includes one or multiple wireless networks of one or multiple types. Wireless network105may be implemented using various wireless architectures, standards, and/or technologies. For example, wireless network105may include a cellular network, such as a 3rdGeneration (3G) network, a 3.5G network, a 4G network, etc. By way of further example, wireless network105may be implemented to include an LTE network, a Universal Mobile Telecommunications System (UMTS) network, a Global System for Mobile Communications (GSM) network, a Wideband Code Division Multiple Access (WCDMA) network, an Ultra Mobile Broadband (UMB) network, a High-Speed Packet Access (HSPA) network, an Evolution Data Optimized (EV-DO) network, a Worldwide Interoperability for Microwave Access (WiMAX) network, and/or another type of wireless network (e.g., an LTE Advanced network, a future generation wireless network architecture, etc.).

Network device110-1through network device110-X (also referred to network devices110or generally as network device110), in which X>1, each includes a wireless communication device. For example, network device110may be implemented as a network device110that provides access to wireless network105. By way of example, network device110may be implemented as a base station, a base station controller, an eNB, a home eNB, a home Node B, a pico base station, a femto device, a base transceiver station, a user device gateway, a radio node, an anchor point, a wireless router, etc.

Given the wide variety of wireless networks that may be implemented in various embodiments, wireless network105may include other types of network devices, such as a wireless relay node, a repeater, a network device that pertains to billing, security (e.g., a firewall, etc.), authentication and authorization, network policies, providing a service or an asset, providing access to another network, a serving gateway (SGW), etc. A network device may support one or multiple access and/or wireless technologies.

External network125includes one or multiple networks of one or multiple types. For example, external network125may be implemented as a service or application-layer network, the Internet, an Internet Protocol Multimedia Subsystem (IMS) network, a proprietary network, a cloud network, a data network, etc. External network125may include a network device130that provides an application or a service, such as a web server, a communication server (e.g., video telephony, Voice over Internet Protocol (VoIP), Voice over LTE (VoLTE)), a media streaming service, etc., or other type of application or service in which an audio session, a video session, or an audio and video session may be established with wireless device150and a codec used.

Wireless device150includes a device with wireless communicative capabilities. Wireless device150may be a mobile device. For example, wireless device150may be implemented as a smartphone, a tablet device, a netbook, a vehicular communication system within a vehicle, a computer, a wearable device (e.g., a watch, glasses, etc.), a music playing device, a location-aware device, or other mobile, wireless device. Alternatively, wireless device150may be a non-mobile (e.g., stationary) device. For example, wireless device150may be implemented as a kiosk, a point of sale terminal, a vending machine, a set top box, a smart television, etc. According to an exemplary embodiment, wireless device150includes a dynamic codec component. The dynamic codec component provides a dynamic codec service, as described herein.

An exemplary embodiment of dynamic codec negotiation is described further below in relation toFIGS. 2A-2E.FIG. 2Aillustrates an exemplary environment200in which an exemplary embodiment of dynamic codec negotiation may be implemented. As illustrated, environment200includes an LTE network205, which is an exemplary implementation of wireless network105, and an eNB210-1and an eNB210-2, which are an exemplary implementation of network devices110. Additionally, environment200includes an IMS network230, which is an exemplary implementation of external network125, and a device235, which is an exemplary implementation of network device130. For example, device235may be a telephony application server. As further illustrated, environment200includes wireless devices150.

It may be assumed, although not illustrated, that other network elements (e.g., a packet data network gateway (PGW), a SGW, a mobility management entity (MME), etc.) exist in LTE network205, but have been omitted for purposes of brevity. Although environment200includes one network of a specific type (e.g., LTE), according to other embodiments, dynamic codec negotiation may be implemented in an environment that includes multiple networks, which may be of the same type or of a different type.

According to an exemplary embodiment, wireless device150is pre-configured with codec lists that are mapped to criteria. The dynamic codec component of wireless device150selects a codec list based on the mapping between the criteria and codec lists.

Referring toFIG. 2A, according to an exemplary scenario, assume a user215-1operates wireless device150-1and a user215-2operates wireless device150-2. Assume wireless device150-1is attached to and registered with (e.g., camped) LTE network205via eNB210-1, and wireless device150-1is similarly camped with LTE network205via eNB210-2. Additionally, wireless device150-1and wireless device150-2each registers with IMS network230. For example, wireless device150-1and wireless device150-2performs a Proxy-Call Session Control Function (P-CSCF) discovery and registration process.

Thereafter, user215-1initiates a VoLTE call, via wireless device150-1, to wireless device150-2and user215-2. For example, user215-1may open a voice application on wireless device150-1. In response to the input of user215-1, the dynamic codec component of wireless device150-1obtains downlink metrics from a wireless communication interface of wireless device150-1. For example, wireless device150-1performs downlink measurements and the dynamic codec component obtains and stores downlink metric values via a modem. The dynamic codec component also obtains congestion information pertaining to LTE network205based on wireless device150-1listening to a System Information Block Type 2 message.

As further illustrated inFIG. 2A, wireless device150-1transmits a measurement report message to eNB210-1. In response to receiving the measurement report or based on a standard downlink control information (DCI) messaging carried in the physical downlink control channel (PDCCH), eNB210-1transmits downlink control information (DCI). By way of further example, the DCI information may indicate resource blocks, a modulation and coding scheme (MCS), and uplink (UL) power control directed to wireless device150-1. Based on the downlink measurements and the DCI information, according to an exemplary implementation, wireless device150-1estimates the uplink conditions. For example, the dynamic codec component may reference an uplink estimation table500, as illustrated inFIG. 5, which is stored by wireless device150-1. Uplink estimation table500stores a mapping between downlink conditions and downlink control information to estimated uplink conditions, as described further below.

Referring toFIG. 5, uplink estimation table500includes an origin downlink field505, a downlink control information field510, and an origin uplink field515. The fields illustrated inFIG. 5and described herein are exemplary. According to other implementations, uplink estimation table500may store additional, fewer, and/or different instances of data. For example, according to other exemplary implementations, uplink estimation table500may not include origin downlink field505or downlink control information field510.

The selection of downlink information, the data (e.g., threshold values, etc.) included therein for mapping to an estimated uplink conditions, etc., as described in relation to exemplary uplink estimation table500, may be based on previous measurements, testing, etc., performed by network administrative personnel, etc., as well as wireless communication theory, etc. Additionally, although according to an exemplary implementation, the mapping of criteria to estimated uplink conditions is illustrated and described in relation to a table, the mapping of downlink information to estimated uplink conditions may be implemented in other types of well-known data structures and/or a database.

Origin downlink field505stores threshold values pertaining to downlink measurements. For example, origin downlink field505stores threshold values pertaining to one or multiple criteria pertaining to downlink conditions, such as power (e.g., RRSI, RSRP), quality (RSRQ), etc., as previously described. Downlink control information field510stores threshold values pertaining to downlink control information (e.g., particular modulation and coding schemes (MCSs), transmit power, etc.). Origin uplink field515stores estimated threshold values pertaining to uplink conditions from the perspective of an intermediary network device (e.g., eNB210).

The dynamic codec component uses the measured downlink metric values and the downlink control information compared to the information stored in origin downlink field505and downlink control information field510to determine which record (e.g., a record520) in uplink estimation table500provides a mapping between downlink conditions and downlink control information to estimated uplink conditions. When the dynamic codec component determines a match or a best-fit, the dynamic codec component may use the origin uplink information stored in origin uplink field515of the selected record as a basis for selecting a list of codecs, as described further below.

Referring toFIG. 2B, according to another exemplary scenario and in contrast toFIG. 2A, wireless device150-1obtains uplink metrics from eNB210-1. For example, wireless device150-1transmits a measurement report message to eNB210-1. In contrast to the measurement report message illustrated and described in relation toFIG. 2A, the measurement report message includes a flag or other form of data that indicates to the intermediary network device (e.g., eNB210-1) to provide uplink condition information. In response to receiving the measurement report message with flag (as illustrated in2B), eNB210-1transmits DCI and uplink information to wireless device150-1via the PDCCH. For example, the DCI and uplink message includes downlink control information and uplink metric values. By way of further example, the uplink metric values may include an SINR value, an RSSI value, and/or a channel state indicator (CSI)/precoding matrix indicator (PMI) value. In an LTE context, the eNB typically performs measurements pertaining to these metrics. However, unlike the exemplary implementation described herein, these measurements are not provided to the UE. Nevertheless, since the eNB typically performs such measurements, resource utilization of the eNB in order to provide these uplink metrics to wireless device150is minimized since the eNB typically calculates uplink metric values for other reasons (e.g., scheduling, etc.). According to other exemplary implementations, the eNB may be configured to provide additional and/or different uplink metrics to the UE including the physical uplink shared channel (PUSCH) power and uplink SINR.

As previously described, according to an exemplary embodiment, other types of criteria may be used as a basis for selecting a list of codecs. For example, the type of session for which the codec applies may be a consideration. Additionally, or alternatively, a network preference (e.g., LTE network205preference) toward one or multiple codecs may also be a consideration. For example, wireless device150-1may store network codec preference information.

Referring toFIG. 2C, the dynamic codec component of wireless device150-1selects a list of codecs based on the accumulated criteria. For example, the dynamic codec component may reference a codec list table600, as illustrated inFIG. 6, which is stored by wireless device150-1. Codec list table600stores a mapping between criteria and different codec lists, as described further below.

Referring toFIG. 6, codec list table600includes an origin downlink field605, an origin uplink field610, an origin network condition and/or network preference field615, a terminate downlink field620, a terminate network condition and/or network preference field625, a category of session field630, and a codec list field635. The fields illustrated inFIG. 6and described herein are exemplary. According to other implementations, codec list table600may store additional, fewer, and/or different instances of data. For example, according to other exemplary implementations, codec list table600may not include field610, field615, field620, field625, and/or field630. Additionally, or alternatively, codec list table600may include a terminating uplink field (not shown), which includes information analogous to field610, but from the terminating side perspective.

The selection of criteria, the data (e.g., threshold values, etc.) included therein for mapping, the list of codecs that are mapped to the criteria, etc., as described in relation to exemplary codec list table600, may be based on previous measurements, testing, etc., performed by network administrative personnel, as well as wireless communication theory, etc. Additionally, although according to an exemplary implementation, the mapping of criteria to a list of codecs is illustrated and described in relation to a table, the mapping of criteria to a list of codecs may be implemented in other types of well-known data structures and/or a database.

Origin downlink field605and origin uplink field610store information similar to that previously described in relation to origin downlink field505and origin uplink field515ofFIG. 5. Origin network condition and/or network preference field615stores a threshold congestion pertaining to a wireless network (e.g., LTE network205) and/or a codec that is a wireless network preference of the wireless network.

Terminate downlink field620is criteria pertaining to a terminating device of the session to which the list of codecs pertains. For example, with reference toFIG. 2A, wireless device150-2may provide, to wireless device150-1, a downlink metric value (e.g., a power value, a quality value, etc.) pertaining to the downlink conditions between wireless device150-2and eNB210-2. An exemplary embodiment of this procedure is described further below.

Terminate network condition and/or network preference field625stores information similar to that of origin network condition and/or network preference field615, except that such information pertains to congestion associated with eNB210-2and network preferences thereof. In some cases, wireless device150-1and wireless device150-2may be camped on the same wireless network105(e.g., LTE network205). However, in other cases, wireless device150-1may be camped on LTE network205, and wireless device150-2may be camped on a different wireless network (e.g., a CDMA network (not illustrated), etc.). Wireless device150-2may provide this information to wireless device150-1. An exemplary embodiment of this procedure is also described further below.

Category of session field630indicates a category of a session. As previously described, a codec that is included in the list of codecs may be an audio codec, a video codec, or an audio and video codec. In this regard, category of session field630may indicate various categories of sessions such as an audio session, a video session, or an audio and video session. Additionally, category of session field630may also indicate a particular type of audio session, such as a voice session, a music session, a radio streaming session, etc., or a particular type of application or service (e.g., VoIP, VoLTE, etc.). Similarly, category of session field630may indicate a particular type of audio and video session, such as an audio/video conference session, a program session (e.g., downloading or streaming a movie or other types of content available on web sites, etc.), etc.

Codec list field635stores a list of codecs that are mapped to criteria values (e.g., fields605through630, or any sub-combination thereof). According to an exemplary implementation, the list of codecs includes a listing of multiple codecs. The codecs may be ordered within the list based on a particular parameter. According to an exemplary implementation, the ordering of codecs may be from the most preferred codec (e.g., from a perspective of the originating wireless device) through a least preferred. According to other exemplary implementations, the ordering of codecs may be based on any other type of parameter (e.g., most-used, most preferred from a perspective of the terminating wireless device, random, wireless conditions and network conditions relative to both originating wireless device and terminating wireless device, etc.).

The dynamic codec component uses the criteria values compared to the information stored in fields605through630, or any sub-combination thereof, to determine which record (e.g., a record640) in codec list table600provides a mapping between the criteria values to a codec list. When the dynamic codec component determines a match or a best-fit, the dynamic codec component may use a codec list stored in codec list field635of the selected record.

Referring back toFIG. 2C, the dynamic codec component of wireless device150-1selects a list of codecs from codec list table600. As illustrated, wireless device150-1generates and transmits a SIP INVITE and SDP offer that includes the list of codecs selected from codec list table600. Wireless device150-1transmits the SIP INVITE and SDP offer via a default bearer. Wireless device150-1also establishes a dedicated bearer for the VoLTE session. Wireless device150-2receives the SIP INVITE and SDP offer via device235of IMS network230.

According to an exemplary embodiment, wireless device150-2does not provide terminating side information, which was previously described in relation to terminate downlink field620and/or terminate network condition and/or network preference field625, to wireless device150-1. Rather, a dynamic codec component of wireless device150-2selects a codec from the list of codecs included in the SIP INVITE and SDP offer message.

According to another exemplary embodiment, wireless device150-1provides information, which was previously described in relation to terminate downlink field620and/or terminate network condition and/or network preference field625, to wireless device150-1. Each embodiment is described further below.

Referring toFIG. 2C, according to an exemplary embodiment, wireless device150-2receives the codec list, but does not provide termination side information. The dynamic codec component of wireless device150-2analyzes the codec list and selects a codec from the codec list. According to an exemplary implementation, the dynamic codec component selects the codec from the list of codecs received based on channel conditions and/or other metrics (e.g., network congestion, etc.) pertaining to wireless device150-2and supportable by wireless device150-1. In this regard, the dynamic codec component selects the codec that provides a best-fit or optimal codec supportable by both wireless device150-1and wireless device150-2. By way of example, when the codec list includes codecs that are meant for less than ideal wireless conditions and/or network conditions from the originating side (e.g., wireless device150-1), and wireless device150-2determines that wireless conditions and network conditions from its perspective are ideal, the dynamic codec component selects the most preferred codec listed in the list of codecs, in view of the less than ideal conditions to which wireless device150-1is subjected.

Thereafter, wireless device150-2generates and transmits a SIP 200 OK message that includes an SDP Answer. The SDP Answer includes data indicating the selected codec. Wireless device150-1receives the SIP 200 OK message. Thereafter, wireless device150-1and wireless device150-2each uses the selected codec during a VoLTE session. For purposes of brevity, other messages (SIP 200 OK (Provisional Response Acknowledgement (PRACK)), SIP 180 (Ringing), a SIP (Acknowledgement (ACK)), etc.) that may be exchanged before the establishment of the VoLTE session have been omitted.

Referring toFIG. 2D, according to an exemplary embodiment, wireless device150-2receives the codec list, and in response, obtains terminating side information to provide to wireless device150-1. For example, wireless device150-2measures a downlink metric (e.g., power, quality, etc.) in a manner similar to that previously described in relation to wireless device150-1. Additionally, or alternatively, wireless device150-2obtains congestion information pertaining to LTE network205based on wireless device150-2listening to a System Information Block Type 2 message. Additionally, or alternatively, wireless device150-2may estimate uplink conditions or obtain uplink condition information from eNB210-2in a manner similar to that previously described with respect to wireless device150-1. Additionally, or alternatively, wireless device150-2may obtain network codec preference information pertaining to LTE network205.

As further illustrated, according to an exemplary implementation, wireless device150-2generates and transmits a SIP OK that includes a SDP Answer. The terminating side information may be carried in, for example, a header of the SIP OK message, or other suitable portion of the message (e.g., trailer, a reserved field, etc.). Wireless device150-1receives the SIP OK message. Referring toFIG. 2E, the dynamic codec component of wireless device150-1selects a list of codecs from codec list table600based on the received, terminating side information and other criteria. Wireless device150-1generates and transmits another SIP INVITE and SDP offer that includes the list of codecs selected from codec list table600. Thereafter, the call flow proceeds in a manner similar to that previously described inFIG. 2C.

According to another exemplary implementation, as illustrated inFIG. 2F, subsequent to receiving the initial SIP INVITE and SDP offer, wireless device150-2generates and transmits a SIP 183 Progress response. The terminating side information may be carried in, for example, a header of the SIP 183 message, or other suitable portion of the message. Wireless device150-1receives the SIP 183 message. Thereafter, in a manner similar to that previously described, the dynamic codec component of wireless device150-1selects a list of codecs from codec list table600based on the received, terminating side information and other criteria. Wireless device150-1generates and transmits another SIP INVITE and SDP offer that includes the list of codecs selected from codec list table600. Thereafter, the call flow proceeds in a manner similar to that previously described inFIG. 2C.

AlthoughFIGS. 2A-2Fillustrate exemplary call flows and messaging, according to other implementations, depending on the wireless network, the protocols used, etc., criteria information and/or terminating side information may be carried by messages and/or use of protocols different from those described.

FIG. 3is a diagram illustrating exemplary components of a device300that may correspond to one or more of the devices in the environments described herein. For example, device300may correspond to network devices of wireless network105and wireless device150. As illustrated, according to an exemplary embodiment, device300includes a processor305, memory/storage310that stores software315, a communication interface320, an input325, and an output330. According to other embodiments, device300may include fewer components, additional components, different components, and/or a different arrangement of components than those illustrated inFIG. 3and described herein.

Processor305may control the overall operation or a portion of operation(s) performed by device300. Processor305may perform one or multiple operations based on an operating system and/or various applications or programs (e.g., software315). Processor305may access instructions from memory/storage310, from other components of device300, and/or from a source external to device300(e.g., a network, another device, etc.).

Memory/storage310includes one or multiple memories and/or one or multiple other types of storage mediums. For example, memory/storage310may include one or multiple types of memories, such as, random access memory (RAM), dynamic random access memory (DRAM), cache, read only memory (ROM), a programmable read only memory (PROM), a static random access memory (SRAM), a single in-line memory module (SIMM), a phase-change memory (PCM), a dual in-line memory module (DIMM), a flash memory, and/or some other type of memory. Memory/storage310may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.), a Micro-Electromechanical System (MEMS)-based storage medium, and/or a nanotechnology-based storage medium. Memory/storage310may include drives for reading from and writing to the storage medium.

Memory/storage310may be external to and/or removable from device300, such as, for example, a Universal Serial Bus (USB) memory stick, a dongle, a hard disk, mass storage, off-line storage, or some other type of storing medium (e.g., a compact disk (CD), a digital versatile disk (DVD), a Blu-Ray® disk (BD), etc.). Memory/storage310may store data, software, and/or instructions related to the operation of device300.

Software315includes an application or a computer program that provides a function and/or a process. Software315may include firmware. For example, with reference to wireless device150, software315may include an application that, when executed by processor305, provides the dynamic codec service, as described herein. Additionally, for example, with reference to network device110, software315may include an application that, when executed by processor305, provides the dynamic codec service, as described herein. For example, eNB210-2may include an application, which when executed, provides uplink conditions to wireless device150.

Communication interface320permits device300to communicate with other devices, networks, systems, etc. Communication interface320may include one or multiple wireless interfaces and/or wired interfaces. Communication interface320may include one or multiple transmitters and receivers or transceivers. Communication interface320may include one or multiple antennas. Communication interface320may operate according to a protocol and a communication standard.

Input325permits an input into device300. For example, input325may include a keyboard, a mouse, a display, a touchscreen, a touchless screen, a button, a switch, an input port, speech recognition logic, and/or some other type of visual, auditory, tactile, etc., input component. Output330permits an output from device300. For example, output330may include a speaker, a display, a touchscreen, a touchless screen, a light, an output port, and/or some other type of visual, auditory, tactile, etc., output component.

Device300may perform a process and/or a function, as described herein, in response to processor305executing software315stored by memory/storage310. By way of example, instructions may be read into memory/storage310from another memory/storage310(not shown) or read from another device (not shown) via communication interface320. The instructions stored by memory/storage310may cause processor305to perform a process described herein. Alternatively, for example, according to other implementations, device300may perform a process described herein based on the operation of hardware (processor305, etc.).

FIG. 4Ais a flow diagram that illustrates an exemplary process400pertaining to dynamic codec negotiation. Process400is directed to a process previously described above with respect toFIGS. 2A-2Cand elsewhere in this description, in which a list of codecs is selected based on various criteria for presentment to a device during a codec negotiation. For example, process400is directed to an exemplary embodiment in which dynamic codec negotiation is performed without receiving terminating side information. According to an exemplary embodiment, wireless device150performs the steps described in process400. For example, processor305may execute software315to provide a dynamic codec service.

Referring toFIG. 4A, process400may begin, in block405, with receiving an input, by a device, to initiate any of an audio session, a video session, or an audio and video session. For example, a triggering event is received by a wireless device150to initiate a session. According to an exemplary implementation, the triggering event is user-initiated. By way of further example, the user may initiate a session, via wireless device150, to start a session with another end user device (e.g., wireless device150) or a network device (e.g., a media server, etc.). The dynamic codec component of wireless device150may identify that any of an audio session, a video session, or an audio and video session has been initiated. Additionally, the dynamic codec component of wireless device150may identify a type of audio session, a type of video session, or a type of audio and video session based on the input. For example, when the user initiates a session via a telephone application, the dynamic codec component may determine that the type of audio session is a voice call.

In block410, criteria information is obtained. For example, the dynamic codec component of wireless device150may obtain criteria information. As previously described, the criteria information may include downlink conditions, uplink conditions, network conditions, and/or network codec preferences. According to an exemplary implementation, the dynamic codec component estimates uplink conditions based on a lookup of uplink estimation table500. According to another exemplary implementation, the dynamic codec component obtains uplink condition values from network device110of wireless network105.

In block415, a list of codecs is selected based on the criteria information. For example, the dynamic codec component selects a list of codecs based on a lookup of codec list table600.

In block420, the list of codecs is transmitted to another device. For example, wireless device150transmits the list of codecs to another device with which wireless device150is to establish the session. By way of further example, wireless device150may transmit a SIP INVITE with an SDP offer, which carries the selected list of codecs.

In block425, a response from the other device is received in which the response indicates a selection of a codec from the list of codecs. For example, wireless device150receives a response from the other device with which wireless device150is to establish the session. By way of further example, wireless device150may receive a SIP 200 OK and an SDP Answer, which carries the selected codec.

In block430, the selected codec is used by the device and the other device during the session. For example, wireless device150and the other device establish a session and use the selected codec to transmit and/or receive data.

AlthoughFIG. 4Aillustrates an exemplary dynamic codec negotiation process400, according to other embodiments, process400may include additional operations, fewer operations, and/or different operations than those illustrated inFIG. 4A, and as described herein. For example, with respect to block425, wireless device150may determine whether the response includes terminating side information. When the response does include terminating side information, wireless device150may select another list of codecs based on the terminating side information received, as described herein. When the response does not include terminating side information, wireless device150proceeds to block430, as set forth inFIG. 4A, block430.

According to an exemplary embodiment, dynamic codec component stores historical information pertaining to whether a terminating device provides terminating side information. For example, in the case of VoLTE calls, a user of a wireless device may regularly call his or her friend. The friend's wireless device may or may not provide terminating side information. In the event that the friend's wireless device provides terminating side information, the dynamic codec component may store this information. Alternatively, this information may be stored in relation to the user's contact list. In this way, the dynamic codec component of the wireless device may expect terminating side information when the user initiates a VoLTE session with the friend.

Based on the historical information, according to an exemplary embodiment, the dynamic codec component may not transmit a list of codecs with the initial SIP INVITE and SDP offer since the dynamic codec component will select a list of codecs once the terminating side information is obtained. Alternatively, according to another exemplary embodiment, the dynamic codec component may select a “dummy” codec list (or other data, such as a request for terminating side information) and transmit that “dummy” codec list or other data with the initial SIP INVITE and SDP offer. In either implementation, the dynamic codec component may reduce resource utilization (e.g. processing, etc.) in selecting an initial codec list, as well as expedite the dynamic codec negotiation process. According to an exemplary implementation, the “dummy” codec list is stored in codec list table600.

FIGS. 4B and 4Care flow diagrams that illustrate an exemplary process450pertaining to dynamic codec negotiation. Process450is directed to a process previously described above with respect toFIGS. 2A-2Fand elsewhere in this description, in which a list of codecs is selected based on various criteria for presentment to a device during a codec negotiation. For example, process450is directed to an exemplary embodiment in which dynamic codec negotiation is performed based on receiving terminating side information. According to an exemplary embodiment, wireless device150performs the steps described in process450. For example, processor305may execute software315to provide a dynamic codec service.

Since block455through470ofFIG. 4Bare similar to blocks405through420ofFIG. 4A, a description of these steps will not be reiterated for the sake of brevity. Referring to block475of process450, and in contrast to process400, a response is received from the other device that includes terminating side information. By way of example, the response may be a SIP 200 OK and an SDP Answer, which carries the terminating side information. According to another example, the response may be a SIP 183 Progress response, which carries the terminating side information.

In block480, a list of codecs is selected based on the criteria information and the terminating side information. For example, the dynamic codec component selects another list of codecs (or an initial list of codecs when a dummy codec list or other data is transmitted in block470) based on a lookup of codec list table600.

Referring toFIG. 4C, block485, the list of codecs is transmitted to another device. For example, wireless device150transmits the list of codecs to another device with which wireless device150is to establish the session. By way of further example, wireless device150may transmit a SIP INVITE with an SDP offer, which carries the selected list of codecs.

Since blocks490and495ofFIG. 4Care similar to blocks425and430ofFIG. 4A, a description of these steps will not be reiterated for the sake of brevity.

AlthoughFIGS. 4B and 4Cillustrate an exemplary dynamic codec negotiation process450, according to other embodiments, process450may include additional operations, fewer operations, and/or different operations than those illustrated inFIGS. 4B and 4C, and as described herein. For example, with respect to block475, wireless device150may determine whether the response includes terminating side information. Additionally, or alternatively, historical information may be used such that a dummy codec list or other data may be transmitted in block470, as previously mentioned.

In view of the foregoing, exemplary embodiments of dynamic codec negotiation may improve the chances that a session is established and maintained since the selection of a list of codecs is based on various criteria, as described herein.

The foregoing description of embodiments provides illustration, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded as illustrative rather than restrictive. For example, according an exemplary embodiment, a wireless device may initiate a re-negotiation of codecs, during the session, when wireless conditions and/or network conditions change. By way of further example, when downlink conditions and/or network congestion levels are poor, the wireless device may select another list of codecs that mapped to the changed conditions, and transmit the list of codecs to the other device. According to an exemplary implementation, when the wireless device receives a request for TTI bundling from the wireless network (e.g., eNB), the received request may serve as a trigger to the wireless device to re-negotiate codecs with another device.

Additionally, exemplary embodiments of dynamic codec negotiation may form a basis for improved network resource utilization. For example, according to one approach, a wireless network may use TTI bundling when a wireless device enters a radio frequency (RF) condition that is below a threshold for a given codec in view of the attributes (e.g., error correction, etc.) afforded by the codec. Without interaction between a higher layer (e.g., above the physical layer and/or the media access control (MAC) layer), which may identify the codec being used during a session, and a lower layer, which may enable certain low level error correction and redundancy (e.g., such as TTI bundling), network resource utilization may be sub-optimal. According to an exemplary embodiment, the wireless network may dynamically operate according to the codec being used. By way of example, the wireless network may hold in abeyance the use of TTI bundling when a codec, which is being used during a session, affords a high error correction. Since the dynamic codec negotiation provides for the selection of a codec that best suits the wireless conditions and/or network conditions at the time the session is initiated, as well as re-negotiation during the session, the wireless network may improve network resource utilization by relying on the attributes of the codec.

Additionally, for example, Hybrid Automatic Repeat Request (HARQ) processes may be adapted to the codec in use. For example, according to one approach, the HARQ process may ensure a certain target residual BLER based on an initial block error rate associated with a first transmission. The parameters under control include retransmission, transport block size (TBS), MCS, and assignment and physical resource block (PRB) allocation for the wireless device. A network device of the wireless network may calculate these parameters based on CQI feedback, uplink RF conditions, packet buffer size, etc. However, the network device may relax the target residual BLER, based on identifying the codec being used during a session. For example, a radio resource management module of an eNB may save layer 2 resources pertaining to scheduling based on the identification of the codec being used during a session and the attributes of the codec that stem therefrom.

The terms “a,” “an,” and “the” are intended to be interpreted to include one or more items. Further, the phrase “based on” is intended to be interpreted as “based, at least in part, on,” unless explicitly stated otherwise. The term “and/or” is intended to be interpreted to include any and all combinations of one or more of the associated items.

The embodiments described herein may be implemented in many different forms of software and/or firmware executed by hardware. For example, a process or a function may be implemented as “logic” or as a “component.” The logic or the component may include, for example, hardware (e.g., processor305, etc.), or a combination of hardware and software (e.g., software315). The embodiments have been described without reference to the specific software code since the software code can be designed to implement the embodiments based on the description herein and commercially available software design environments/languages.

Additionally, embodiments described herein may be implemented as a non-transitory storage medium that stores data and/or information, such as instructions, program code, data structures, program modules, an application, etc. A non-transitory storage medium includes one or more of the storage mediums described in relation to memory/storage310.

The word “exemplary” is used herein to mean “serving as an example.” Any embodiment or implementation described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or implementations.

No element, act, or instruction described in the present application should be construed as critical or essential to the embodiments described herein unless explicitly described as such.