INCREASING NETWORK COVERAGE USING RATE ADAPTATION

Aspects of the present disclosure provide techniques and apparatus for wireless communication, and more particularly, increasing network coverage using rate adaption. The techniques include adjusting a cell transition threshold based on, for example, maximum packet loss rates (PLRs) for a VOIP terminal, for example, taking into consideration application layer redundancy employed at the terminal. Numerous other aspects are provided.

FIELD OF THE DISCLOSURE

Aspects of the present disclosure relate generally to wireless communications, and more particularly, to techniques and apparatus for improving coverage in wireless networks during communication sessions, such as voice over IP (VOIP) calls.

DESCRIPTION OF RELATED ART

These multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate on a municipal, national, regional, and even global level. An example of an emerging telecommunication standard is Long Term Evolution (LTE). LTE is a set of enhancements to the Universal Mobile Telecommunications System (UMTS) mobile standard promulgated by Third Generation Partnership Project (3GPP). It is designed to better support mobile broadband Internet access by improving spectral efficiency, lowering costs, improving services, making use of new spectrum, and better integrating with other open standards using OFDMA on the downlink (DL), SC-FDMA on the uplink (UL), and multiple-input multiple-output (MIMO) antenna technology.

As the demand for mobile broadband access continues to increase, there exists a need for further improvements in wireless technologies. Preferably, these improvements should be applicable to multi-access technologies and the telecommunication standards that employ these technologies.

One example of such improvement is the ability for a media receiver, such as a user equipment (UE), to request a sender (e.g., another UE) to switch to a more robust codec configuration when it detects high packet loss during a media session. Unfortunately, if the corresponding network entities are unaware of this ability, they may set packet loss rate (PLR) handover thresholds based on less robust codec configurations. This may lead to premature handover, triggered by a given PLR, before the media receiver has the opportunity to request a switch to a more robust codec configuration.

SUMMARY

Certain aspects of the present disclosure provide a method for wireless communications by a network entity. The method generally includes receiving signaling of information indicating capability of a UE to handle at least one target packet loss rate (PLR) and determining, based on the information, a maximum PLR associated with the UE.

Certain aspects of the present disclosure provide a method for wireless communications by a UE. The method generally includes signaling information indicating capability of the UE to handle at least one target packet loss rate (PLR), the signaling designed to allow a network entity to determine one or more thresholds for handover of the UE from a packet switched (PS) radio access network (RAN) to a circuit switched (CS) radio access network (RAN), and employing application layer redundancy to transmit a plurality of voice over Internet Protocol (VoIP) packets.

Certain aspects of the present disclosure provide a method for wireless communications by a network entity. The method generally includes receiving signaling of a parameter indicating capability of a first user equipment (UE) to request, during a media session with a second UE, that the second UE switch from a first codec configuration to a second codec configuration and determining one or more thresholds for handover of the UE, based on the parameter.

Certain aspects of the present disclosure provide a method for wireless communications by a UE. The method generally includes signaling, to a network entity, parameter indicating capability of the first UE to request, during a media session with a second UE, that the second UE switch from a first codec configuration to a second codec configuration, detecting a packet loss rate (PLR) above a threshold value, while participating in the media session with the second UE using the first codec configuration, and requesting, in response to detecting the PLR above the threshold value, that the second UE switch from to the second codec configuration.

Numerous other aspects are provided including methods, apparatus, systems, computer program products, and processing systems.

DETAILED DESCRIPTION

Aspects of the present disclosure provide techniques that allow a network entity to determine a maximum packet loss rate (MaxPLR) supported by a VOIP terminal and/or adjust handover thresholds based on the maximum packet loss rate (MaxPLR) supported by a VOIP terminal, such as a Voice over LTE (VoLTE) UE. The actual MaxPLR may depend, for example, on a type of redundancy employed by the UE to re-transmit part or all of one or more voice frames to improve reliability. For example, application layer redundancy (where entire voice frames may be repeatedly transmitted) may allow a UE to tolerate a higher MaxPLR than it could otherwise tolerate.

The techniques described herein may be used for various wireless communication networks such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA) and other networks. The terms “network” and “system” are often used interchangeably. A CDMA network may implement a radio access technology (RAT) such as universal terrestrial radio access (UTRA), cdma2000, etc. UTRA includes wideband CDMA (WCDMA) and other variants of CDMA. cdma2000 covers IS-2000, IS-95 and IS-856 standards. IS-2000 is also referred to as 1× radio transmission technology (1×RTT), CDMA2000 1×, etc. A TDMA network may implement a RAT such as global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), or GSM/EDGE radio access network (GERAN). An OFDMA network may implement a RAT such as evolved UTRA (E-UTRA), ultra mobile broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM®, etc. UTRA and E-UTRA are part of universal mobile telecommunication system (UMTS). 3GPP long-term evolution (LTE) and LTE-Advanced (LTE-A) are new releases of UMTS that use E-UTRA, which employs OFDMA on the downlink and SC-FDMA on the uplink. UTRA, E-UTRA, UMTS, LTE, LTE-A and GSM are described in documents from an organization named “3rd Generation Partnership Project” (3GPP). cdma2000 and UMB are described in documents from an organization named “3rd Generation Partnership Project 2” (3GPP2). The techniques and apparatus described herein may be used for the wireless networks and RATs mentioned above as well as other wireless networks and RATs.

Circuit-switched fallback (CSFB) is a technique to deliver voice-services to a UE, when the UE is camped in a long-term evolution (LTE) network. This may be required when the LTE network does not support voice services natively. The LTE network and a 3GPP CS network (e.g., UMTS or GSM) may be connected using a tunnel interface. The UE may register with the 3GPP CS network while on the LTE network by exchanging messages with the 3GPP CS core network over the tunnel interface.

An Example Wireless Communications System

FIG. 1shows an exemplary deployment in which multiple wireless networks have overlapping coverage, in which aspects of the present disclosure may be performed. For example, a UE110may receive one or more session initiation protocol (SIP) requests (e.g., SIP:INVITE messages), from one or more other UEs110(e.g., via eNB122), to establish a call with the UE110. The UE110may postpone processing of the one or more SIP requests until detection that a predetermined amount of time has passed (e.g., expiry of a timer) without receiving a SIP request. After the predetermined amount of time has passed, the UE110may process the one or more SIP requests in response to the detection (e.g., based on a first-in-last-out protocol).

As shown inFIG. 1, an evolved universal terrestrial radio access network (E-UTRAN)120may support LTE and may include a number of evolved Node Bs (eNBs)122and other network entities that can support wireless communication for user equipments110(UEs). Each eNB122may provide communication coverage for a particular geographic area. The term “cell” can refer to a coverage area of an eNB and/or an eNB subsystem serving this coverage area. A serving gateway (S-GW)124may communicate with E-UTRAN120and may perform various functions such as packet routing and forwarding, mobility anchoring, packet buffering, initiation of network-triggered services, etc. A mobility management entity (MME)126may communicate with E-UTRAN120and serving gateway124and may perform various functions such as mobility management, bearer management, distribution of paging messages, security control, authentication, gateway selection, etc. The network entities in LTE are described in 3GPP TS 36.300, entitled “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description,” which is publicly available.

A radio access network (RAN)130may support GSM and may include a number of base stations132and other network entities that can support wireless communication for UEs. A mobile switching center (MSC)134may communicate with the RAN130and may support voice services, provide routing for circuit-switched calls, and perform mobility management for UEs located within the area served by MSC134. Optionally, an inter-working function (IWF)140may facilitate communication between MME126and MSC134(e.g., for 1×CSFB).

E-UTRAN120, serving gateway124, and MME126may be part of an LTE network102. RAN130and MSC134may be part of a GSM network104. For simplicity,FIG. 1shows only some network entities in the LTE network102and the GSM network104. The LTE and GSM networks may also include other network entities that may support various functions and services.

A UE110may be stationary or mobile and may also be referred to as a mobile station, a terminal, an access terminal, a subscriber unit, a station, etc. UE110may be a cellular phone, a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, etc.

Upon power up, UE110may search for wireless networks from which it can receive communication services. If more than one wireless network is detected, then a wireless network with the highest priority may be selected to serve UE110and may be referred to as the serving network. UE110may perform registration with the serving network, if necessary. UE110may then operate in a connected mode to actively communicate with the serving network. Alternatively, UE110may operate in an idle mode and camp on the serving network if active communication is not required by UE110.

UE110may be located within the coverage of cells of multiple frequencies and/or multiple RATs while in the idle mode. For LTE, UE110may select a frequency and a RAT to camp on based on a priority list. This priority list may include a set of frequencies, a RAT associated with each frequency, and a priority of each frequency. For example, the priority list may include three frequencies X, Y and Z. Frequency X may be used for LTE and may have the highest priority, frequency Y may be used for GSM and may have the lowest priority, and frequency Z may also be used for GSM and may have medium priority. In general, the priority list may include any number of frequencies for any set of RATs and may be specific for the UE location. UE110may be configured to prefer LTE, when available, by defining the priority list with LTE frequencies at the highest priority and with frequencies for other RATs at lower priorities, e.g., as given by the example above.

UE110may operate in the idle mode as follows. UE110may identify all frequencies/RATs on which it is able to find a “suitable” cell in a normal scenario or an “acceptable” cell in an emergency scenario, where “suitable” and “acceptable” are specified in the LTE standards. UE110may then camp on the frequency/RAT with the highest priority among all identified frequencies/RATs. UE110may remain camped on this frequency/RAT until either (i) the frequency/RAT is no longer available at a predetermined threshold or (ii) another frequency/RAT with a higher priority reaches this threshold. This operating behavior for UE110in the idle mode is described in 3GPP TS 36.304, entitled “Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode,” which is publicly available.

UE110may be able to receive packet-switched (PS) data services from LTE network102and may camp on the LTE network while in the idle mode. LTE network102may have limited or no support for voice-over-Internet protocol (VoIP), which may often be the case for early deployments of LTE networks. Due to the limited VoIP support, UE110may be transferred to another wireless network of another RAT for voice calls. This transfer may be referred to as circuit-switched (CS) fallback. UE110may be transferred to a RAT that can support voice service such as 1×RTT, WCDMA, GSM, etc. For call origination with CS fallback, UE110may initially become connected to a wireless network of a source RAT (e.g., LTE) that may not support voice service. The UE may originate a voice call with this wireless network and may be transferred through higher-layer signaling to another wireless network of a target RAT that can support the voice call. The higher-layer signaling to transfer the UE to the target RAT may be for various procedures, e.g., connection release with redirection, PS handover, etc.

Single radio voice call continuity (SRVCC) provides the ability to transition a voice call from a packet domain (e.g., voice over internet protocol (VoIP) or IP multimedia subsystem (IMS)) to the legacy circuit domain. Variations of SRVCC may support Global System for Mobile Communications (GSM)/Universal Mobile Telecommunications System (UMTS) and CDMA 1× circuit domains. For an operator with a legacy cellular network who wishes to deploy internet protocol (IP) multimedia subsystem (IMS) and voice over IP (VoIP)-based voice services in conjunction with the rollout of a long term evolution (LTE) network, SRVCC may offer VoIP subscribers with coverage over a much larger area than would typically be available during the rollout of a new network. As described in greater detail below, in some embodiments, a network entity such as a core network entity and/or a base station may implement the functionality described herein for improving user experience of a voice call associated with a device, such as a SRVCC device. For example, a base station may detect failures during mobile originated calls from a UE and may transition (e.g., redirect) the UE to another system in an effort to improve user experience.

As described in greater detail below, in some embodiments, the UEs110may implement the functionality described herein for improving user experience of a voice call associated with a device, such as a SRVCC device. For example, the UE may maintain timers, counts, and/or thresholds for use in silent redial. UE110may also detect a failure during mobile originated call, determine how to attempt retrying the call, select a subsequent system for attempting the call, and attempt to retry the call as described herein.

FIG. 2shows simplified block diagrams of UE110, eNB122, and MME126ofFIG. 1. In general, each entity may include any number of transmitters, receivers, processors, controllers, memories, communication units, etc. Other network entities may also be implemented in similar manner.

At UE110, an encoder212may receive traffic data and signaling messages to be sent on the uplink. Encoder212may process (e.g., format, encode, and interleave) the traffic data and signaling messages. A modulator (Mod)214may further process (e.g., symbol map and modulate) the encoded traffic data and signaling messages and provide output samples. A transmitter (TMTR)222may condition (e.g., convert to analog, filter, amplify, and frequency upconvert) the output samples and generate an uplink signal, which may be transmitted via an antenna224to eNB122.

On the downlink, antenna224may receive downlink signals transmitted by eNB122and/or other eNBs/base stations. A receiver (RCVR)226may condition (e.g., filter, amplify, frequency downconvert, and digitize) the received signal from antenna224and provide input samples. A demodulator (Demod)216may process (e.g., demodulate) the input samples and provide symbol estimates. A decoder218may process (e.g., deinterleave and decode) the symbol estimates and provide decoded data and signaling messages sent to UE110. Encoder212, modulator214, demodulator216, and decoder218may be implemented by a modem processor210. These units may perform processing in accordance with the RAT (e.g., LTE, 1×RTT, etc.) used by the wireless network with which UE110is in communication.

A controller/processor230may direct the operation at UE110. Controller/processor230may also perform or direct other processes for the techniques described herein. Controller/processor230may also perform or direct the processing by UE. Memory232may store program codes and data for UE110. Memory232may also store a priority list and configuration information.

At eNB122, a transmitter/receiver (TMTR/RCVR)238may support radio communication with UE110and other UEs. A controller/processor240may perform various functions for communication with the UEs. On the uplink, the uplink signal from UE110may be received via an antenna236, conditioned by receiver238, and further processed by controller/processor240to recover the traffic data and signaling messages sent by UE110. On the downlink, traffic data and signaling messages may be processed by controller/processor240and conditioned by transmitter238to generate a downlink signal, which may be transmitted via antenna236to UE110and other UEs. Controller/processor240may also perform or direct other processes for the techniques described herein. Controller/processor240may also perform or direct the processing by eNB122. Memory242may store program codes and data for the base station. A communication (Comm) unit244may support communication with MME126and/or other network entities.

At MME126, a controller/processor250may perform various functions to support communication services for UEs. Controller/processor250may also perform or direct the processing by MME126inFIGS. 3 and 4. Memory252may store program codes and data for MME126. A communication unit254may support communication with other network entities.

FIG. 3illustrates an example call flow300for circuit-switched (CSFB) when a UE (e.g., UE110), which may support EUTRAN/UTRAN/GERAN protocols, makes a mobile-originated (MO) call, in accordance with certain aspects of the present disclosure. While the UE110is camped on a long-term evolution (LTE) network102that may not support voice services, the UE110may fall back to a 1× network connected to the mobile switching center (MSC)134in order to make the MO call. As shown, the call setup procedure may begin at302where the UE110may initiate a non-access stratum (NAS) extended service request (ESR). At304, the UE may receive CS radio access technology (RAT) candidates from a measurement report. At306, the LTE network102may assist the UE110in the mobility procedure in a network assisted cell change (NACC). For example, if an interface between the MSC134and the mobility management entity (MME)126is down, the LTE network102may inform the UE110to retry the call setup after a set period. At308, the UE may receive a mobility command from the LTE network102indicating the target RAT/band/channel the UE110may need to tune to in order to find CS services and in order to continue with the call setup procedure.

FIG. 4illustrates an example call flow400of CSFB when a UE110receives a mobile-terminated (MT) call, according to certain aspects of the present disclosure. Operations may be similar to those described inFIG. 3, however, the UE110may initiate the call setup procedure after receiving a 1× page at402(CS SERVICE NOTIFICATION). The MSC134may deliver the 1× page to the UE110(e.g., forward the page through SGs interface to MME126). The 1× page may comprise caller line identification information.

Example Methods and Apparatus to Improve Network Coverage Using Rate Adaptation

Aspects of the present disclosure provide a mechanism for a media receiver (e.g., a first UE) to signal, to a network entity, its capability to support rate adaptation during a media session with a media sender (e.g., second UE). Such a capability may allow the media receiver to request the media sender change its encoder to a more robust mode when it detects packet losses. As used herein, the relative term “more robust” when applied to a codec generally refers to a codec that is capable of tolerating a higher packet loss rate (PLR) than a current codec. Thus, switching to a more robust codec may allow a UE to tolerate a higher PLR. Given this information, the network entity may adjust handover thresholds accordingly, helping avoid premature handover and the corresponding overhead, delay, and possible degradation of quality of the media session.

While the techniques presented herein are described with reference to voice over IP (VoIP) sessions, the techniques are broadly applicable to any type of media sessions where a media receiver (e.g. a UE) is capable of requesting a media sender to change codec configurations (e.g., in response to detecting a PLR above a threshold). By signaling the ability to adapt rates in this manner to a network entity, the network entity may be able to appropriately set handover thresholds to avoid unnecessary (premature) handovers. As used herein, the term codec configuration generally refers to different configurations involving a same codec type or different codec types, such as adaptive multi-rate (AMR) and enhanced voice service (EVS) channel aware mode.

The thresholds set based on the UE capability for rate adaptation may be used to trigger different types of handovers. These may include handovers between different types of radio access networks (RANs), such as from a packet-switched RAN to a circuit-switched RAN, or handovers between base stations within a same type of RAN.

As noted above, aspects of the present disclosure may allow a network entity to determine a MaxPLR supported by a VOIP terminal and/or adjust one or more handover thresholds based on the MaxPLR supported by a VOIP terminal that employs, for example, application layer redundancy and/or the rate adaptability.

By repeating uplink transmission of voice frames (e.g., in different VoIP packets), such redundancy schemes may increase reliability of uplink transmissions from UEs in low or poor coverage areas (e.g., such as a cell edge), allowing the UE to effectively tolerate higher PLRs.

An eNB (or other network entity) may update (e.g., increase) handover thresholds for UEs that employ application layer redundancy and, as a result, can tolerate higher MaxPLRs. By increasing handover thresholds, an eNB may not be as quick to handover a UE from a packet switched (PS) radio access network (RAN) to a circuit switched (CS) RAN. In some cases, this may be desirable, particularly for operators that are motivated to keep UEs on the PS RAN (e.g., as they try and phase out support of CS RANs).

Aspects of the present disclosure provide techniques for allowing a UE to provide signaling of information that allows a network entity (e.g., a core network entity or an eNB) to determine a MaxPLR, accounting for application layer redundancy. As will be described in greater detail below, the UE may explicitly signal its MaxPLR or may signal information (e.g., codec and redundancy or ability for rate adaptation) allowing the network entity to determine the MaxPLR itself. The signaling may be direct to the eNB (e.g., via RRC signaling) or indirect (e.g., via SIP signaling).

FIG. 5illustrates an example voice over IP (VOIP) scenario involving two UEs (UE A and UE B), in which aspects of the present disclosure may be practiced.

For example, aspects of the present disclosure may help eNBs (e.g., eNB A and/or eNB B) or other network entities set the one or more handover thresholds. These thresholds may be set in an effort to ensure that the end-to-end error rate across the transport path between UE A and UE B does not exceed a maximum PLR based on current codes, accounting for advanced techniques, such as application layer redundancy. Accounting for an increase in MaxPLR may help avoid unnecessarily handing over the UEs from a packet switched network to a circuit switched network.

FIG. 6illustrates example operations600for wireless communications by a UE (e.g., a VoIP terminal), according to aspects of the present disclosure. For example, operations600may be performed by UE A and/or UE B ofFIG. 5.

The operations600begin, at602, by signaling information (explicitly or implicitly) indicating capability of the UE to handle at least one target packet loss rate (PLR), the signaling designed to allow a network entity to determine one or more thresholds for handover of the UE from a packet switched (PS) radio access network (RAN) to a circuit switched (CS) radio access network (RAN).

At604, the UE employs application layer redundancy to transmit a plurality of voice over IP packets. In aspects, operations600further comprise receiving signaling, while the UE is participating in a voice call over the PS RAN, for the UE to handover from the PS RAN to the CS RAN based on the determined thresholds.

According to certain aspects, the signaling is provided via radio resource control (RRC) signaling. According to certain aspects, the signaling is provided via Session Initiation Protocol (SIP) signaling. According to certain aspects, the information comprises an indication of a maximum PLR. In such aspects, operations600may further comprise determining the maximum PLR based on the employed application layer redundancy. The information may comprise an indication of an amount of redundancy supported by the UE for each of one or more codecs.

FIG. 7illustrates example operations700for wireless communications by a network entity (e.g., an eNB or a core network entity), according to aspects of the present disclosure. For example, operations700may be performed by eNB A and/or eNB B ofFIG. 5.

The operations700begin, at702, by receiving signaling of information indicating capability of a UE to handle at least one target packet loss rate (PLR). At704, the eNB determines, based on the information, a maximum PLR associated with the UE.

Based on the maximum PLR, the network entity (e.g., an eNB) may determine one or more thresholds for handover of the UE from a packet switched (PS) radio access network (RAN) to a circuit switched (CS) radio access network (RAN). The network entity may decide, while the UE is participating in a voice call over the PS RAN, whether to cause handover of the UE from the PS RAN to the CS RAN based on the determined thresholds.

According to certain aspects, the information comprises an indication of an amount of redundancy supported by the UE for each of one or more codecs. In such aspects, the operations700further comprise determining a maximum PLR for each indication of redundancy supported by the UE for each of one or more codecs. Operations700may further comprise transmitting (e.g., by a core network entity) the determined maximum PLR to another network entity (e.g., an eNB).

As noted above, in some cases, a VoLTE terminal may explicitly signal its MaxPLR. For example, based on a current codec and application layer redundancy scheme, the VoLTE terminal may determine the MaxPLR it can support. A possible advantage of this approach is that it does not require any calculations by the RAN or core network, although it does not allow the operator direct control over the kind of voice quality it wants to achieve. In other words, the operator may not be able to select the MaxPLR for a particular codec to guarantee a target voice quality.

As noted above, the explicit signaling of the MaxPLR may be done in at least two ways. For example, the VoLTE terminal may use RAN-level signaling (RRC) to send the information directly to the eNB. One advantage of this approach is that it is directly communicated to the eNB and there is no impact to the core network.

As an alternative, or in addition, the VoLTE terminal may use Session Initiation Protocol (SIP) signaling to send the information to the core network which then communicates this to the eNB. In this case, the information (e.g., MaxPLR) may be sent as a Session Description Protocol (SDP) parameter or with SDP parameters.

For example, the VoLTE terminal may send the MaxPLR to a core network entity, such as a call session control function (CSCF). The CSCF may, in turn, communicate this information to another core network entity such as ae Policy and Charging Rules Function (PCRF), which may communicate the MaxPLR to the eNB (serving the VoLTE terminal). One advantage of this approach is that there may be little or no impact to the RAN (e.g., RRC) signaling between the VoLTE terminal and the eNB. It also gives the operator some control over the MaxPLR communicated to the eNB, as the operator may change the MaxPLR value when it passes through the PCRF.

In some cases, rather than receiving explicit signaling of the MaxPLR, a network entity may derive the MaxPLR based on information (e.g., codec information) from the VoLTE terminal. For example, the VoLTE terminal may provide information to the core network that allows the core network to determine, compute and/or derive the MaxPLR that the VoLTE terminal can tolerate.

This information may include the codec modes (codec configurations which may involve one or more codec types), whether application layer redundancy can be used, and/or whether the terminals can autonomously adapt to more robust configurations when experiencing higher packet loss rates. For example, the information can indicate how much application layer redundancy (e.g., 100%, 200%, 300%, etc.) can be applied for each particular codec mode, such as:AMR 5.9 200% max-redAMR 12.2 0% max-redAMR 7.2 100% max-red
As described above, for example, due to bandwidth constraints, the terminal may support up to 200% redundancy for the adaptive multi-rate (AMR) 5.9 kbps codec mode, but only up to 100% redundancy for the AMR 7.2 kbps codec mode. In some cases, the UE may provide an indication that the UE is able to adapt between particular codec modes and redundancy levels.

As will be, such information (as the ability to adapt codec modes) may be communicated via SIP in the form of SDP parameters that are sent to the CSCF. The CSCF then sends the relevant information to the PCRF which then determines the MaxPLR based on all the information received. The PCRF then communicates the MaxPLR to the eNB. The information can also be communicated directly to the eNB via RAN-level (RRC) signaling. The eNB then derives the MaxPLR based on all the information it receives.

FIG. 8illustrates an example scenario in which a UE (UE B) signals the ability for rate adaptation via a parameter that may be referred to as an “adapt” parameter. As illustrated, the adapt parameter may be signaled via an SDP message (e.g., an Offer or Answer) sent, for example, when establishing a multimedia session to help each of the parties understand each other in terms of the various multimedia capabilities.

The adapt parameter may allow the network (e.g., via a PCRF and/or CSCF) to confirm a UE will be able to adapt to a more robust codec, for example, to the most robust codec mode negotiated for a media session and to take this into consideration when setting handover thresholds to indicate to the eNB currently serving the UE. In some cases, a network entity may use the presence of the “adapt” parameter (a receiver rate codec configuration or rrcc parameter) in the SDP message to determine what Max PLR to indicate to its eNB as follows.

For example, as illustrated inFIG. 8, if PCRF B detects the adapt parameter (rrcc) is sent from a client (UE B) served by its local eNB (eNB B), then the PCRF can indicate the Max PLR for the most robust codec mode negotiated in the downlink direction to the eNB (eNB B) for its downlink. Similarly, if the PCRF A detects the adapt parameter is sent from the far-end client (UE B in this example), then PCRF A can indicate the Max PLR for the most robust codec mode negotiated in the uplink direction to the eNB (eNB A) for its uplink (in the direction from UE A to UE B).

On the other hand, as illustrated inFIG. 9, if the adapt parameter is not detected, PCRF B may indicate the Max PLR for the least robust codec mode negotiated in the downlink direction to eNB B for its downlink (to be safe since UE B has not indicated the ability to stich codec modes). Similarly, if the PCRF A detects the adapt parameter is not sent from the far-end client (UE B in this example), then PCRF A can indicate the Max PLR for the least robust codec mode negotiated in the uplink direction to the eNB (eNB A) for its uplink (in the direction from UE A to UE B).

As noted above, the techniques presented herein are broadly applicable to any type of media sessions where a media receiver (e.g. a UE) is capable of requesting a media sender to change codec configurations. By signaling the ability to adapt rates in this manner to a network entity, the network entity may be able to appropriately set handover thresholds to avoid premature handovers.

FIG. 10illustrates example operations1000for wireless communications by a first UE, in accordance with certain aspects of the present disclosure. For example, operations1000may performed by UE B (and/or UE A) ofFIG. 8to signal PCRF B (and/or PCRF A). For example, operations1000may be performed by the UE ofFIG. 2(and/or by one or more of the UE processors thereof).

Operations1000begin, at1002, by signaling, to a network entity, a parameter indicating capability of the first UE to request, during a media session with a second UE, that the second UE switch from a first codec configuration to a second codec configuration. At1004, the first UE detects a packet loss rate (PLR) above a threshold value, while participating in the media session with the second UE using the first codec configuration. At1006, the first UE requests, in response to detecting the PLR above the threshold value, that the second UE switch to the second codec configuration.

FIG. 11illustrates example operations1100for wireless communications by a network entity, in accordance with certain aspects of the present disclosure. For example, operations1100may performed by PCRF B (and/or PCRF A) ofFIG. 8to process signaling of a rate adapt parameter signaled by UE B (and/or UE A) performing operations1000ofFIG. 10. For example, operations1100may be performed by one or more of the eNB or the MME ofFIG. 2(or by one of the processors thereof).

Operations1100begin, at1102, by receiving signaling of a parameter indicating capability of a first user equipment (UE) to request, during a media session with a second UE, that the second UE switch from a first codec configuration to a second codec configuration. At1104, the network entity determines one or more thresholds for handover of the UE, based on the parameter.

As noted above, the adapt parameter may be used to indicate the ability to request a switch between different codec configurations involving a same codec type or different codec types, such as adaptive multi-rate (AMR) and enhanced voice service (EVS) channel aware mode. A network entity may set handover thresholds (used to trigger different types of handovers) based on the indicated adapt parameter.

As described herein, an SDP signaled adapt parameter (rrcc) may indicate that a media receiver (e.g., UE B inFIG. 8) has the ability to request a more robust codec (e.g., up to the most robust codec configuration supported by the UE) when it detects high packet loss. As noted above, the most robust codec configuration can include a robust codec mode, use of application layer partial and full redundancy, use of transport or application layer error correction, or any combination of these mechanisms.

In some cases, the rate adapt parameter (rrcc) may be generic as to media type. In other words, the adapt parameter may indicate that when a client receiving media detects packet losses higher than that tolerable by a current codec configuration in use, the client supports sending a request to the media sender to use a more robust codec configuration, regardless of the media type involved in the session (e.g., whether video, voice, some other audio, or text).

In other cases, however, the rate adaptation parameter may be media-specific. In such cases, if supported for one codec type, the indicated parameter may apply for all codecs of that same media type negotiated in a session. In other words, the adapt parameter may be defined to only indicate robustness requests within a certain RTP payload type (codec) and may not be expected to make requests across codec types of the same media.

Signaling a media specific adapt parameter may make sense, for example, if the UE supports request for more robust configurations for a particular codec type (e.g., AMR-WB) where it is reasonable to expect that the UE can make similar adaptations for any other codec of the same media type (e.g. EVS). In such cases, there may not be a need to enable adaptation requests across different codec types of the same media type.

In certain scenarios however, multiple codec types may be negotiated for receiving media, for example, for sessions where the codec type may switch depending on the capabilities of the active media sender for a conference involving users with different capabilities. In such cases, it may be beneficial for the media receiver to be able to attempt to switch the codec type as determined by the capabilities of a media sender involved in the conference.

Dynamically switching codec types in an active session, however, presents challenges and may cause disruptions in the media quality in some cases, due to processing overhead involved to support the different codecs. In other words, supporting a seamless transition may be challenging to implement.

In certain scenarios, such as Multi-party Multi-stream Conferencing Media Handling (MMCMH) sessions, multiple codec types may be negotiated for a single media type. In such cases, the PCRF/PCC may not be able to rely on the UEs to adapt to the most robust mode among all those negotiated. In such cases, the PCRF/PCC may need to rely on the PLR of the least robust among the most robust mode of each codec type negotiated (e.g., the MIN [MAX (codec type 1), MAX (codec type 2), MAX (codec type 3) . . . ]).

In some cases, an in-band codec mode request (CMR) may be directed to a particular payload type by relying on the payload type of the media sent in the direction of the CMR. For other requests, a different mechanism may be used to distinguish which codec type the robustness request is being made.

In some cases, the SDP adapt parameter may be defined in a manner that allows different media receivers participating in media session to independently indicate their capability to adapt to the most robust configuration. In other words, this approach may allow for asymmetric support for adaptation. This may allow for different thresholds to be set independently in each direction of media transmission.

In some cases, an adapt parameter may be defined to indicate whether a media sender can dynamically change between codecs (encoders) when requested by the media receiver (e.g., a “Media sender encoder switch”). In such cases, if multiple codecs are negotiated and the PCRF sees that codec switching is not supported by a terminal, then the PCRF may take this into account. For example, if the PCRF does not know which codec will be in use, it may have to use a MaxPLR of the codec whose most robust configuration is the least “robust” among all the negotiated codecs. In some cases, multiple codecs may not be supported in an SDP Answer, in which case an indicated parameter may apply to a specific codec type.

For example, means for transmitting may comprise a transmitter222and/or an antenna(s)224of the UE110or far-end user511and a transceiver238or antenna(s)236of eNB122. Means for receiving may comprise a receiver226and/or an antenna(s)224of the UE110or far-end user511and transceiver238and/or antenna(s)236of eNB122. Means for determining, means for refraining, means for postponing, means for processing, means for detecting, and/or means for initiating may comprise a processing system, which may include one or more processors, such as modem processor210of the UE110or controller/processor240of eNB122, for example.

According to certain aspects, such means may be implemented by processing systems configured to perform the corresponding functions by implementing various algorithms (e.g., in hardware or by executing software instructions). For example, various operations shown inFIGS. 6 and 10may be performed by one or more of processors210or230ofFIG. 2, while operations shown inFIGS. 7 and 11may be performed by one or more processors of a network entity, such as processors240or250shown inFIG. 2.

The various algorithms may implemented by a computer-readable medium that may be a non-transitory computer-readable medium. The computer-readable medium may have computer executable instructions (e.g., code) stored thereon. For example, the instructions may be executed by a processor or processing, such as modem processor210of the UE110or processor240of eNB122, and stored in a memory, such as memory232of the UE110or memory242of eNB122. For example, the computer-readable medium may have computer executable instructions stored thereon for receiving one or more session initiation protocol (SIP) requests, from one or more other UEs, to establish a call with the UE, instructions for postponing processing of the one or more SIP requests until detection that a predetermined amount of time has passed without receiving a SIP request, and instructions for processing the one or more SIP requests in response to the detection.