WO2018226318A1 - Methods for increasing voip network coverage - Google Patents

Methods for increasing voip network coverage Download PDF

Info

Publication number
WO2018226318A1
WO2018226318A1 PCT/US2018/028333 US2018028333W WO2018226318A1 WO 2018226318 A1 WO2018226318 A1 WO 2018226318A1 US 2018028333 W US2018028333 W US 2018028333W WO 2018226318 A1 WO2018226318 A1 WO 2018226318A1
Authority
WO
WIPO (PCT)
Prior art keywords
plr
uplink
downlink
tolerate
base station
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2018/028333
Other languages
English (en)
French (fr)
Inventor
Vivek Rajendran
Nikolai Konrad Leung
Min Wang
Venkatraman ATTI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Priority to BR112019025454-4A priority Critical patent/BR112019025454B1/pt
Priority to CN201880036888.0A priority patent/CN110710182B/zh
Priority to ES18723171T priority patent/ES2882194T3/es
Priority to KR1020197035840A priority patent/KR102616336B1/ko
Priority to EP18723171.7A priority patent/EP3635931B1/en
Priority to JP2019566776A priority patent/JP7084431B2/ja
Publication of WO2018226318A1 publication Critical patent/WO2018226318A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H04W36/00224—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H04M7/0072—Speech codec negotiation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H04W36/00224—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
    • H04W36/00226—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB] wherein the core network technologies comprise IP multimedia system [IMS], e.g. single radio voice call continuity [SRVCC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
    • H04W36/0085—Hand-off measurements
    • H04W36/0094—Definition of hand-off measurement parameters

Definitions

  • VoIP Voice- over-Internet Protocol
  • Wireless communication systems have developed through various generations, including a first-generation analog wireless phone service (1G), a second-generation (2G) digital wireless phone service (including interim 2.5G and 2.75G networks) and third-generation (3G) and fourth-generation (4G) high-speed data and Internet-capable wireless services.
  • 1G first-generation analog wireless phone service
  • 2G second-generation digital wireless phone service
  • 3G third-generation
  • 4G fourth-generation
  • wireless communication systems in use including Cellular and Personal Communications Service (PCS) systems.
  • Exemplary cellular systems include the cellular Analog Advanced Mobile Phone System (AMPS), digital cellular systems based on Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), the Global System for Mobile access (GSM) variation of TDMA, and newer hybrid digital communication systems using both TDMA and CDMA technologies.
  • AMPS cellular Analog Advanced Mobile Phone System
  • CDMA Code Division Multiple Access
  • FDMA Frequency Division Multiple Access
  • TDMA Time Division Multiple
  • LTE Long Term Evolution
  • GSM Global System for Mobile communications
  • EDGE Enhanced Data rates for GSM Evolution
  • UMTS Universal Mobile Telecommunications System
  • HSPA High-Speed Packet Access
  • the fifth generation (5G) mobile standard is currently being formulated and calls for higher data transfer speeds, greater numbers of connections, and better coverage, among other improvements.
  • the 5G standard according to the Next Generation Mobile Networks Alliance, is expected to provide data rates of several tens of megabits per second to each of tens of thousands of users, with one gigabit per second to tens of workers on an office floor.
  • Several hundreds of thousands of simultaneous connections should be supported in order to support large sensor deployments. Consequently, the spectral efficiency of 5G mobile communications should be significantly enhanced compared to the current 4G standard.
  • signaling efficiencies should be enhanced and latency should be substantially reduced compared to current standards.
  • the disclosure generally relates to various methods to increase network coverage with respect to Voice-over-Internet Protocol (VoIP) sessions and/or other voice-based multimedia services.
  • VoIP Voice-over-Internet Protocol
  • two or more terminals may perform a codec negotiation to exchange information related to supported multimedia codecs and/or codec modes, jitter buffer management (JBM), and packet loss concealment (PLC) capabilities.
  • JBM jitter buffer management
  • PLC packet loss concealment
  • a message may be sent to a base station to indicate the maximum packet loss rate (PLR) for each terminal. Additional techniques may ensure that the terminals use the most robust codecs or codec modes that are available when nearing the edge of coverage to help avoid unnecessary and/or excessive handovers.
  • a method for increasing network coverage for a VoIP session between a first user equipment (UE) and a second UE may comprise negotiating, between the first UE and the second UE, a codec configuration to use in the VoIP session between the first UE and the second UE, determining, at the first UE, maximum end-to-end PLRs that the first UE and the second UE can tolerate for received media based at least in part on the negotiated codec configuration, determining, at the first UE, a distribution of the maximum end-to-end PLRs among respective uplinks and downlinks at the first UE and the second UE, and transmitting, by the first UE to a serving base station, a message to request an uplink PLR for media transmitted in a direction from the first UE to the second UE and a downlink PLR for media transmitted in a direction from the second UE to the first UE according to the determined distribution.
  • the maximum end-to- end PLRs may be further based on respective PLC and JBM implementations in use at the first UE and the second UE.
  • determining the maximum end-to-end PLRs that the first UE and the second UE can tolerate for received media may comprise transmitting, by the first UE to the second UE, the maximum end-to-end PLR that the first UE can tolerate for received media given the negotiated codec configuration and receiving, at the first UE from the second UE, the maximum end-to-end PLR that the second UE can tolerate for received media given the negotiated codec configuration.
  • the serving base station may be configured to establish a handover threshold for the VoIP session (e.g., a Single Radio Voice Call Continuity (SRVCC) threshold) based at least in part on the requested uplink PLR and the requested downlink PLR.
  • a handover threshold for the VoIP session e.g., a Single Radio Voice Call Continuity (SRVCC) threshold
  • another method for increasing network coverage for a VoIP session between a first UE and a second UE may comprise monitoring, by a network element serving the first UE, a codec configuration negotiation between the first UE and the second UE, wherein the codec configuration negotiation includes an exchange of maximum end-to-end PLRs that the first UE and the second UE can tolerate for received media based at least in part on the negotiated codec configuration, wherein the maximum end-to-end PLRs may be further based on respective PLC and JBM implementations in use at the first UE and the second UE, determining, by the network element, an agreed-upon distribution of the maximum end-to-end PLRs among respective uplinks and downlinks at the first UE and the second UE, and transmitting, by the network element to a base station serving the first UE, a message to request an uplink PLR for media transmitted in a direction from the first UE to the second UE and a downlink PLR for media transmitted in a direction from the
  • the base station serving the first UE may therefore be configured to establish a handover threshold for the VoIP session (e.g., a Single Radio Voice Call Continuity (SRVCC) threshold) based at least in part on the requested uplink PLR and the requested downlink PLR.
  • a handover threshold for the VoIP session e.g., a Single Radio Voice Call Continuity (SRVCC) threshold
  • the distribution of the maximum end-to-end PLRs among the respective uplinks and downlinks may comprise an agreed-upon ratio (R) representing an uplink PLR-to-downlink PLR ratio.
  • R agreed-upon ratio
  • the uplink PLR and the downlink PLR to request from the serving base station may be calculated (e.g., by the requesting UE or the requesting network element) according to the agreed-upon ratio (R) such that the requested uplink PLR is equal to the maximum end-to-end PLR that the second UE can tolerate for received media multiplied by R/(R+1), and such that the requested downlink PLR is equal to the maximum end-to-end PLR that the first UE can tolerate for received media multiplied by 1/(R+1).
  • the first UE and the second UE may be configured to determine the distribution of the maximum end-to-end PLRs among the respective uplinks and downlinks via Session Description Protocol (SDP) such that the uplink PLR requested from the serving base station is less than or equal to a difference between the maximum end-to-end PLR that the second UE can tolerate for received media and a downlink PLR that the second UE requests from a serving base station associated therewith, and such that the downlink PLR requested from the serving base station is less than or equal to a difference between the maximum end-to-end PLR that the first UE can tolerate for received media and an uplink PLR that the second UE requests from the serving base station associated therewith.
  • SDP Session Description Protocol
  • the network element may negotiate the agreed- upon distribution of the maximum end-to-end PLRs among the respective uplinks and downlinks with a network element serving the second UE via Session Description Protocol (SDP), which may comprise receiving, at the network element, an SDP offer transmitted by the first UE that indicates the maximum end-to-end PLR that the first UE can tolerate for received media, determining, at the network element based on operator policy, a proportion of the maximum end-to-end PLR that the first UE can tolerate for received media to allocate to the downlink to the first UE from the base station serving the first UE, determining, at the network element based on the operator policy, a preferred PLR for the uplink from the first UE to the base station serving the first UE, modifying, by the network element, the SDP offer to indicate the determined proportion to allocate to the downlink to the first UE and the preferred PLR for the uplink from the first UE, and transmitting, by the network element, the modified SDP offer to
  • SDP Session Description
  • the network element may then receive an SDP answer that includes a proposed uplink PLR for the second UE from the network element serving the second UE and accept or reject the SDP answer depending on whether the proposed uplink PLR for the second UE is less than or equal to a difference between the maximum end-to-end PLR that the first UE can tolerate for received media and the proportion of the maximum end-to-end PLR allocated to the downlink to the first UE.
  • FIG. 1 illustrates a high-level system architecture of a wireless communications system that may support voice-based multimedia services, according to various aspects.
  • FIG. 2 illustrates an exemplary wireless network architecture that may support voice-based multimedia services, according to various aspects.
  • FIG. 3 illustrates an exemplary end-to-end communication flow between two terminals engaged in a voice-based multimedia session, according to various aspects.
  • FIGs. 4A-4C illustrate exemplary communication flows that can be used to provide a base station with suitable information to establish an appropriate handover threshold based on tolerable packet loss at a terminal, according to various aspects.
  • FIG. 5 illustrates an exemplary communication flow that can be used to ensure that terminals engaged in a voice session will use more robust multimedia codecs or codec modes upon reaching a coverage edge, according to various aspects.
  • FIG. 6 illustrates exemplary user equipment (UE) configurations that may be used in accordance with the various aspects and embodiments described herein.
  • UE user equipment
  • FIG. 7 illustrates an exemplary access point that may be used in accordance with the various aspects and embodiments described herein.
  • FIG. 8 illustrates an exemplary communications device having various structural components that can be configured to be used in accordance with the various aspects and embodiments described herein.
  • FIG. 9 illustrates an exemplary server that may be configured in accordance with the various aspects and embodiments described herein.
  • a CDMA system may implement a radio technology 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.
  • a TDMA system may implement a radio technology such as Global System for Mobile Communications (GSM).
  • GSM Global System for Mobile Communications
  • An OFDMA system may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMTM, etc.
  • E-UTRA Evolved UTRA
  • UMB Ultra Mobile Broadband
  • IEEE 802.11 Wi-Fi
  • WiMAX IEEE 802.16
  • Flash-OFDMTM Flash-OFDMTM
  • UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS).
  • 3GPP Long Term Evolution (LTE) is a release of UMTS that uses E-UTRA, which employs OFDMA on the downlink and SC-FDMA on the uplink UTRA, E-UTRA, UMTS, LTE, and GSM are described in documents from the "3rd Generation Partnership Project" (3GPP).
  • CDMA2000 and UMB are described in documents from an organization named "3rd Generation Partnership Project 2" (3GPP2).
  • the terms “user device,” “user equipment” (or “UE"), “user terminal,” “client device,” “communication device,” “wireless device,” “wireless communications device,” “handheld device,” “mobile device,” “mobile terminal,” “mobile station,” “handset,” “access terminal,” “subscriber device,” “subscriber terminal,” “subscriber station,” “terminal,” and variants thereof may interchangeably refer to any suitable mobile or stationary device.
  • the above-mentioned terms may suitably refer to any one or all of cellular telephones, smart phones, personal or mobile multimedia players, personal data assistants, laptop computers, personal computers, tablet computers, smart books, palm-top computers, wireless electronic mail receivers, multimedia Internet-enabled cellular telephones, wireless gaming controllers, and similar devices with a programmable processor, memory, and circuitry to connect to and communicate over a radio access network (RAN) that implements a particular radio access technology (RAT), over a wired network, over a wireless local area network (WLAN) (e.g., based on IEEE 802.11, etc.), and/or with other devices via a direct device-to-device (D2D) or peer-to-peer (P2P) connection.
  • RAN radio access network
  • RAT radio access technology
  • WLAN wireless local area network
  • D2D direct device-to-device
  • P2P peer-to-peer
  • a communication link through which one or more
  • UEs can send signals to the RAN, the wired network, the WLAN, etc. is called an uplink or reverse link channel (e.g., a reverse traffic channel, a reverse control channel, an access channel, etc.), while a communication link through which the RAN, the wired network, the WLAN, etc. can send signals to UEs is called a downlink or forward link channel (e.g., a paging channel, a control channel, a broadcast channel, a forward traffic channel, etc.).
  • a traffic channel can refer to either an uplink / reverse link channel or a downlink / forward link channel.
  • FIG. 1 illustrates a high-level system architecture of a wireless communications system 100 that may support voice-based multimedia services.
  • the wireless communications system 100 may contain various UEs, including UE 102-1, UE 102-2, UE 102-3, UE 102-4, UE 102-5, 102-6, UE 102-N, collectively referred to herein as UEs 102-1..N.
  • the UEs 102-1..N can include cellular telephones, smart phones, personal or mobile multimedia players, personal data assistants, laptop computers, personal computers, tablet computers, and so on.
  • UE 102-1..6 are illustrated as cellular touchscreen phones or smart phones and UE 102-N is illustrated as a desktop computer.
  • the UEs 102-1..N may communicate with an access network
  • the air interfaces 104 and 106 can comply with a given cellular communications protocol (e.g., CDMA, EV-DO, eHRPD, GSM, EDGE, W-CDMA, LTE, etc.), while the air interface 108 can comply with a wireless local area network (WLAN) protocol (e.g., IEEE 802.11).
  • WLAN wireless local area network
  • the RAN 120 may include various access points that can serve UEs over air interfaces, such as the air interfaces 104 and 106.
  • Each access point in the RAN 120 can be referred to as an access node or AN, an access point or AP, a base station or BS, a Node B, an evolved Node B, an eNodeB or eNB, and so on. These access points can be terrestrial access points (or ground stations) or satellite access points.
  • the RAN 120 may be configured to connect to a core network 140 that can perform various functions, including bridging calls (e.g., voice calls) between UEs serviced via the RAN 120 and other UEs serviced via the RAN 120 or an altogether different RAN.
  • bridging calls e.g., voice calls
  • the RAN 120 may be configured to bridge circuit- switched (CS) calls between UEs serviced via the RAN 120 and other UEs serviced via the RAN 120 or an altogether different RAN.
  • the RAN 120 may also be configured to mediate an exchange of packet-switched (PS) data with external networks such as Internet 175.
  • the Internet 175 may generally include various routing agents and processing agents (not explicitly shown in FIG. 1 for sake of convenience).
  • UE 102-N is shown as connecting to the Internet 175 via the wired connection 109 (i.e., separate from the core network 140, such as over an Ethernet connection to an 802.11-based wireless local area network).
  • the Internet 175 can thereby bridge packet-switched data communications (including data associated with voice calls) between UE 102-N and UEs 102-1 to 102-6 via the core network 140. Also shown in FIG. 1 is the access point 125 separate from the RAN 120. The access point 125 may connect to the Internet 175 independent from the core network 140 (e.g., via an optical communication system, a cable modem, etc.). The air interface 108 may serve UE 102-5 or UE 102-6 over a local wireless connection, such as IEEE 802.11 in an example.
  • UE 102-N is shown as a desktop computer with the wired connection 109 to the Internet 175, such as a direct connection to a modem or router, which can correspond to the access point 125 itself in one example (e.g., a WLAN router with wired and/or wireless connectivity may correspond to the access point 125).
  • a modem or router which can correspond to the access point 125 itself in one example (e.g., a WLAN router with wired and/or wireless connectivity may correspond to the access point 125).
  • a server 170 is shown as connected to the Internet 175, the core network 140, or both.
  • the server 170 can be implemented as multiple structurally separate servers or alternately as a single server.
  • the server 170 may correspond to any suitable type of server, such as a web server (e.g., hosting a web page), an application download server, or an application server configured to support one or more communication services for UEs that can connect to the server 170 via the core network 140 and/or the Internet 175 (e.g., Voice-over-Internet Protocol (VoIP) sessions, Voice- over-LTE (VoLTE) sessions, Push-to-Talk (PTT) sessions, group communication sessions, sessions that involve Video-over-LTE (ViLTE) or other suitable video call services, Rich Communication Services (RCS), social networking services, etc.).
  • VoIP Voice-over-Internet Protocol
  • VoIP Voice-over-LTE
  • PTT Push-to-Talk
  • group communication sessions sessions that involve Video-over-LTE (ViLTE) or other suitable
  • UEs 102-1, 102-2, and 102-3 are depicted as part of a D2D network or D2D group 185, with UEs 102-1 and 102-3 being connected to the RAN 120 via the air interface 104.
  • UE 102-2 may also gain indirect access to the RAN 120 via mediation by UEs 102-1 and/or 102-3, whereby data 'hops' to/from UE 102-2 and one (or more) of UEs 102-1 and 102-3, which may communicate with the RAN 120 on behalf of UE 102-2.
  • one example protocol-specific implementation for the RAN 120 and the core network 140 is provided below with respect to FIG. 2 to help explain the wireless communications system 100 in more detail.
  • the components of the RAN 120 and the core network 140 may be described with reference to functions that relate to supporting packet-switched (PS) communications that can be used in a voice-based multimedia session.
  • PS packet-switched
  • CS legacy circuit-switched
  • FIG. 2 illustrates an exemplary wireless network architecture 200 that may support voice-based sessions between a first UE 202-1 and a second UE 202-2.
  • the wireless network architecture 200 may comprise a Long Term Evolution (LTE) (or Evolved Packet System (EPS)) network architecture 200.
  • LTE Long Term Evolution
  • EPS Evolved Packet System
  • the wireless network architecture 200 may include an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) 220, an Evolved Packet Core (EPC) 240, a Home Subscriber Server (HSS) 255, and Operator Internet Protocol (IP) Services 260 associated with an operator (e.g., a mobile network operator (MNO)).
  • E-UTRAN Evolved UMTS Terrestrial Radio Access Network
  • EPC Evolved Packet Core
  • HSS Home Subscriber Server
  • IP Services 260 associated with an operator (e.g., a mobile network operator (MNO)).
  • MNO mobile
  • the EPS network architecture 200 can interconnect with other access networks and core networks (not shown), such as a UMTS access network or an IP core network. As shown, the EPS network architecture 200 provides packet-switched services; however, those skilled in the art will readily appreciate that the various concepts disclosed herein may be extended to networks that provide circuit-switched services.
  • the E-UTRAN 220 may include a first eNode B (eNB)
  • the eNBs 222-1, 222-2 may provide user and control plane protocol terminations toward the UEs 202-1, 202-2 and may be connected to each other via a backhaul (e.g., an X2 interface).
  • the eNBs 222-1, 222-2 may also be referred to as base stations, Node Bs, access points, base transceiver stations, radio base stations, radio transceivers, transceiver functions, a basic service set (BSS), an extended service set (ESS), or some other suitable terminology.
  • the eNBs 222-1, 222-2 each provide an access point to the EPC 240 for the respective UEs 202-1, 202-2.
  • the eNBs 222-1, 222-2 may each connect to the EPC 240 via an Si interface, wherein the EPC 240 may include a Mobility Management Entity (MME) 242, other MMEs 244, a Serving Gateway 246, a Multimedia Broadcast Multicast Service (MBMS) Gateway 250, a Broadcast Multicast Service Center (BM-SC) 252, and a Packet Data Network (PDN) Gateway 248.
  • MME Mobility Management Entity
  • BM-SC Broadcast Multicast Service Center
  • PDN Packet Data Network Gateway 248.
  • the MME 242 is the control node that processes the signaling between the UEs 202-1, 202-2 and the EPC 240. Generally, the MME 242 provides bearer and connection management. All user IP packets are transferred through the Serving Gateway 246, which may be connected to the PDN Gateway 248.
  • the PDN Gateway 248 provides UE IP address allocation as well as other functions.
  • the PDN Gateway 248 is connected to the Operator IP Services 260, which may include the Intemet, an intranet, an IP Multimedia Subsystem (IMS), and a PS Streaming Service (PSS).
  • the BM-SC 252 may provide functions for MBMS user service provisioning and delivery.
  • the BM-SC 252 may serve as an entry point for content provider MBMS transmission, may be used to authorize and initiate MBMS Bearer Services within a PLMN, and may be used to schedule and deliver MBMS transmissions.
  • the MBMS Gateway 250 may be used to distribute MBMS traffic to the eNBs (e.g., 222-1, 222-2) belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service, and may be responsible for session management (start/stop) and for collecting eMBMS related charging information.
  • MMSFN Multicast Broadcast Single Frequency Network
  • a UE pair may establish a device-to-device (D2D) connection 204 to communicate directly without utilizing the respective eNBs 222-1, 222-2.
  • the UE pair 202-1, 202-2 may then transfer data traffic over the D2D connection 204.
  • one or more entities in the network infrastructure e.g., eNBs 222-1, 222-2, entities in the EPC 240, etc.
  • the UE pair 202-1, 202-2 may be configured establish the D2D connection 204 autonomously, wherein initial discovery and establishing the D2D connection 204 may be based on an ability to communicate signals directly therebetween.
  • terminals or UEs supporting multimedia (e.g., speech) services reach the edge of network coverage (e.g., the edge of a wireless wide area network (WW AN) such as an LTE network)
  • the network typically examines a handover threshold and decides whether to handoff the terminal to a different radio access technology based on measurement reports from the terminal.
  • WW AN wireless wide area network
  • LTE networks were initially deployed to support data services rather than voice-based services, LTE networks have evolved to increasingly support VoLTE and other voice-based services.
  • uplink coverage in certain networks tends to be limited or at least more limited than downlink coverage.
  • SRVCC Single Radio Voice Call Continuity
  • Adaptive Multi-Rate Wideband is similar to the AMR codec except that AMR-WB provides improved speech quality due to a wider speech bandwidth compared to the AMR audio codec.
  • Enhanced Voice Services as described in 3 GPP TS 26.441, offers greater robustness than AMR and AMR-WB and also offers a Channel-Aware mode that includes partial redundancy based packet loss concealment mechanisms resulting in improved quality/intelligibility relative to EVS non-channel-aware modes or AMR/ AMR-WB.
  • the various aspects and embodiments described herein generally contemplate a hierarchy in which the AMR audio codec is less robust than AMR-WB, which in turn is less robust than the EVS codec, while EVS Channel-Aware mode may be the most robust relative to AMR, AMR-WB, and EVS.
  • EVS Channel-Aware mode may be the most robust relative to AMR, AMR-WB, and EVS.
  • the other possible audio codecs may be included in the hierarchy, possibly also including future- developed audio codecs that offer greater robustness than EVS Channel-Aware mode.
  • the hierarchy in which EVS Channel-Aware mode is the most robust and AMR is the least robust is described herein for illustrative purposes only and is not intended to be limiting in any way.
  • PLC algorithms such as zero insertion, waveform substitutions, model-based methods, and so on generally mask the effects of packet loss in VoIP communications. This is because voice signals are sent over a network in packets that may travel different routes to a destination and consequently arrive late, corrupted, out- of-order, or not at all.
  • packets may arrive at a decoder out-of-order or with random jitters in arrival time
  • JBM implementations may use different techniques to absorb the jitter(s) in the packet arrival time so that a speech packet may beefed to the decoder at evenly spaced periodic intervals. Consequently, there are various factors that may influence the packet loss that each UE can tolerate to maintain a quality voice session.
  • One of the challenges in setting the appropriate handover threshold which is generally handled at a mobile infrastructure in a WW AN or other wireless network, (e.g., at the eNB in an LTE network), is therefore to ensure that the end-to-end (e2e) error rate across the transport path from the media sender to receiver does not exceed the maximum packet loss that the codec, PLC, and JBM can handle without resulting in a substantially degraded quality and/or intelligibility.
  • e2e end-to-end
  • voice transmissions in a direction from UE 302-2 to UE 302-1 are sent on an uplink 332 from UE 302-2 to a local eNB 322-2, which then forwards the transmissions to a local eNB 322-1 for the UE 302-1 over a backhaul link 334.
  • the local eNB 322-1 then sends the voice transmissions to the receiving UE 302-1 on a downlink 336.
  • voice transmissions from UE 302-1 to UE 302-2 are sent on an uplink 342 from UE 302-1 to the local eNB 322-1, which then forwards the transmissions to the local eNB 322-2 for the UE 302-2 over a backhaul link 344.
  • the local eNB 322-2 then sends the voice transmissions to the receiving UE 302-2 on a downlink 346.
  • PLR packet loss rate
  • the sum of the packet loss rate (PLR) on the uplink 342 and the downlink 346 has to be less than or equal to the maximum PLR for the codec in use during the voice session and the PLC algorithm(s) and JBM implementation(s) in use at UE 302-2.
  • the multimedia session negotiates the use of multiple codecs or codec modes with different robustness to packet losses.
  • the UEs 302-1, 302-2 can use any of the negotiated codecs or codec modes at any time and the infrastructure (e.g., eNBs 322-1, 322-2) does not explicitly know which codec is in use.
  • FIGs. 4A-4C illustrate exemplary communication flows that can be used to provide a base station (e.g., eNBs 322-1, 322-2) with suitable information to establish an appropriate handover threshold based on tolerable packet loss at a terminal (e.g., UEs 302-1, 302-2).
  • the appropriate handover threshold may be UE- specific because two UEs that are using the same multimedia codec may be able to tolerate different PLRs due to differences in the PLC algorithm(s) and/or JBM implementation(s) in use at the respective UEs.
  • the PLC algorithm(s) and JBM implementation(s) and performance are conventionally only known at the terminal receiving media, the PLC algorithm(s) and JBM implementation(s) need to be signaled to the network.
  • the information has to be shared with the two eNBs 322-1, 322-2 in the transport path to determine how to set the appropriate PLR targets.
  • FIG. 4A illustrates one possible solution to signal PLR requirements to the two eNBs 322-1, 322-2 in the transport path between the UEs 302- 1, 302-2 based on the codec in use as well as the PLC and JBM implementations in use. More particularly, at 432, the UEs 302-1, 302-2 may perform a codec negotiation, during which the UEs 302-1, 302-2 exchange information about their PLC and JBM capabilities.
  • the PLC capabilities may include one or more PLC algorithms such as zero insertion, waveform substitutions, model-based methods
  • the JBM capabilities may refer to a target underflow rate or other suitable JBM implementation used to counter jitter in a packet-switched network (e.g., the effective packet loss, jitter induced packet/delay loss statistics experienced over time, location, etc.).
  • the PLC and JBM capabilities could take the form of a total tolerable packet loss rate (PLR) that the respective UEs 302-1, 302-2 can tolerate for a given codec/mode and current PLC and JBM implementation.
  • PLR total tolerable packet loss rate
  • codec mode can be any operating point of a codec, which may include different bit rates (e.g., as per EVS or AMR-WB codec rates in TS 26.441), audio bandwidths (e.g., narrowband, wideband, super- wideband), speech/audio coding types, channel aware or non-channel aware mode, extended PLC post-processing techniques, etc.
  • the respective UEs 302-1, 302-2 can determine what maximum PLR to request of the respective local eNBs 322-1, 322-2.
  • the UEs 302-1, 302-2 can be specified, pre-configured, or dynamically configured (e.g., via Open Mobile Alliance Device Management (OMA-DM)) to divide the max end-to-end (e2e) PLR across the uplink and downlink according to an agreed-upon ratio.
  • OMA-DM Open Mobile Alliance Device Management
  • the max e2e PLR could be divided according to a 1 : 1 ratio, whereby the UEs 302-1, 302-2 may request that the eNBs 322-1, 322-2 each provide links to support PLRs that are half of the max e2e PLR.
  • the UEs 302-1, 302-2 can negotiate how to distribute the maximum tolerable end-to-end PLR according to a different ratio.
  • the UEs 302-1, 302-2 may negotiate a ratio that allows for more errors on an uplink than a downlink because LTE networks typically have more limited uplink coverage. As such, referring again to FIG.
  • UE 302-1 may request that eNB 322-1 support on the uplink 342 from UE 302-1 to eNB 322-1 a PLR equal to the maximum e2e PLR that UE 302-2 can tolerate multiplied by R/(R+1), and UE 302-1 may further request that eNB 322-1 support on the downlink 336 a PLR equal to the maximum e2e PLR that UE 302- 1 can tolerate multiplied by 1/(R+1).
  • UE 302-2 may request that eNB 322-2 support on the uplink 332 from UE 302-2 to eNB 322-2 a PLR equal to the maximum e2e PLR that UE 302-1 can tolerate multiplied by R/(R+1) and further request that eNB 322-2 support on the downlink 346 a PLR equal to the maximum e2e PLR that UE 302-2 can tolerate multiplied by 1/(R+1).
  • the UEs 302-1, 302-2 may engage in a negotiation (e.g., via Session Description Protocol (SDP)) to explicitly negotiate how to distribute the distribute the maximum tolerable end-to-end PLR.
  • SDP Session Description Protocol
  • UE 302-1 could request that eNB 322-1 provide a link to support a greater PLR relative to a link that UE 302-2 requests from eNB 322-2.
  • the UE 302-2 also signals the local eNB 322-2 to indicate that UE 302-2 only requires 4% PLR on the uplink to eNB 322-2.
  • the UE 302-2 signals its respective uplink and downlink PLR requirements to the local eNB 322-2, while the UE 302-1 similarly signals uplink and downlink PLR requirements to its local eNB 322-1 at 436.
  • FIG. 4B illustrates another possible solution to signal PLR requirements to the two local eNBs 322-1, 322-2 in the transport path between the UEs 302-1, 302-2 based on the codec in use as well as the PLC and JBM implementations in use at the respective UEs 302-1, 302-2.
  • the UEs 302-1, 302-2 may engage in a codec negotiation in a similar manner as described above with respect to FIG. 4A.
  • 4B differs in the sense that one terminal (i.e., UE 302-2 in the illustrated example) makes the initial decision as to what PLR to request from the local eNB 322-2 and signals the initial decision accordingly at 434. Then, at 435, the UE 302-2 sends a message to UE 302-1 to indicate the PLR that UE 302-2 expects to be requested from eNB 322-1, and UE 302-1 then requests the indicated PLR from eNB 322-1, as depicted at 436.
  • one terminal i.e., UE 302-2 in the illustrated example
  • FIG. 4C illustrates still another possible solution to signal PLR requirements to the two eNBs 322-1, 322-2 in the transport path between the UEs 302-1, 302-2 based on the codec in use as well as the PLC and JBM implementations in use at the respective UEs 302-1, 302-2. More particularly, at 432, the UEs 302-1, 302-2 may perform a codec negotiation, during which the UEs 302-1, 302-2 exchange information about their PLC and JBM capabilities.
  • the PLC capabilities may include one or more PLC algorithms such as zero insertion, waveform substitutions, model-based methods
  • the JBM capabilities may refer to a target underflow rate or other suitable JBM implementation used to counter jitter in a packet-switched network (e.g., the effective packet loss, jitter induced packet/delay loss statistics experienced over time, location, etc.).
  • the PLC and JBM capabilities could take the form of a total tolerable packet loss rate (PLR) that the respective UEs 302-1, 302-2 can tolerate for a given codec/mode and current PLC and JBM implementation.
  • PLR total tolerable packet loss rate
  • the network element(s) may comprise a Call Session Control Function (CSCF) or Policy and Charging Rules Function (PCRF) 412-1 that sends a message 442 to eNB 322-1 to signal the uplink and downlink PLR for UE 302-1 as well as a CSCF/PCRF 412-2 that sends a message 444 to eNB 322-2 to signal the uplink and downlink PLR for UE 302-2.
  • CSCF Call Session Control Function
  • PCRF Policy and Charging Rules Function
  • the CSCF/PCRFs 412-1, 412-2 can decide to request that each of the eNBs 322-1, 322-2 provide links to support PLRs that are based on a particular ratio.
  • the ratio may be a 1 : 1 ratio such that half of the max end-to-end PLR is allocated to the uplink and the other half to the downlink, or the CSCF/PCRFs 412-1, 412-2 can decide on a ratio whereby the maximum tolerable end-to-end PLR allows more errors on an uplink because LTE networks tend to have more limited uplink coverage.
  • the variable R may represent the ratio of the uplink PLR to the downlink PLR.
  • the CSCF/PCRF 412-1 may request that eNB 322-1 support on the uplink from UE 302-1 a PLR equal to the maximum e2e PLR that UE 302-2 can tolerate multiplied by R/(R+1) and further request that eNB 322-1 support on the downlink to UE 302-1 a PLR equal to the maximum e2e PLR that UE 302-1 can tolerate multiplied by 1/(R+1).
  • CSCF/PCRF 412-2 may request that eNB 322-2 support on the uplink from UE 302-2 a PLR equal to the maximum e2e PLR that UE 302-1 can tolerate multiplied by R/(R+1) and further request that eNB 322-2 support on the downlink to UE 302-2 a PLR equal to the maximum e2e PLR that UE 302-2 can tolerate multiplied by 1/(R+1).
  • Another approach may be based upon a Session
  • SDP Session Description Protocol
  • UE 302-1 may send a Session Description Protocol (SDP) message with the maximum end-to-end PLR that the UE 302-1 can receive for a codec mode and a current PLC/JMB implementation (e.g., six percent).
  • SDP Session Description Protocol
  • the CSCF/PCRF 412-1 may see the parameter in the SDP message and decides to allocate on the downlink to UE 302-1 a proportion of the maximum end-to-end PLR (e.g., 2% out of the advertised 6%).
  • the CSCF/PCRF 412-1 therefore tells the local eNB 322-1 to support 2% PLR on the downlink to UE 302-1.
  • the CSCF/PCRF 412-1 also modifies the parameter in the SDP offer to indicate that 4% PLR is required and sends this modified SDP offer to the CSCF/PCRF 412-2.
  • the CSCF/PCRF 412-2 uses the modified PLR value in the SDP offer to set the uplink PLR at eNB 322-2 (e.g., directing the eNB 322-2 to use 4% PLR on an uplink from UE 302-2).
  • a similar procedure may happen in the reverse direction.
  • UE 302-2 sends back in an SDP answer the maximum PLR that UE 302-2 can receive and the local CSCF/PCRF 412-2 takes a portion of the PLR budget.
  • FIGs. 4A-4C each illustrate a signaling exchange 432 during which UEs 302-1, 302-2 negotiate a codec and/or codec mode and further exchange PLC and JBM information. Accordingly, and with further reference to FIG.
  • the UEs 302-1, 302-2 may use the signaling exchange 432 to negotiate a maximum end-to-end error rate and an error rate for each link, including at least an uplink 342 from UE 302-1 to eNB 322-1 and a downlink 346 from eNB 322-2 to UE 302-2 in a direction from UE 302-1 to UE 302-2 as well as an uplink 332 from UE 302-2 to eNB 322-2 and a downlink 336 from eNB 322-1 to UE 302-1 in a direction from UE 302-2 to UE 302-1.
  • the maximum end-to-end error rate and the error rate for each link may comprise packet loss rate (PLR) values and/or block error rate (BLER) values, which are generally expressed as percentages.
  • PLR packet loss rate
  • BLER block error rate
  • the maximum end-to-end PLR and the PLR for each of the links 332, 336, 342, 346 may be pre-configured at the device level (e.g., at manufacture time) and/or configured at the device level via Open Mobile Alliance Device Management (OMA-DM).
  • OMA-DM Open Mobile Alliance Device Management
  • the PLR values may generally depend on device-specific and/or operator-specific parameters related to supported codecs, supported codec modes, PLC algorithms, JBM implementations, and so on.
  • the maximum end- to-end and link-specific PLR values can be dependent on network conditions. For example, the network may be lightly or heavily loaded at any given point in time, which may impact the ability of the network to support a given PLR value.
  • the network may include one or more areas in which good coverage can be provided (e.g., a low uplink/downlink PLR) until an edge of cell is reached, or the maximum PLR values may depend on operator policy (e.g., the network may provide less reliable bearers during busy times of day), etc.
  • this non-static information about the supported PLR can be communicated to the CSCF/PCRFs 412-1, 412-2, which may then modify one or more parameters used in a Session Description Protocol (SDP) offer/answer exchange between the UEs 302-1, 302-2 to reflect the link- specific PLR limitation(s).
  • SDP Session Description Protocol
  • the network PLR conditions could be sent to the UEs 302-1, 302-2 prior to the UEs 302-1, 302-2 initiating the SDP offer/answer negotiation (i.e., the network PLR conditions are broadcast across the cell).
  • one or more network nodes such as the CSCF/PCRFs 412-1, 412-2 may look at the result of the SDP offer/answer negotiation between the endpoint UEs 302-1, 302-2 and make appropriate requests to the respective eNBs 322-1, 322-2 via messages 442, 444.
  • one of the endpoint UEs 302-1, 302-2 may be an offeror device and the other may be an answerer device.
  • certain SDP attributes may be used in the SDP offer/answer negotiation, including a triad for the offeror device that specifies (i) a maximum end-to-end (e2e) PLR that the offeror device is setup to receive (max_e2e_PLR_Off), (ii) a proposed uplink PLR in a direction from the offeror device to the answerer device (UL PLR Off), and (iii) a proposed downlink PLR in a direction from the answerer device to the offeror device (DL PLR Off).
  • e2e maximum end-to-end
  • the SDP attributes used in the SDP offer/answer negotiation may include a substantially similar triad for the answerer device, wherein the answerer triad specifies (i) a maximum end-to-end (e2e) PLR that the answerer device is setup to receive (max_e2e_PLR_Ans), (ii) a proposed uplink PLR in a direction from the answerer device to the offeror device (UL PLR Ans), and (iii) a proposed downlink PLR in a direction from the offeror device to the answerer device (DL PLR Ans).
  • all PLR values may be expressed as percentages.
  • the offeror triad and the answerer triad mentioned above are subject to the following constraints:
  • SDP offer/answer negotiation may proceed as follows. First, the offeror device may send an SDP offer to the answerer device that indicates the offeror triad set, including max_e2e_PLR_Off, UL PLR Off, and DL PLR Off. The answerer device, upon receiving the SDP offer, may then either accept or modify the proposed UL PLR Off and DL PLR Off values. For example, if the proposed UL PLR Off exceeds the difference between max_e2e_PLR_Ans and DL PLR Ans, the proposed UL PLR Off may be more than the answerer device can handle.
  • the answerer device may reduce the proposed UL PLR Off value to fit within the end-to-end PLR limit that the answerer device can handle, taking into consideration any portion thereof that the answerer device may need to reserve for DL PLR Ans.
  • the answerer device may have all the information needed to either accept or modify the offer based on the information in the offeror triad and the PLR configuration at the answerer device, specifically the values for max_e2e_PLR_Ans, UL PLR Ans, and DL PLR Ans.
  • the offeror device may either accept the modified PLR parameters in the modified offer or reject the modified offer.
  • the answerer device may therefore respond with its triad set.
  • the answerer device may only need to provide the max_e2e_PLR_Ans value, as the other values can be derived from the values in the offeror triad.
  • reducing the parameters provided in the SDP answer may not allow for scenarios that do not exhaust the entire PLR budget (e.g., to maintain a higher quality voice call) and/or limit applicability to scenarios in which the uplink PLR and downlink PLR are split equally.
  • the SDP offer/answer negotiation as described above may be applied in a scenario in which the answerer device has a PLR configuration that indicates agreement with the offeror triad included in the SDP offer from the offeror device and further in which the entire end-to-end PLR budget is utilized.
  • the SDP offer may include an offeror triad in which max_e2e_PLR_Off equals five (5), UL PLR Off equals seven (7), and DL PLR Off equals one (1).
  • the answerer device may insert the answerer triad into the SDP answer without modifying the offeror triad.
  • the SDP answer may include an answerer triad in which max_e2e_PLR_Ans equals nine (9), UL PLR Ans equals four (4), and DL PLR Ans equals two (2). Accordingly, in a direction from the answerer device to the offeror device, the maximum 5% end-to-end budget for max_e2e_PLR_Off is split up into 1% PLR for the downlink to the offeror device and 4% PLR for the uplink from the answerer device.
  • the maximum 9% end-to-end budget for max_e2e_PLR_Ans is split up into 2% PLR for the downlink to the answerer device and 7% PLR for the uplink from the offeror device.
  • the SDP offer/answer negotiation as described above may be applied in a scenario in which the answerer device has a PLR configuration that agrees with the offeror triad included in the SDP offer from the offeror device, except that this scenario may differ from the previous scenario in that the entire end-to-end PLR budget is not utilized.
  • voice quality may generally degrade as PLR/BLER increases, whereby utilizing less than the entire end-to-end PLR budget may leader to a better quality voice session.
  • the SDP offer may include an offeror triad in which the value for max_e2e_PLR_Off is ten (10), the value for UL PLR Off is five (5), and the value for DL PLR Off is one (1).
  • the answerer device may insert the answerer triad into the SDP answer without modifying the offeror triad.
  • the SDP answer may include an answerer triad in which the values are configured to not utilize the entire max_e2e_PLR_Off and/or max_e2e_PLR_Ans end-to-end budgets.
  • the value for max_e2e_PLR_Ans may be set to nine (9)
  • the value for UL PLR Ans may be set to four (4)
  • the value for DL PLR Ans may be set to two (2).
  • the maximum 10% end-to-end budget for max_e2e_PLR_Off is split up into 1% PLR for the downlink to the offeror and 4% PLR for the uplink from the answerer, leaving 5% of the end-to-end budget unutilized.
  • the maximum 9% end-to-end budget for max_e2e_PLR_Ans is split up into 2% PLR for the downlink to the answerer and 5% PLR for the uplink from the offeror, leaving 2% of the end-to-end budget unutilized.
  • the SDP offer/answer negotiation as described above may be applied in a scenario in which the answerer device has a PLR configuration that conflicts with the offeror triad included in the SDP offer from the offeror device, wherein the entire end-to-end PLR budget may need to be utilized in order to fit the link-specific PLR values within the maximum end-to-end PLR values in either or both directions.
  • this scenario may be illustrated in an SDP offer that includes an offeror triad in which the value for max_e2e_PLR_Off is ten (10), the value for UL PLR Off is seven (7), and the value for DL PLR Off is one (1).
  • the SDP answer may include SDP attributes in which max_e2e_PLR_Ans is seven (7), UL PLR Ans is four (4), DL PLR Ans is two (2), and further in which the offeror triad is modified such that max_e2e_PLR_Off remains at ten (10), UL PLR Off is reduced to five (5), and DL PLR Off remains at one (1).
  • the offeror device can either accept or reject the payload type.
  • the uplink PLR and the downlink PLR in a given direction can generally be assumed to add up to the total end-to-end PLR in that direction.
  • the offeror/answerer PLR configurations could be simplified to two parameters, namely the end-to-end PLR and the link-specific PLR in either the uplink or the downlink direction, as the PLR in the other direction can be derived from the other values.
  • Another possible simplification may be to only communicate one parameter, namely the maximum end-to-end PLR budget, which may be well-suited to implementations in which the maximum end-to-end PLR budget is equally split among the uplink PLR and the downlink PLR.
  • the CSCF/PCRFs 412-1, 412-2 may examine the SDP answer to extract the negotiated PLR configuration and communicate the appropriate values to the respective local eNBs 322-1, 322-2. For example, if UE 302-1 is the offerer device and UE 302-2 is the answerer device, then CSCF/PCRF 412-1 may ask eNB 322-1 to support UL PLR Off on its uplink from UE 302-1 and further ask eNB 322-1 to support on DL PLR Off on its downlink to UE 302-1 based on the appropriate values indicated in the SDP answer from UE 302-2. Furthermore, CSCF/PCRF 412-2 may ask eNB 322-2 to support UL_PLR_Ans on its uplink from UE 302-2 and further ask eNB 322-2 to support DL PLR Ans on its downlink to UE 302-2.
  • a PCRF -negotiated approach may also be implemented, which may advantageously leverage the fact that the CSCF/PCRFs 412-1, 412-2 may have more dynamic information about the loading and coverage situation of the eNBs 322-1, 322-2 serving the UEs 302-1, 302-2.
  • the CSCF/PCRFs 412-1, 412-2 negotiate the proportion of the maximum end- to-end (e2e) PLR to allocate to the uplinks and downlinks associated with eNBs 322-1, 322-2 as follows. First, in an SDP offer to the answerer UE 302-2, the offeror UE 302-1 may indicate its maximum end-to-end PLR (max_e2e_PLR_Off).
  • the CSCF/PCRF 412-1 may see this parameter value decide how to allocate a proportion of max_e2e_PLR_Off to the downlink of eNB 322-1 based on operator policy, which may be indicated by adding DL PLR Off in the SDP offer.
  • the CSCF/PCRF 412-1 may also indicate a preferred uplink PLR by adding UL PLR Off into the SDP offer.
  • the CSCF/PCRF 412-2 may store the values of DL PLR Off and UL PLR Off in the SDP offer and remove these SDP parameters from the SDP offer before forwarding this onto the answerer UE 302-2.
  • the answerer UE 302-2 receives the SDP offer, and responds by including its maximum end-to-end PLR, max_e2e_PLR_Ans in the SDP answer it sends back.
  • the CSCF/PCRF 412-2 receives the SDP answer and checks that DL PLR Ans plus UL PLR Off is less than max_e2e_PLR_Ans. If this condition is met, then CSCF/PCRF 412-2 adds DL PLR Ans and UL PLR Off into the SDP Answer. Otherwise, the CSCF/PCRF 412-2 modifies both DL PLR Ans and UL PLR Off so that their sum is less than max_e2e_PLR_Ans and then includes them into the SDP answer.
  • the CSCF/PCRF 412-2 may check that UL PLR Ans plus DL PLR Off is less than max_e2e_PLR_0ff. If this condition is met, then the CSCF/PCRF 412-1 may add UL PLR Ans and DL PLR Off into the SDP Answer. Otherwise, the CSCF/PCRF 412-2 modifies both UL PLR Ans and DL PLR Off so that their sum is less than max_e2e_PLR_Off and then includes them into the SDP answer. When the CSCF/PCRF 412-1 receives the SDP answer, the SDP answer may be rejected if the values of UL PLR Off and DL PLR Off that were modified by the CSCF/PCRF 412-2 are not acceptable. If the CSCF/PCRF 412-1 accepts the SDP answer, then both CSCF/PCRFs 4121, 412-2 have all the information needed to communicate the required UL and DL PLRs to their local eNBs 322-1, 322-2.
  • the PCRF -negotiated approach may be implemented using a single SDP parameter, namely, the maximum end-to-end PLR, or max_e2e_PLR.
  • a single SDP parameter namely, the maximum end-to-end PLR, or max_e2e_PLR.
  • max_e2e_PLR the maximum end-to-end PLR
  • the offeror UE 302-1 sends max_e2e_PLR_Off in the SDP offer.
  • the CSCF/PCRF 412-1 may see this parameter in the SDP offer and decide that it will allocate on the downlink to UE 302-1 DL PLR Off which is less than max_e2e_PLR_0ff.
  • the CSCF/PCRF 412-2 could also choose to use a UL PLR Ans that is less than new max_e2e_PLR_Off if it did not want to use the entire e2e PLR budget. In the reverse direction a similar procedure happens, wherein the answerer UE 302-2 sends its max_e2e_PLR_Ans in the SDP answer. The local CSCF/PCRF 412-2 takes a portion of max_e2e_PLR_Ans and allocates it to the downlink of eNB 322-2 in DL PLR Ans.
  • the CSCF/PCRF 412-1 could also choose to use a value for UL PLR Off that is less than new max_e2e_PLR_Ans if it did not want to use the entire e2e PLR budget.
  • each UE engaged in a voice session may determine actual packet loss rates during the voice session.
  • the far-end UE receiving media packets may send a request (e.g., using codec mode request (CMR)) to the UE transmitting the media packets to use a more robust codec or codec mode (e.g., move from AMR or AMR-WB to EVS, from EVS to EVS Channel-Aware, etc.).
  • CMR codec mode request
  • the receiving UE may send a request to the transmitting UE to use application layer redundancy and/or pay load or partial redundancy depending on the negotiated bitrate.
  • the transmitting UE may detect poor network coverage (e.g., due to low transmission power headroom, build-up in an uplink transmission buffer, etc.). In such cases, the transmitting UE may autonomously start to transmit using a more robust codec or a more robust mode of a codec.
  • FIG. 5 Another possible solution to ensure that terminals engaged in a voice session will use more robust multimedia codecs or codec modes is illustrated in FIG. 5.
  • the communication flow shown in FIG. 5 may be based on a Session Description Protocol (SDP) parameter that indicates that both UEs 302-1, 302-2 will perform codec adaptation, which may be exchanged between the UEs 302-1, 302-2 as part of the initial codec negotiation performed at 532.
  • SDP Session Description Protocol
  • the CSCF/PCRFs 412-1, 412-2 may send the PLR associated with the most robust mode to the local eNBs 322-1, 322-2 at 542, 544. This may be based on an assumption that the UEs 302-1, 302-2 will switch to a more robust codec/mode in the event that network coverage becomes poor.
  • the CSCF/PCRFs 412-1, 412-2 may send the local eNBs 322-1, 322-2 the PLR associated with the least robust mode (e.g., to assure call continuity when there is uncertainty as to whether the UEs 302-1, 302-2 will switch to a more robust codec/mode).
  • this codec adaptation parameter could also be useful in general, as the CSCF/PCRFs 412-1, 412-2 could use the codec adaptation parameter to determine whether and/or when to set a Maximum Bit Rate (MBR) to be greater than a Guaranteed Bit Rate (GBR).
  • MLR Maximum Bit Rate
  • GBR Guaranteed Bit Rate
  • one possible issue that may arise when using application layer redundancy (instead of the partial redundancy used in EVS Channel- Aware mode) to improve error robustness of the codec when at the coverage edge is that the particular configuration that the UEs 302-1, 302-2 will use when high packet loss is detected may be unknown because there are several possibilities that tradeoff between speech quality and error robustness (e.g., different PLC and/or JBM implementations, different codec/mode configuration options, etc.).
  • the UEs 302-1, 302-2 may be configured to indicate (e.g., in SDP) a "most robust codec configuration" supported at the respective UEs 302-1, 302-2 so that the network elements (e.g., eNBs 322-1, 322-2 and CSCF/PCRFs 412-1, 412-2) may know what to expect when one or more of the UEs 302-1, 302-2 approach the coverage edge or otherwise detect increased packet loss and/or poor network coverage.
  • the appropriate network element(s) can thereby set the applicable SRVCC threshold(s) according to the most robust codec configuration indicated by the respective UEs 302-1, 302-2.
  • an operator may optionally configure one or more of the UEs 302-1, 302-2 to use a particular configuration when high packet loss is detected and this configuration may be signaled via SDP to the far end eNB and UE.
  • the eNBs 322-1, 322-2 may be configured to further update or modify an SRVCC threshold(s) that was originally set based on the signaling from CSCF/PCRFs 412-1, 412-2, respectively.
  • the eNBs 322-1, 322-2 may be configured to further update or modify an SRVCC threshold(s) and/or other suitable handoff threshold that was originally set based on the signaling from UEs 302-1, 302-2, respectively.
  • the eNBs 322-1, 322-2 may be configured to further update or modify an SRVCC threshold(s) and/or other suitable handoff threshold based on the signaling from both the UEs 302-1, 302-2 and CSCF/PCRFs 412-1, 412-2.
  • a user equipment (UE) 600 may have a configuration suitable for use in accordance with the various aspects and embodiments described herein.
  • the UE 600 may include one or more processors 605 (e.g., one or more ASICs, one or more digital signal processors (DSPs), etc.) and a memory 610 (e.g., RAM, ROM, EEPROM, flash cards, or any memory common to computer platforms).
  • processors 605 e.g., one or more ASICs, one or more digital signal processors (DSPs), etc.
  • DSPs digital signal processors
  • memory 610 e.g., RAM, ROM, EEPROM, flash cards, or any memory common to computer platforms.
  • the UE 600 also includes one or more UI input components 615 (e.g., a keyboard and mouse, a touchscreen, a microphone, one or more buttons such as volume or power buttons, etc.) and one or more UI output components 620 (e.g., speakers, a display screen, a vibration device for vibrating the UE 600, etc.).
  • UI input components 615 e.g., a keyboard and mouse, a touchscreen, a microphone, one or more buttons such as volume or power buttons, etc.
  • UI output components 620 e.g., speakers, a display screen, a vibration device for vibrating the UE 600, etc.
  • the UE 600 further includes a wired communications interface 625 and a wireless communications interface 630.
  • the wired communications interface 625 can be used to support wired local connections to peripheral devices (e.g., a USB connection, a mini USB or lightning connection, a headphone jack, graphics ports such as serial, VGA, HDMI, DVI or Display Port, audio ports, and so on) and/or to a wired access network (e.g., via an Ethemet cable or another type of cable that can function as a bridge to the wired access network such as HDMI vl.4 or higher, etc.).
  • peripheral devices e.g., a USB connection, a mini USB or lightning connection, a headphone jack, graphics ports such as serial, VGA, HDMI, DVI or Display Port, audio ports, and so on
  • a wired access network e.g., via an Ethemet cable or another type of cable that can function as a bridge to the wired access network such as HDMI vl.4 or higher, etc.
  • the wireless communications interface 630 includes one or more wireless transceivers for communication in accordance with a local wireless communications protocol (e.g., WLAN, Wi-Fi Direct, Bluetooth, etc.).
  • the wireless communications interface 630 may also include one or more wireless transceivers for communication with a cellular RAN (e.g., via CDMA, W-CDMA, time division multiple access (TDMA), frequency division multiple access (FDMA), Orthogonal Frequency Division Multiplexing (OFDM), GSM, or other protocols that may be used in a wireless communications network or a data communications network).
  • the various components 605-630 of the UE 600 can communicate with each other via a bus 635.
  • the UE 600 may correspond to any type of UE, including but not limited to a smart phone, a laptop computer, a desktop computer, a tablet computer, a wearable device (e.g., a pedometer, a smart watch, etc.) and so on.
  • a smart phone e.g., a laptop computer, a desktop computer, a tablet computer, a wearable device (e.g., a pedometer, a smart watch, etc.) and so on.
  • FIG. 6 Two particular implementation examples of the UE 600 are depicted in FIG. 6, which are illustrated as laptop 640 and touchscreen device 655 (e.g., a smart phone, a tablet computer, etc.).
  • the laptop 640 includes a display screen 645 and a UI area 650 (e.g., keyboard, touchpad, power button, etc.), and while not shown the laptop 640 may include various ports as well as wired and/or wireless transceivers (e.g., Ethernet card, WLAN card, broadband card, etc.).
  • the touchscreen device 655 is configured with a touchscreen display 660, peripheral buttons 665, 670, 675 and 680 (e.g., a power control button, a volume or vibrate control button, an airplane mode toggle button, etc.), and at least one front-panel button 685 (e.g., a Home button, etc.), among other components, as is known in the art.
  • the touchscreen device 655 can include one or more external antennas and/or one or more integrated antennas that are built into the external casing of the touchscreen device 655, including but not limited to WLAN antennas, cellular antennas, satellite position system (SPS) antennas (e.g., global positioning system (GPS) antennas), and so on.
  • WLAN antennas e.g., cellular antennas, satellite position system (SPS) antennas (e.g., global positioning system (GPS) antennas), and so on.
  • SPS satellite position system
  • GPS global positioning system
  • the UE 600 illustrated in FIG. 6 may correspond to any of the UEs described above, including the UEs 302-1, 302-2 illustrated in FIG. 3, FIGs. 4A-4C, and FIG. 5. Accordingly, the various components of the UE 600 may provide means for performing at least the functions associated with the UEs 302-1, 302-2 illustrated in FIG. 3, FIGs. 4A-4C, and FIG. 5.
  • the access point 700 may include one or more processors 705 (e.g., one or more ASICs, one or more DSPs, etc.) and a memory 710 (e.g., RAM, ROM, EEPROM, flash cards, or any memory common to computer platforms).
  • the access point 700 further includes a wired communications interface 725 and a wireless communications interface 730.
  • the various components 705-330 of the access point 700 can communicate with each other via a bus 735.
  • the wired communications interface 725 can be used to connect to one or more backhaul components.
  • the one or more backhaul components to which the access point 700 is connected via the wired communications interface 725 may include a base station controller (BSC), a radio network controller (RNC), other access points (e.g., other Node Bs via X2 connections as defined by LTE), core network components such as a serving gateway (S-GW) or a mobility management entity (MME), and so on.
  • BSC base station controller
  • RNC radio network controller
  • other access points e.g., other Node Bs via X2 connections as defined by LTE
  • core network components such as a serving gateway (S-GW) or a mobility management entity (MME), and so on.
  • S-GW serving gateway
  • MME mobility management entity
  • the wireless communications interface 730 includes one or more wireless transceivers for communication in accordance with a wireless communications protocol.
  • the wireless communications protocol may be based on the configuration of the access point 700. For example, if the access point 700 is implemented as macro cell 740 or small cell 745 (e.g., a femto cell, a pico cell, etc.), the wireless communications interface 730 may include one or more wireless transceivers configured to implement a cellular protocol (e.g., CDMA, W-CDMA, GSM, 3G, 4G, 5G, etc.).
  • a cellular protocol e.g., CDMA, W-CDMA, GSM, 3G, 4G, 5G, etc.
  • the wireless communications interface 730 may include one or more wireless transceivers configured to implement a Wi-Fi (or 802.11) protocol (e.g., 802.11a, 802.11b, 802.1 lg, 802.11 ⁇ , etc.).
  • the access point 700 illustrated in FIG. 7 may correspond to any of the access points, base stations, etc. described above, including the eNBs 322-1, 322-2 illustrated in FIG. 3, FIGs. 4A-4C, and FIG. 5. Accordingly, the various components of the access point 700 illustrated in FIG. 7 may provide means for performing at least the functions associated with the eNBs 322-1, 322-2 illustrated in FIG. 3, FIGs. 4A-4C, and FIG. 5.
  • an exemplary communications device 800 as illustrated therein may include various structural components that can be configured in accordance with the various aspects and embodiment described herein.
  • the communications device 800 can correspond to any of the above-noted communications devices, including but not limited to a UE or an access point, any component included in a RAN such as a base station, an access point, an eNB, a BSC or RNC, a CSCF or PCRF or any other suitable component of a core network, a server or any other component coupled to the Internet, and so on.
  • communications device 800 can correspond to any electronic device that is configured to communicate with (or facilitate communication with) one or more other entities as described herein.
  • the communications device 800 includes transceiver circuitry configured to receive and/or transmit information 805.
  • the transceiver circuitry configured to receive and/or transmit information 805 can include a wireless communications interface (e.g., Bluetooth, WLAN, Wi-Fi Direct, LTE-Direct, etc.) such as a wireless transceiver and associated hardware (e.g., an RF antenna, a MODEM, a modulator and/or demodulator, etc.).
  • a wireless communications interface e.g., Bluetooth, WLAN, Wi-Fi Direct, LTE-Direct, etc.
  • a wireless transceiver and associated hardware e.g., an RF antenna, a MODEM, a modulator and/or demodulator, etc.
  • the transceiver circuitry configured to receive and/or transmit information 805 can correspond to a wired communications interface (e.g., a serial connection, a USB or Firewire connection, an Ethernet connection through which the Internet can be accessed, etc.).
  • a wired communications interface e.g., a serial connection, a USB or Firewire connection, an Ethernet connection through which the Internet can be accessed, etc.
  • the transceiver circuitry configured to receive and/or transmit information 805 can correspond to an Ethernet card, in an example, that connects the network-based server to other communication entities via an Ethernet protocol.
  • the transceiver circuitry configured to receive and/or transmit information 805 can include sensory or measurement hardware by which the communications device 800 can monitor its local environment (e.g., an accelerometer, a temperature sensor, a light sensor, an antenna for monitoring local RF signals, etc.).
  • the transceiver circuitry configured to receive and/or transmit information 805 can also include software that, when executed, permits the associated hardware of the transceiver circuitry configured to receive and/or transmit information 805 to perform its reception and/or transmission function(s).
  • the transceiver circuitry configured to receive and/or transmit information 805 does not correspond to software alone, and the transceiver circuitry configured to receive and/or transmit information 805 relies at least in part upon structural hardware to achieve its functionality.
  • the transceiver circuitry configured to receive and/or transmit information 805 may be implicated by language other than "receive "and "transmit", so long as the underlying function corresponds to a receive or transmit function.
  • functions such as obtaining, acquiring, retrieving, measuring, etc., may be performed by the transceiver circuitry configured to receive and/or transmit information 805 in certain contexts as being specific types of receive functions.
  • functions such as sending, delivering, conveying, forwarding, etc., may be performed by the transceiver circuitry configured to receive and/or transmit information 805 in certain contexts as being specific types of transmit functions.
  • the communications device 800 further includes at least one processor configured to process information 810.
  • Example implementations of the type of processing that can be performed by the at least one processor configured to process information 810 includes but is not limited to performing determinations, establishing connections, making selections between different information options, performing evaluations related to data, interacting with sensors coupled to the communications device 800 to perform measurement operations, converting information from one format to another (e.g., between different protocols such as .wmv to .avi, etc.), and so on.
  • the at least one processor configured to process information 810 can include a general purpose processor, a DSP, an ASIC, a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein.
  • a general purpose processor may be a microprocessor, but in the alternative, the at least one processor configured to process information 810 may be any conventional processor, controller, microcontroller, or state machine.
  • a processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).
  • the at least one processor configured to process information 810 can also include software that, when executed, permits the associated hardware of the at least one processor configured to process information 810 to perform its processing function(s). However, the at least one processor configured to process information 810 does not correspond to software alone, and the at least one processor configured to process information 810 relies at least in part upon structural hardware to achieve its functionality. Moreover, the at least one processor configured to process information 810 may be implicated by language other than "processing", so long as the underlying function corresponds to a processing function. For example, functions such as evaluating, determining, calculating, identifying, etc., may be performed by the at least one processor configured to process information 810 in certain contexts as being specific types of processing functions. Other functions that correspond to other types of processing functions may also be performed by the at least one processor configured to process information 810.
  • the communications device 800 further includes memory configured to store information 815.
  • the memory configured to store information 815 can include at least a non-transitory memory and associated hardware (e.g., a memory controller, etc.).
  • the non-transitory memory included in the memory configured to store information 815 can correspond to RAM, flash memory, ROM, erasable programmable ROM (EPROM), EEPROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
  • the memory configured to store information 815 can also include software that, when executed, permits the associated hardware of the memory configured to store information 815 to perform its storage function(s).
  • the memory configured to store information 815 does not correspond to software alone, and the memory configured to store information 815 relies at least in part upon structural hardware to achieve its functionality.
  • the memory configured to store information 815 may be implicated by language other than "storing", so long as the underlying function corresponds to a storing function.
  • functions such as caching, maintaining, etc., may be performed by the memory configured to store information 815 in certain contexts as being specific types of storing functions.
  • Other functions that correspond to other types of storing functions may also be performed by the memory configured to store information 815.
  • the communications device 800 further optionally includes user interface output circuitry configured to present information 820.
  • the user interface output circuitry configured to present information 820 can include at least an output device and associated hardware.
  • the output device can include a video output device (e.g., a display screen, a port that can carry video information such as USB, HDMI, etc.), an audio output device (e.g., speakers, a port that can carry audio information such as a microphone jack, USB, HDMI, etc.), a vibration device and/or any other device by which information can be formatted for output or actually outputted by a user or operator of the communications device 800.
  • a video output device e.g., a display screen, a port that can carry video information such as USB, HDMI, etc.
  • an audio output device e.g., speakers, a port that can carry audio information such as a microphone jack, USB, HDMI, etc.
  • a vibration device e.g., a vibration device and/or any other device by which information can be formatted
  • the user interface output circuitry configured to present information 820 can include a display such as display screen 645 or touchscreen display 660.
  • the user interface output circuitry configured to present information 820 can be omitted for certain communications devices, such as network communications devices that do not have a local user (e.g., network switches or routers, remote servers, etc.).
  • the user interface output circuitry configured to present information 820 can also include software that, when executed, permits the associated hardware of the user interface output circuitry configured to present information 820 to perform its presentation function(s).
  • the user interface output circuitry configured to present information 820 does not correspond to software alone, and the user interface output circuitry configured to present information 820 relies at least in part upon structural hardware to achieve its functionality.
  • the user interface output circuitry configured to present information 820 may be implicated by language other than "presenting", so long as the underlying function corresponds to a presenting function.
  • functions such as displaying, outputting, prompting, conveying, etc., may be performed by the user interface output circuitry configured to present information 820 in certain contexts as being specific types of presenting functions.
  • Other functions that correspond to other types of presenting functions may also be performed by the user interface output circuitry configured to present information 820.
  • the communications device 800 further optionally includes user interface input circuitry configured to receive local user input 825.
  • the user interface input circuitry configured to receive local user input 825 can include at least a user input device and associated hardware.
  • the user input device can include buttons, a touchscreen display, a keyboard, a camera, an audio input device (e.g., a microphone or a port that can carry audio information such as a microphone jack, etc.), and/or any other device by which information can be received from a user or operator of the communications device 800.
  • the communications device 800 corresponds to UE 600 as shown in FIG. 6, the user interface input circuitry configured to receive local UI area 650 or touchscreen display 660, etc.
  • the user interface input circuitry configured to receive local user input 825 can be omitted for certain communications devices, such as network communications devices that do not have a local user (e.g., network switches or routers, remote servers, etc.).
  • the user interface input circuitry configured to receive local user input 825 can also include software that, when executed, permits the associated hardware of the user interface input circuitry configured to receive local user input 825 to perform its input reception function(s).
  • the user interface input circuitry configured to receive local user input 825 does not correspond to software alone, and the user interface input circuitry configured to receive local user input 825 relies at least in part upon structural hardware to achieve its functionality.
  • the user interface input circuitry configured to receive local user input 825 may be implicated by language other than "receiving local user input", so long as the underlying function corresponds to a receiving local user input function.
  • functions such as obtaining, receiving, collecting, etc., may be performed by the user interface input circuitry configured to receive local user input 825 in certain contexts as being specific types of receiving local user functions.
  • Other functions that correspond to other types of receiving local user input functions may also be performed by the user interface input circuitry configured to receive local user input 825.
  • any software used to facilitate the functionality of the configured structural components of 805 through 825 can be stored in the non-transitory memory associated with the memory configured to store information 815, such that the configured structural components of 805 through 825 each performs their respective functionality (i.e., in this case, software execution) based in part upon the operation of software stored by the memory configured to store information 815.
  • the at least one processor configured to process information 810 can format data into an appropriate format before being transmitted by the transceiver circuitry configured to receive and/or transmit information 805, such that the transceiver circuitry configured to receive and/or transmit information 805 performs its functionality (i.e., in this case, transmission of data) based in part upon the operation of structural hardware associated with the at least one processor configured to process information 810.
  • the server 900 may correspond to one example configuration of the server 170 described above.
  • the server 900 includes a processor 901 coupled to volatile memory 902 and a large capacity nonvolatile memory, such as a disk drive 903.
  • the server 900 may also include a floppy disc drive, compact disc (CD) or DVD disc drive 906 coupled to the processor 901.
  • the server 900 may also include network access ports 904 coupled to the processor 901 for establishing data connections with a network 907, such as a local area network coupled to other broadcast system computers and servers or to the Internet.
  • a network 907 such as a local area network coupled to other broadcast system computers and servers or to the Internet.
  • the server 900 of FIG. 9 illustrates one example implementation of the communications device 800, whereby the transceiver circuitry configured to transmit and/or receive information 805 corresponds to the network access ports 904 used by the server 900 to communicate with the network 907, the at least one processor configured to process information 810 corresponds to the processor 901, and the memory configuration to store information 815 corresponds to any combination of the volatile memory 902, the disk drive 903 and/or the disc drive 906.
  • the optional user interface output circuitry configured to present information 820 and the optional user interface input circuitry configured to receive local user input 825 are not shown explicitly in FIG. 9 and may or may not be included therein.
  • FIG. 9 helps to demonstrate that the communications device 800 illustrated in FIG. 8 may be implemented as a server as shown in FIG. 9 in addition to and/or as an alternative to the UE 600 as in FIG. 6 and/or the access point 700 as in FIG. 7.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • a general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
  • a processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or other such configurations).
  • a software module may reside in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of non-transitory computer-readable medium known in the art.
  • An exemplary non-transitory computer-readable medium may be coupled to the processor such that the processor can read information from, and write information to, the non-transitory computer-readable medium.
  • the non-transitory computer-readable medium may be integral to the processor.
  • the processor and the non-transitory computer-readable medium may reside in an ASIC.
  • the ASIC may reside in an IoT device.
  • the processor and the non- transitory computer-readable medium may be discrete components in a user terminal.
  • the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a non-transitory computer-readable medium.
  • Computer- readable media may include storage media and/or communication media including any non-transitory medium that may facilitate transferring a computer program from one place to another.
  • a storage media may be any available media that can be accessed by a computer.
  • such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.
  • any connection is properly termed a computer-readable medium.
  • the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium.
  • disk and disc which may be used interchangeably herein, includes CD, laser disc, optical disc, DVD, floppy disk, and Blu-ray discs, which usually reproduce data magnetically and/or optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
PCT/US2018/028333 2017-06-05 2018-04-19 Methods for increasing voip network coverage Ceased WO2018226318A1 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
BR112019025454-4A BR112019025454B1 (pt) 2017-06-05 2018-04-19 Métodos para aumentar a cobertura da rede para voip
CN201880036888.0A CN110710182B (zh) 2017-06-05 2018-04-19 用于增大VoIP网络覆盖的方法
ES18723171T ES2882194T3 (es) 2017-06-05 2018-04-19 Métodos para aumentar la cobertura de la red de VoIP
KR1020197035840A KR102616336B1 (ko) 2017-06-05 2018-04-19 VoIP 네트워크 커버리지를 증가시키기 위한 방법
EP18723171.7A EP3635931B1 (en) 2017-06-05 2018-04-19 Methods for increasing voip network coverage
JP2019566776A JP7084431B2 (ja) 2017-06-05 2018-04-19 ＶｏＩＰネットワークカバレッジを増加させるための方法

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US201762515342P 2017-06-05 2017-06-05
US62/515,342 2017-06-05
US201762567613P 2017-10-03 2017-10-03
US62/567,613 2017-10-03
US201862651045P 2018-03-30 2018-03-30
US62/651,045 2018-03-30
US15/954,587 2018-04-16
US15/954,587 US10574830B2 (en) 2017-06-05 2018-04-16 Methods for increasing VoIP network coverage

Publications (1)

Publication Number Publication Date
WO2018226318A1 true WO2018226318A1 (en) 2018-12-13

Family

ID=64460313

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/028333 Ceased WO2018226318A1 (en) 2017-06-05 2018-04-19 Methods for increasing voip network coverage

Country Status (9)

Country Link
US (1) US10574830B2 (enExample)
EP (1) EP3635931B1 (enExample)
JP (1) JP7084431B2 (enExample)
KR (1) KR102616336B1 (enExample)
CN (1) CN110710182B (enExample)
BR (1) BR112019025454B1 (enExample)
ES (1) ES2882194T3 (enExample)
TW (1) TWI755522B (enExample)
WO (1) WO2018226318A1 (enExample)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022531853A (ja) * 2019-05-06 2022-07-12 クゥアルコム・インコーポレイテッド パケット損失率に基づくコーデック構成適応

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11197345B2 (en) * 2017-09-07 2021-12-07 Intel Corporation Apparatuses for end-to-end coordination of voice over cellular data network communications
FR3071997A1 (fr) * 2017-10-02 2019-04-05 Orange Signalisation d’une requete d’adaptation d’une session de communication en voixsur ip
US11026147B2 (en) * 2018-02-13 2021-06-01 Apple Inc. Dynamic adaptation of maximum packet loss rate (PLR) for single radio voice call continuity (SRVCC) handover optimization using session description protocol (SDP)
US20190215729A1 (en) * 2018-03-15 2019-07-11 Intel Corporation Session description protocol mechanisms for signaling radio access network capabilities in multimedia telephony sessions
US11700526B2 (en) * 2018-06-12 2023-07-11 Samsung Electronics Co., Ltd. Method and apparatus for identifying in-call capability features
WO2019242846A1 (en) * 2018-06-19 2019-12-26 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for controlling a robot device over a wireless network
CN116566958A (zh) * 2018-09-07 2023-08-08 苹果公司 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法
US11509772B2 (en) * 2018-11-13 2022-11-22 Qualcomm Incorporated Methods for increasing Voice-over-Internet Protocol (VoIP) network coverage
CN110099405B (zh) * 2019-05-28 2022-03-18 中国联合网络通信集团有限公司 一种网络覆盖评估方法及装置
CN114175588B (zh) * 2019-06-21 2025-03-11 苹果公司 基于丢包率(plr)的自适应的配置
WO2020264166A1 (en) 2019-06-25 2020-12-30 Apple Inc. User equipment assistance information for voice over cellular
US12328619B2 (en) * 2019-10-15 2025-06-10 Qualcomm Incorporated Considerations on quality of service (QOS) hints for an uplink streaming service
WO2021164490A1 (en) * 2020-02-20 2021-08-26 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Methods, apparatus and user equipment for wireless communication
US11516718B2 (en) * 2020-07-09 2022-11-29 At&T Intellectual Property I, L.P. Dynamic discovery of network functions in mobility interworking across radio access technologies
US11297548B1 (en) * 2020-07-10 2022-04-05 T-Mobile Innovations Llc Initiating handover of a wireless device based on power headroom and packet drops
CN121001066A (zh) * 2021-03-05 2025-11-21 达发科技股份有限公司 接收和处理方法及装置、传送方法及装置和存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130215774A1 (en) * 2004-03-11 2013-08-22 Augme Technologies, Inc. System and method of media over an internet protocol communication

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7251241B1 (en) * 2002-08-21 2007-07-31 Cisco Technology, Inc. Devices, softwares and methods for predicting reconstruction of encoded frames and for adjusting playout delay of jitter buffer
WO2006126959A2 (en) * 2005-05-25 2006-11-30 Telefonaktiebolaget Lm Ericsson (Publ) Local switching of calls setup by multimedia core network
ZA200709592B (en) * 2005-05-25 2009-09-30 Ericsson Telefon Ab L M Enhanced VolP media flow quality by adapting speech encoding based on selected modulation and coding scheme (MCS)
CN100512214C (zh) * 2005-11-14 2009-07-08 华为技术有限公司 识别以太网业务质量的方法及系统
WO2007127481A2 (en) * 2006-04-28 2007-11-08 Airmagnet, Inc. Voice quality measurement for voice over ip in a wireless local area network
US8208516B2 (en) * 2006-07-14 2012-06-26 Qualcomm Incorporated Encoder initialization and communications
US8171146B2 (en) * 2007-06-20 2012-05-01 Cisco Technology, Inc. Utilization of media capabilities in a mixed environment
US8767545B2 (en) * 2009-06-15 2014-07-01 Qualcomm Incorporated Radio access network control of multimedia application data rates
US9338580B2 (en) * 2011-10-21 2016-05-10 Qualcomm Incorporated Method and apparatus for packet loss rate-based codec adaptation
US9047863B2 (en) * 2012-01-12 2015-06-02 Qualcomm Incorporated Systems, methods, apparatus, and computer-readable media for criticality threshold control
CN103517419B (zh) * 2012-06-20 2017-08-25 华为终端有限公司 通知上行数据发送的信道使用时间的方法、上行数据发送方法和设备
US9635644B2 (en) * 2012-08-10 2017-04-25 Qualcomm Incorporated Downlink coverage enhancements
CN102868576B (zh) * 2012-09-26 2015-05-13 电子科技大学 宽带网用户接入链路下行丢包率测量方法
US9882818B2 (en) * 2013-09-30 2018-01-30 Apple Inc. Adjusting a jitter buffer based on inter arrival jitter
WO2017015948A1 (zh) * 2015-07-30 2017-02-02 华为技术有限公司 调整无线网络系统的能量损耗的方法和装置
CN108029036B (zh) * 2015-09-15 2021-07-16 华为技术有限公司 业务处理方法、业务处理装置和通信系统

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130215774A1 (en) * 2004-03-11 2013-08-22 Augme Technologies, Inc. System and method of media over an internet protocol communication

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022531853A (ja) * 2019-05-06 2022-07-12 クゥアルコム・インコーポレイテッド パケット損失率に基づくコーデック構成適応
JP7600142B2 (ja) 2019-05-06 2024-12-16 クゥアルコム・インコーポレイテッド パケット損失率に基づくコーデック構成適応

Also Published As

Publication number Publication date
KR20200014770A (ko) 2020-02-11
KR102616336B1 (ko) 2023-12-20
BR112019025454B1 (pt) 2022-08-16
JP7084431B2 (ja) 2022-06-14
US20180352092A1 (en) 2018-12-06
TWI755522B (zh) 2022-02-21
ES2882194T3 (es) 2021-12-01
US10574830B2 (en) 2020-02-25
EP3635931B1 (en) 2021-06-23
TW201904252A (zh) 2019-01-16
CN110710182B (zh) 2021-11-26
BR112019025454A2 (pt) 2020-06-23
CN110710182A (zh) 2020-01-17
JP2020522940A (ja) 2020-07-30
EP3635931A1 (en) 2020-04-15

Similar Documents

Publication Publication Date Title
EP3635931B1 (en) Methods for increasing voip network coverage
US9554389B2 (en) Selectively allocating quality of service to support multiple concurrent sessions for a client device
US20140219167A1 (en) Quality of service for web client based sessions
US10652340B2 (en) Quick relay interface and transport selection
US20150195326A1 (en) Detecting whether header compression is being used for a first stream based upon a delay disparity between the first stream and a second stream
CN102075566A (zh) 业务的分流处理方法、通信设备及网络系统
US10978096B2 (en) Optimized uplink operation for voice over long-term evolution (VoLte) and voice over new radio (VoNR) listen or silent periods
US20140280705A1 (en) Seamless Session Handover
EP2781115B1 (en) Adjusting a bundling factor and de-jitter buffer size
CN107959950A (zh) 终端无线数据传输方法、装置、终端及存储介质
CN103929774B (zh) 资源状态交互方法、网络设备及网络系统
CN108174410A (zh) 终端无线数据传输方法、装置、终端及存储介质
HK40019798B (en) Methods for increasing voip network coverage
HK40019798A (en) Methods for increasing voip network coverage
WO2023011006A1 (zh) 一种通信方法、装置及设备
US20240381490A1 (en) Method and device for supporting multicast service transmission
KR20100060011A (ko) 이동 통신 시스템에서 수신 전용 그룹 콜을 위한 단방향 트래픽 할당
US20220217571A1 (en) Method Performed by a Core Network Node for Deciding How to Shape a Specific Data Flow
WO2024035797A1 (en) Wtru-initiated withdrawal from federated learning operation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18723171

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20197035840

Country of ref document: KR

Kind code of ref document: A

Ref document number: 2019566776

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112019025454

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2018723171

Country of ref document: EP

Effective date: 20200107

ENP Entry into the national phase

Ref document number: 112019025454

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20191202