WO2019184816A1 - Techniques for handling single radio voice call continuity - Google Patents

Techniques for handling single radio voice call continuity Download PDF

Info

Publication number
WO2019184816A1
WO2019184816A1 PCT/CN2019/079249 CN2019079249W WO2019184816A1 WO 2019184816 A1 WO2019184816 A1 WO 2019184816A1 CN 2019079249 W CN2019079249 W CN 2019079249W WO 2019184816 A1 WO2019184816 A1 WO 2019184816A1
Authority
WO
WIPO (PCT)
Prior art keywords
network entity
srvcc
measurement report
supported
network
Prior art date
Application number
PCT/CN2019/079249
Other languages
French (fr)
Inventor
Zhiguo Li
Haichao SONG
Bing LENG
Yuting Wang
Original Assignee
Qualcomm Incorporated
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 Incorporated filed Critical Qualcomm Incorporated
Publication of WO2019184816A1 publication Critical patent/WO2019184816A1/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0083Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
    • H04W36/0085Hand-off measurements
    • H04W36/0088Scheduling hand-off measurements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022Control 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/00224Control 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/00226Control 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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Various aspects described herein relate to techniques for managing measurement reports and handover procedures in wireless communications. In an aspect, the method includes receiving, by a user equipment (UE) from a network entity, a message including information of single radio voice call continuity (SRVCC) capability of the network entity, storing, by the UE, the information of the SRVCC capability of the network entity, receiving, by the UE from the network entity, a request for a measurement report. The method further includes determining, by the UE and in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information, and transmitting, by the UE to the network entity, the measurement report in response to a determination that the SRVCC is supported by the network entity.

Description

TECHNIQUES FOR HANDLING SINGLE RADIO VOICE CALL CONTINUITY
CROSS-REFERENCE TO RELATED APPLICATION
This application claims the benefit of International Application No. PCT/CN2018/081069 entitled “TECHNIQUES FOR HANDLING SINGLE RADIO VOICE CALL CONTINUITY” and filed March 29, 2018, which is expressly incorporated by reference herein in its entirety.
BACKGROUND
Aspects of the present disclosure relate generally to wireless communications systems, and more particularly, to techniques for handling a Single Radio Voice Call Continuity (SRVCC) in wireless communications.
Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. Typical wireless communication systems may employ multiple-access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple-access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.
These multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate on a municipal, national, regional, and even global level. An example telecommunication standard is Long Term Evolution (LTE) or LTE-Advanced (LTE-A) . However, although newer multiple access systems, such as an LTE or LTE-Asystem, deliver faster data throughput than older technologies, such increased downlink rates have triggered a greater demand for higher-bandwidth content, such as high-resolution graphics and video, for use on or with mobile devices. As such, demand for bandwidth, higher data rates, better transmission quality as well as better spectrum utilization, and lower latency on wireless communications systems continues to increase.
In another example, the fifth generation (5G) new radio (NR) communications technology, used in a wide range of spectrum, is envisaged to expand and support diverse usage scenarios and applications with respect to conventional mobile network generations. In an aspect, 5G NR communications technology includes, for example: enhanced mobile broadband (eMBB) addressing human-centric use cases for access to multimedia content, services and data; ultra-reliable low-latency communications (URLLC) with strict requirements, especially in terms of latency and reliability; and massive machine type communications (mMTC) for a very large number of connected devices and typically transmitting a relatively low volume of non-delay-sensitive information. As the demand for mobile broadband access continues to increase, there exists a need for further improvements in 5G communications technology and beyond. Preferably, these improvements should be applicable to other multi-access technologies and the telecommunication standards that employ these technologies.
Accordingly, due to the requirements for higher system reliability and lower latency, new approaches may be desirable to improve call successful rate by managing measurement reports and handling handover procedures, in order to enhance UE mobility, to satisfy consumer demand, and to improve user experience in wireless communications.
SUMMARY
The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.
According to an example, a method related to managing measurement reports and handover procedures in a wireless communications system is provided. In an aspect, the method includes receiving, by a user equipment (UE) from a network entity, a message including information of single radio voice call continuity (SRVCC) capability of the network entity, storing, by the UE, the information of the SRVCC capability of the network entity, receiving, by the UE from the network entity, a request for a measurement report. The method further includes determining, by the UE and in response to receiving  the request, whether an SRVCC is supported by the network entity based on the stored information, and transmitting, by the UE to the network entity, the measurement report in response to a determination that the SRVCC is supported by the network entity.
In another aspect of the disclosure, an apparatus for managing measurement reports and handover procedures in wireless communications is provided. The apparatus may include a receiver configured to receive signals, a transmitter configured to transmit signals, a memory configured to store instructions, and at least one processor communicatively coupled with the receiver, the transmitter, and the memory. In an example, the at least one processor is configured to execute the instructions to receive, via the receiver, a message from a network entity including information of SRVCC capability of the network entity, store the information of the SRVCC capability of the network entity, receive, via the receiver, a request for a measurement report from the network entity, determine, in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information, and transmit, via the transmitter, the measurement report to the network entity in response to a determination that the SRVCC is supported by the network entity.
In yet another aspect of the disclosure, an apparatus for managing measurement reports and handover procedures in wireless communications is provided. The apparatus may include means for receiving a message from a network entity including information of SRVCC capability of the network entity, means for storing the information of the SRVCC capability of the network entity, means for receiving a request for a measurement report from the network entity, means for determining, in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information, and means for transmitting the measurement report to the network entity in response to a determination that the SRVCC is supported by the network entity.
In a further aspect of the disclosure, a computer-readable medium (e.g., a non-transitory computer-readable medium) storing computer code executable by a processor for managing measurement reports and handover procedures in wireless communications is provided. The computer-readable medium may include code for receiving a message from a network entity including information of SRVCC capability of the network entity, code for storing the information of the SRVCC capability of the network entity, code for receiving a request for a measurement report from the network entity, code for determining, in response to receiving the request, whether an SRVCC is supported by the  network entity based on the stored information, and code for transmitting the measurement report to the network entity in response to a determination that the SRVCC is supported by the network entity.
To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.
BRIEF DESCRIPTION OF THE DRAWINGS
In order to facilitate a fuller understanding of aspects described herein, reference is now made to the accompanying drawings, in which like elements are referenced with like numerals. These drawings should not be construed as limiting the present disclosure, but are intended to be illustrative only.
FIG. 1 is a block diagram illustrating a first example of a wireless communications system including a user equipment (UE) communicating with one or more network entities to perform measurement reports and handover procedures, according to one or more of the presently described aspects.
FIG. 2 is a block diagram illustrating a second example of a wireless communications system including multiple UEs for communicating with one or more network entities to perform measurement reports and handover procedures, according to one or more of the presently described aspects.
FIG. 3 is a block diagram illustrating an example of a UE communicating with a base station or network entity to perform measurement reports and handover procedures in an access network, according to one or more of the presently described aspects.
FIG. 4 is a flowchart of an example procedure for managing measurement reports and handover, according to one or more of the presently described aspects.
FIG. 5 is a flowchart of an example method for managing measurement reports and handover procedures, according to one or more of the presently described aspects.
DETAILED DESCRIPTION
The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.
In wireless communications, for example, in the fourth generation (4G) or an LTE network, when the signal quality for a voice call (e.g., a voice over LTE (VoLTE) ) using the LTE network is poor (e.g., the signal condition or quality is below a threshold) but a legacy (e.g., the second generation (2G) or the third generation (3G) ) network is sufficient to handle the voice call (e.g., the signal condition or quality is at or above a threshold) , one or more measurements (e.g., event B2 measurements) may be triggered and transmitted from a user equipment (UE) to the LTE network. For example, the UE may transmit one or more measurement reports to at least a base station in the LTE network. In this case, the LTE network or network operator may use Single Radio Voice Call Continuity (SRVCC) to handover the voice call from a packet-switching (PS) network (e.g., LTE) to a circuit-switching (CS) network (e.g., 2G/3G) . In some examples, SRVCC is a voice call continuity operation between Internet Protocol (IP) multimedia subsystem (IMS) over PS access network (s) and CS access network (s) for calls that are anchored in IMS, when the UE is capable of transmitting and/or receiving on only one of the access networks at a given time. In an example, a Single Radio Voice Call Continuity before ringing phase (bSRVCC) may be used to handover the voice call from a PS network to a CS network before an alerting stage.
In some implementations, both the UE and a network entity in the network (e.g., a base station in an LTE network) may need to support SRVCC to perform SRVCC operations between the UE and the network entity, and the SRVCC capability of the network entity may be sent to the UE from the network entity (e.g., via 183 or 180 commands) . In an example, if the UE supports SRVCC operations, the UE may configure the SRVCC capability of the UE to “supported, ” which indicates that the UE has the  capability to perform SRVCC operations. Similarly, if the network entity supports SRVCC operations, the network entity may configure the SRVCC capability of the network entity to “supported, ” which indicates that the network entity has the capability to perform SRVCC operations. On the other hand, if the UE does not support SRVCC operations, the UE may configure the SRVCC capability of the UE to “not supported, ” which indicates that the UE does not have the capability to perform SRVCC operations. Similarly, if the network entity does not support SRVCC operations, the network entity may configure the SRVCC capability of the network entity to “not supported, ” which indicates that the network entity does not have the capability to perform SRVCC operations.
However, during field operations, some problems may occur. For example, if the network entity does not support SRVCC but requests event B2 measurement before sending commands (e.g., 183 or 180 commands) , a failure of handover or a call drop may happen (e.g., if the measurement meets the requirement for handover) . In another example, if a precondition (e.g., a network resource reservation acknowledgement procedure) is not supported by either the network entity or the UE, SRVCC procedures may not be performed.
As such, new or improved solutions may be required to solve the above-mentioned problems. For example, to avoid the problems and reduce call drops, an enhanced solution is that the UE stores the network SRVCC capability received from a previous call (e.g., the last call) and uses the stored information of the network SRVCC capability in one or more subsequence calls. In addition, this new solution may reduce the time for a UE handover from PS to CS by using the stored information, rather than waiting for new messages or commands (e.g., 183 commands with the network SRVCC capability) that may take, for example, two to three seconds to arrive the UE.
The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known components are shown in block diagram form in order to avoid obscuring such concepts.
Several aspects of telecommunication systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.
By way of example, an element, or any portion of an element, or any combination of elements may be implemented with a “processing system” that includes one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPSs) , central processing units (CPUs) , application processors, digital signal processors (DSPs) , reduced instruction set computing (RISC) processors, systems on a chip (SoC) , baseband processors, field programmable gate arrays (FPGAs) , programmable logic devices (PLDs) , state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.
Accordingly, in one or more aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD) , laser disc, optical  disc, digital versatile disc (DVD) , and floppy disk where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. In some aspects, the computer-readable media may be non-transitory or include a non-transitory computer-readable storage medium.
The following description provides examples, and is not limiting of the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the disclosure. Various examples may omit, substitute, or add various procedures or components as appropriate. For instance, the methods described may be performed in an order different from that described, and various steps may be added, omitted, or combined. Also, features described with respect to some examples may be combined in other examples.
Various aspects or features will be presented in terms of systems that can include a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems can include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. A combination of these approaches can also be used.
Described herein are various aspects related to wireless communications, for example, in a 4G LTE network (or a 5G NR network) , and in particular, techniques for handling SRVCC or handover procedures. In an aspect, as discussed above, when the signal quality for a voice call (e.g., a VoLTE call) using an LTE system is not good (e.g., signal condition below a threshold) , but a 2G or 3G system is good enough to handle the voice call, event B2 measurement (s) may be triggered and transmitted from a UE to the network. In some examples, an SRVCC procedure may be used to handover the voice call from a PS network (e.g., an LTE network) to a CS network (e.g., a 2G or 3G network) . For example, a bSRVCC procedure may be used to handover the voice call from a PS network to a CS network before an alerting stage. In some cases, the SRVCC procedure may include at least one of a basic SRVCC procedure, an SRVCC procedure during (or in) ringing phase or alerting stage (aSRVCC) , a bSRVCC procedure, an enhanced SRVCC (eSRVCC) procedure, a video SRVCC (vSRVCC) procedure, or a mid-call  SRVCC procedure (e.g., an SRVCC procedure that allows both active and held calls to be transferred from VoLTE to CS) .
In some examples, both the UE and the network (e.g., an LTE network) may need to support bSRVCC. In an aspect, in order to perform bSRVCC operations, the bSRVCC capability of the network (or a base station in the network) may be sent to the UE from the network (e.g., via 183 or 180 commands) . In a first example, if the network does not support bSRVCC but requests event B2 measurement before sending commands (e.g., 183 or 180 commands) , a failure of handover or a call drop may happen (e.g., if the measurement meets the requirement for handover) . In a second example, if a precondition is not supported by either the network or the UE, bSRVCC procedures may not be performed.
In an aspect, the UE updates the information of the network capability at the UE, after each call and/or after each time the UE receives information of the network capability (e.g., the SRVCC or bSRVCC capability of the network) from the network (e.g., via a message, an indication, or one or more commands such as 180 or 183 commands) . In one implementation, to solve the problem in the first example discussed above is to delay or block the event B2 measurement report until the 183 commands are received by the UE. And for the problem in the second example discussed above, there is no known solution in current implementations. As such, a new or improved solution may be desirable to solve both problems mentioned above, and reduce the latency (e.g., the time for receiving the 183 commands) .
In some implementations, an SRVCC procedure may be used for handover and may contain two steps. In the first step (e.g., as shown in 3GPP Technical Specification 36.331, chapter 5.5.5) , a UE may send a measurement report to the network (e.g., an LTE network) , and the content for the measurement report is for event B2. For example, as shown in 3GPP Technical Specification 36.331, chapter 5.5.4.8, event B2 is a trigger event when serving (from the current serving cell) becomes worse or lower than a first threshold and inter radio access technology (RAT) neighbour cell (or base station) becomes better or higher than a second threshold. In the second step, when the network side receives the event B2 measurement report, an SRVCC procedure (e.g., a bSRVCC procedure) may be triggered.
In various aspects discussed herein, a new procedure or method is proposed that the UE may proceed to perform the first step (event B2 measurement report) by  identifying or using the stored network bSRVCC capability from a previous voice call, or delay (or block) the first step (event B2 measurement report) until the UE knows or obtains the network SRVCC capability after checking the stored network bSRVCC capability. There may be multiple advantages using the new procedure discussed herein. For example, the new procedure for SRVCC may enhance successful rate for voice call (e.g., a VoLTE call) handovers. In another example, the new procedure or method may reduce the time for a UE handover from a PS network to a CS network by using the stored information rather than waiting for new 183 commands (with the network bSRVCC capability) that may take additional time (e.g., 2 to 3 seconds) to arrive at the UE.
In some examples, the UE may store the network bSRVCC capability received from the last call and may use the stored information of the network bSRVCC capability in subsequence calls. In an aspect, the new procedure or method may include triggering a measurement report based on the network bSRVCC capability stored in the UE and obtained from a previous call. If the network supports bSRVCC, the new procedure may handover the UE to a CS network faster (e.g., 2 to 3 seconds) than a conventional bSRVCC procedure or solution. Additionally, the new procedure may support bSRVCC even when a precondition is not supported by either the network or UE (e.g., precondition is disabled) . In some cases, a precondition may be that a participant (e.g., a UE or a base station) reserves network resources before a session initiation protocol (SIP) session begins or before continuing with the SIP session. In an example, a precondition may be that a UE is registered to an LTE network, before an SIP session.
In an aspect, for example, the procedures, methods, techniques, or schemes discussed herein may be implemented by or reside in hardware or software at the UE or network entity (e.g., a base station) . In another aspect, for example, some of the procedures, methods, techniques, or schemes discussed herein may be within the limits of specifications of various wireless communication standards (e.g., 3GPP standards) .
Each of the aspects described above are performed or implemented in connection with FIGs. 1-5, which are described in more detail below.
Referring to FIG. 1, in an aspect, a wireless communication system 100 includes at least one UE 12 in communication coverage of at least one network entity 14 or network entity 20. The UE 12 may communicate with a network via the network entity 14 or network entity 20. In some aspects, multiple UEs including the UE 12 may be in communication coverage with one or more network entities, including the network entity  14 and the network entity 20. In an aspect, the network entity 14 or network entity 20 may be a base station, such as an eNB in an LTE network. Although various aspects are described in relation to a UMTS or LTE network, similar principles may be applied in other wireless wide area networks (WWAN) . The wireless network may employ a scheme where multiple base stations may transmit on a channel. In an example, the UE 12 may transmit and/or receive wireless communications (e.g., messages or signals used for handover or cell selection) to and/or from the network entity 14 and/or the network entity 20. For example, the UE 12 may be actively communicating with network entity 14 and/or network entity 20, for example, to report or delay reporting measurements, and/or perform one or more handover procedures (e.g., an SRVCC procedure) .
In some aspects, the UE 12 may also be referred to by those skilled in the art (as well as interchangeably herein) as a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a terminal, a user agent, a mobile client, a client, or some other suitable terminology. The UE 12 may be a cellular phone, a personal digital assistant (PDA) , a wireless modem, a wireless communication device, a handheld device, a tablet computer, a laptop computer, a cordless phone, a wireless local loop (WLL) station, a global positioning system (GPS) device, a multimedia device, a video device, a digital audio player (e.g., MP3 player) , a camera, a game console, a wearable computing device (e.g., a smart-watch, smart-glasses, a health or fitness tracker, etc. ) , an appliance, a sensor, a vehicle communication system, a medical device, a vending machine, a device for IoT (e.g., a NB-IoT device) , an eMTC device, or any other similar functioning device.
In some examples, the network entity 14 or network entity 20 may be referred to as a base station, a base transceiver station, a radio base station, a radio transceiver, a basic service set (BSS) , an extended service set (ESS) , a NodeB, eNodeB, Home NodeB, a Home eNodeB, a gNB or some other suitable terminology. The coverage area for a base station may be divided into sectors making up only a portion of the coverage area (not shown) . The wireless communications system 100 may include the network entity 14 and/or network entity 20 of different types (e.g., macro, micro, and/or pico base stations) . The network entity 14 or network entity 20 may utilize different radio technologies, such as cellular and/or Wireless Local Area Network (WLAN) radio access  technologies (RAT) . The network entity 14 or network entity 20 may be associated with the same or different access networks or operator deployments. The coverage areas of the network entity 14 or network entity 20, including the coverage areas of the same or different types of the network entity 14 or network entity 20, utilizing the same or different radio technologies, and/or belonging to the same or different access networks, may overlap. Furthermore, the network entity 14 or network entity 20 may be substantially any type of component that may communicate with UE 12 to provide wireless network access at the UE 12.
According to the present aspects, the UE 12 may include one or more processors 103 and a memory 130 that may operate in combination with a handover management component 40. The handover management component 40 may include a network SRVCC capability component 42, storing component 44, SRVCC support determining component 46, and/or measurement reporting component 48.
In some examples, the handover management component 40 may be configured to perform one or more measurement reporting and/or handover procedures as discussed herein in connection with SRVCC. In an aspect, the network SRVCC capability component 42 may be configured to obtain information or determine the SRVCC capability of the  network entity  14 or 20. For example, the network SRVCC capability component 42 may be configured to receive a message including information of SRVCC capability of the network entity from the  network entity  14 or 20. In an aspect, the storing component 44 may be configured to record or store the obtained network SRVCC capability in UE memory (e.g., the memory 130) as discussed herein. In another aspect, the SRVCC support determining component 46 may be configured to determine whether or not the  network entity  14 or 20 supports SRVCC based on the stored network SRVCC capability. In another aspect, the measurement reporting component 48 may be configured to report the UE measurements (e.g., event B2 measurement (s) ) , based on the determined network SRVCC capability that is stored at the UE 12, as discussed below referring to FIG. 4.
In some aspects, the handover management component 40 may be communicatively coupled with a transceiver 106, which may include a receiver 32 for receiving and processing radio frequency (RF) signals, and a transmitter 34 for processing and transmitting RF signals. The processor 103 may be communicatively coupled with the transceiver 106 and memory 130 via at least one bus 110.
The receiver 32 may include hardware, firmware, and/or software code executable by a processor for receiving data, the code comprising instructions and being stored in a memory (e.g., computer-readable medium) . The receiver 32 may be, for example, an RF receiver. In an aspect, the receiver 32 may receive signals transmitted by the UE 12, one or more other UEs 12 and/or one or more network entities (e.g., the network entity 14 or network entity 20) . The receiver 32 may obtain measurements of the signals. For example, the receiver 32 may determine signal-to-noise ratio (SNR) , RSRP, etc.
The transmitter 34 may include hardware, firmware, and/or software code executable by a processor for transmitting data, the code comprising instructions and being stored in a memory (e.g., computer-readable medium) . The transmitter 34 may be, for example, a RF transmitter.
In an aspect, the one or more processors 103 may include a modem 108 that uses one or more modem processors. The various functions related to the handover management component 40 may be included in the modem 108 and/or processor (s) 103 and, in an aspect, may be executed by a single processor, while in other aspects, different ones of the functions may be executed by a combination of two or more different processors. For example, in an aspect, the one or more processors 103 may include any one or any combination of a modem processor, or baseband processor, or digital signal processor, or transmit processor, or transceiver processor associated with the transceiver 106. In particular, the one or more processors 103 may implement components included in the handover management component 40, including the network SRVCC capability component 42, storing component 44, SRVCC support determining component 46, and/or measurement reporting component 48.
The handover management component 40, network SRVCC capability component 42, storing component 44, SRVCC support determining component 46, and/or measurement reporting component 48, may include hardware, firmware, and/or software code executable by a processor for managing measurement reports and performing handover procedures. For example, the hardware may include, for example, a hardware accelerator, or specialized processor. In an aspect, the term “component” as used herein may be one of the parts that make up a system, may be hardware, firmware, and/or software, and may be divided into other components.
Moreover, in an aspect, the UE 12 may include an RF front end 104 and the transceiver 106 for receiving and transmitting radio transmissions, for example, wireless  communications 26. For example, transceiver 106 may transmit or receive one or more signals. The transceiver 106 may measure a received pilot signal in order to determine signal quality (e.g., based on RSRP, RSRQ, or RSSI) and for providing feedback to the network entity 14 or network entity 20. For example, the transceiver 106 may communicate with the modem 108 to transmit messages generated by the handover management component 40 and to receive messages and forward them to the handover management component 40.
The RF front end 104 may be communicatively couple with one or more antennas 102 and may include one or more low-noise amplifiers (LNAs) 141, one or  more switches  142, 143, one or more power amplifiers (PAs) 145, and one or more filters 144 for transmitting and receiving RF signals. In an aspect, the components of the RF front end 104 may be communicatively coupled with the transceiver 106 (e.g., via one or more communication links or buses 110) . The transceiver 106 may be communicatively coupled with one or more modems 108 and/or processor 103.
In an aspect, the LNA 141 may amplify a received signal at a desired output level. In an aspect, each LNA 141 may have a specified minimum and maximum gain values. In an aspect, the RF front end 104 may use one or  more switches  142, 143 to select a particular LNA 141 and its specified gain value based on a desired gain value for a particular application. In an aspect, the RF front end 104 may provide measurements (e.g., Ec/Io) and/or applied gain values to the handover management component 40.
The one or more PA (s) 145 may be used by the RF front end 104 to amplify a signal for an RF output at a desired output power level. In an aspect, each PA 145 may have a specified minimum and maximum gain values. In an aspect, the RF front end 104 may use one or  more switches  143, 146 to select a particular PA 145 and a specified gain value of the PA 145 based on a desired gain value for a particular application.
The one or more filters 144 may be used by the RF front end 104 to filter a received signal to obtain an input RF signal. Similarly, in an aspect, for example, a respective filter 144 may be used to filter an output from a respective PA 145 to produce an output signal for transmission. In an aspect, each filter 144 may be communicatively coupled with a specific LNA 141 and/or PA 145. In an aspect, the RF front end 104 may use one or  more switches  142, 143, 146 to select a transmit or receive path using a specified filter 144, LNA, 141, and/or PA 145, based on a configuration as specified by the transceiver 106 and/or processor 103.
The transceiver 106 may be configured to transmit and receive wireless signals through an antenna 102 via the RF front end 104. In an aspect, the transceiver 106 may be tuned to operate at specified frequencies such that the UE 12 may communicate with, for example, the network entity 14 or network entity 20. In an aspect, for example, the modem 108 may configure the transceiver 106 to operate at a specified frequency and power level based on the UE configuration of the UE 12 and communication protocol used by the modem 108.
In an aspect, the modem 108 may be a multiband-multimode modem, which may process digital data and communicate with the transceiver 106 such that the digital data is sent and received using the transceiver 106. In an aspect, the modem 108 may be multiband and be configured to support multiple frequency bands for a specific communications protocol. In an aspect, the modem 108 may be multi-mode and be configured to support multiple operating networks and communications protocols. In an aspect, the modem 108 may control one or more components of the UE 12, or the network entity 14 or 20 (e.g., RF front end 104, transceiver 106) , to perform handover or SRVCC procedures or enable transmission and/or reception of signals based on a specified modem configuration. In an aspect, the modem configuration may be based on the mode of the modem and the frequency band in use. In another aspect, the modem configuration may be based on UE configuration information associated with the UE 12 as provided by the network during handovers or SRVCC procedures.
In some aspects, the UE 12 may further include memory 130, such as for storing data used herein and/or local versions of applications or the handover management component 40 and/or one or more subcomponents of the handover management component 40 being executed by the processor (s) 103. The memory 130 may include any type of computer-readable medium usable by a computer or processor (s) 103, such as random access memory (RAM) , read only memory (ROM) , tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof. In an aspect, for example, the memory 130 may be a computer-readable storage medium that stores one or more computer-executable codes defining handover management component 40 and/or one or more of the subcomponents of the handover management component 40, and/or data associated therewith, when the UE 12 and/or the network entity 14 or network entity 20 is operating the processor (s) 103 to execute the handover management component 40 and/or one or more subcomponents of the handover  management component 40. In another aspect, for example, the memory 130 may be a non-transitory computer-readable storage medium.
Referring to FIG. 2, a diagram illustrates an example of a wireless communications system 200, in accordance with aspects described herein. In some examples, the wireless communications system 200 may include the wireless communications system 100 in FIG. 1, and may include a plurality of network entities 14 and/or 20 (e.g., base stations, gNBs, or WLAN network entity) , a number of UEs 12, and a core network 230. In an aspect, one or more UEs 12 may include the handover management component 40 configured to manage measurements and handover procedures. The handover management component 40 may be configured to perform at least some aspects of the techniques or methods described above in wireless communications (e.g., in an LTE network) . Some of the  network entity  14 or 20 may communicate with the UEs 12 under the control of a base station controller (not shown) , which may be part of the core network 230 or the network entity 14 or the network entity 20 (e.g., a base station or a gNB) in various examples.
In an aspect, the  network entity  14 or 20 may communicate control or system information and/or user data with the core network 230 through backhaul links 232. In some cases, the  network entity  14 or 20 may communicate, either directly or indirectly, with each other over backhaul links 234, which may be wired or wireless communication links. The wireless communications system 200 may support operation on multiple carriers (waveform signals of different frequencies) . Multi-carrier transmitters may transmit modulated signals simultaneously on the multiple carriers. For example, each communication link 225 (e.g., wireless communications 26 in FIG. 1) may be a multi-carrier signal modulated according to the various radio technologies described above. Each modulated signal may be sent on a same or different carrier and may carry control or system information (e.g., reference signals, control channels, etc. ) , overhead information, data, etc.
In some examples, the  network entity  14 or 20 may wirelessly communicate with the UEs 12 via one or more antennas 102. Each of the  network entity  14 or 20 may provide communication coverage for a respective coverage area 210. In some examples, the  network entity  14 or 20 may be referred to as a base station, a NodeB, an eNodeB, a Home NodeB, a Home eNodeB, a gNB, or an access point. In some cases, at least a portion of the wireless communications system 200 may be configured to operate on a  spatial multiplexing (e.g., multiple-input and multiple-output (MIMO) ) scheme in which one or more of the UEs 12 and one or more of the  network entity  14 or 20 may be configured to support transmissions on closed-loop MIMO and/or open-loop MIMO scheme.
In network communication systems using 4G (e.g., LTE/LTE-A) or similar communication technologies, the terms evolved Node B (eNodeB or eNB) or gNB may be used to describe the  network entity  14 or 20, though concepts described herein may be applied to other types of network entity in other types of communication technologies. For example, the wireless communications system 200 may be a 4G LTE network in which different types of network entity provide coverage for various geographical regions. For example, each  network entity  14 or 20 may provide communication coverage for a macro cell, a pico cell, a femto cell, and/or other types of cell. Small cells such as pico cells, femto cells, and/or other types of cells may include low power nodes or LPNs. A macro cell may cover a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access by UEs 12 with service subscriptions with the network provider. A small cell may cover a relatively smaller geographic area and may allow unrestricted access by UEs 12 with service subscriptions with the network provider, for example, and in addition to unrestricted access, may also provide restricted access by UEs 12 having an association with the small cell (e.g., UEs in a closed subscriber group (CSG) , UEs for users in the home, and the like) . A base station for a macro cell may be referred to as a macro base station. A base station for a small cell may be referred to as a small cell base station. A base station may support one or multiple (e.g., two, three, four, and the like) cells.
In some aspects, the core network 230 may communicate with the base stations or  other network entity  14 or 20 via one or more backhaul links 232 (e.g., S1 interface, etc. ) . The  network entity  14 or 20 may also communicate with one another, e.g., directly or indirectly via backhaul links 234 (e.g., X2 interface, etc. ) and/or via backhaul links 232 (e.g., through core network 230) . The backhaul links 232 may be wired or wireless communication links.
In some examples, the UEs 12 may be dispersed throughout the wireless communications system 200, and each UE 12 may be stationary or mobile (e.g., in a low mobility mode) . The UE 12 may be referred to by those skilled in the art as a suitable terminology discussed herein. The UE 12 may be able to communicate with macro base  stations, small cell base stations, relays, and the like. The UE 12 may be able to communicate over different access networks, such as cellular or other WWAN access networks, or WLAN access networks.
The communication links 225 (e.g., wireless communications 26 in FIG. 1) shown in wireless communications system 200 may include uplink transmissions from the UE 12 to the  network entity  14 or 20, and/or downlink transmissions (e.g., a message with 183 or 180 commands) from the  network entity  14 or 20 to the UE 12. The downlink transmissions may also be called forward link transmissions while the uplink transmissions may also be called reverse link transmissions. The communication links 225 may carry transmissions of each hierarchical layer which, in some examples, may be multiplexed in the communication links 225. The UEs 12 may be configured to collaboratively communicate with  multiple network entity  14 or 20 through, for example, MIMO, carrier aggregation (CA) , Coordinated Multi-Point (CoMP) , or other schemes. MIMO techniques use multiple antennas on the  network entity  14 or 20 and/or multiple antennas on the UE 12 to transmit multiple data streams. The MIMO techniques may include closed-loop MIMO and/or open-loop MIMO scheme. Carrier aggregation (CA) may utilize two or more component carriers (CCs) on a same or different serving cell for data transmission. CoMP may include techniques for coordination of transmission and reception by a number of  network entity  14 or 20 to improve overall transmission quality for UEs 12 as well as increasing network and spectrum utilization.
Referring to FIG. 3, a block diagram illustrates an example of a base station 310 (e.g., the network entity 14 or 20) in communication with a UE 350 (e.g., the UE 12) in an access network (e.g., the wireless communications system 100 and/or 200) . In the downlink, upper layer packets from the core network are provided to a controller/processor 375. The controller/processor 375 implements the functionality of the L2 layer. In the downlink, the controller/processor 375 provides header compression, ciphering, packet segmentation and reordering, multiplexing between logical and transport channels, and radio resource allocations to the UE 350 based on various priority metrics. The controller/processor 375 is also responsible for HARQ operations, retransmission of lost packets, and signaling to the UE 350.
The transmit (TX) processor 316 implements various signal processing functions for the L1 layer (i.e., physical layer) . The signal processing functions includes coding and interleaving to facilitate forward error correction (FEC) at the UE 350 and mapping  to signal constellations based on various modulation schemes (e.g., binary phase-shift keying (BPSK) , quadrature phase-shift keying (QPSK) , M-phase-shift keying (M-PSK) , M-quadrature amplitude modulation (M-QAM) ) . The coded and modulated symbols are then split into parallel streams. Each stream is then mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., pilot signal) in the time and/or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to produce a physical channel carrying a time domain OFDM symbol stream. The OFDM stream is spatially precoded to produce multiple spatial streams. Channel estimates from a channel estimator 374 may be used to determine the coding and modulation scheme, as well as for spatial processing. The channel estimate may be derived from a reference signal and/or channel condition feedback transmitted by the UE 350. Each spatial stream is then provided to a different antenna 320 via a separate transmitter 318TX. Each transmitter 318TX modulates an RF carrier with a respective spatial stream for transmission.
At the UE 350, each receiver 354RX receives a signal through a respective antenna 352. Each receiver 354RX recovers information modulated onto an RF carrier and provides the information to the receive (RX) processor 356. The RX processor 356 implements various signal processing functions of the L1 layer. The RX processor 356 performs spatial processing on the information to recover any spatial streams destined for the UE 350. If multiple spatial streams are destined for the UE 350, they may be combined by the RX processor 356 into a single OFDM symbol stream. The RX processor 356 then converts the OFDM symbol stream from the time-domain to the frequency domain using a Fast Fourier Transform (FFT) . The frequency domain signal comprises a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, and the reference signal, is recovered and demodulated by determining the most likely signal constellation points transmitted by the base station 310. These soft decisions may be based on channel estimates computed by the channel estimator 358. The soft decisions are then decoded and deinterleaved to recover the data and control signals that were originally transmitted by the base station 310 on the physical channel. The data and control signals are then provided to the controller/processor 359.
The controller/processor 359 implements the L2 layer. The controller/processor may be associated with a memory 360 that stores program codes and data. The memory 360 may be referred to as a computer-readable medium. In the uplink, the  controller/processor 359 provides demultiplexing (DEMUX) between transport and logical channels, packet reassembly, deciphering, header decompression, control signal processing to recover upper layer packets from the core network. The upper layer packets are then provided to a data sink 362, which represents all the protocol layers above the L2 layer. Various control signals may be provided to the data sink 362 for L3 processing. The controller/processor 359 may be responsible for error detection using an acknowledgement (ACK) and/or negative acknowledgement (NACK) protocol to support HARQ operations. In addition, the UE 350 may include a handover management component 40 configured to manage measurement reports and handover procedures. Though the handover management component 40 is shown as communicatively coupled with controller/processor 359, substantially any processor of the UE 350 may provide the functions of the handover management component 40 and/or the related components described herein (e.g., in conjunction with controller/processor 359, memory 360, or otherwise) . For example, TX processor 368 and/or RX processor 356 may additionally or alternatively provide one or more functions of the handover management component 40, as described herein.
In the uplink, a data source 367 is used to provide upper layer packets to the controller/processor 359. The data source 367 represents all protocol layers above the L2 layer. Similar to the functionality described in connection with the downlink transmission by the base station 310, the controller/processor 359 implements the L2 layer for the user plane and the control plane by providing header compression, ciphering, packet segmentation and reordering, and multiplexing between logical and transport channels based on radio resource allocations by the base station 310. The controller/processor 359 is also responsible for HARQ operations, retransmission of lost packets, and signaling to the base station 310.
Channel estimates derived by a channel estimator 358 from a reference signal or feedback transmitted by the base station 310 may be used by the TX processor 368 to select the appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial streams generated by the TX processor 368 are provided to different antenna 352 via separate transmitters 354TX. Each transmitter 354TX modulates an RF carrier with a respective spatial stream for transmission.
The uplink transmission is processed at the base station 310 in a manner similar to that described in connection with the receiver function at the UE 350. Each receiver  318RX receives a signal through its respective antenna 320. Each receiver 318RX recovers information modulated onto an RF carrier and provides the information to a RX processor 370. The RX processor 370 may implement the L1 layer.
The controller/processor 375 implements the L2 layer. The controller/processor 375 may be associated with a memory 376 that stores program codes and data. The memory 376 may be referred to as a computer-readable medium. In the uplink, the controller/processor 375 provides demultiplexing (DEMUX) between transport and logical channels, packet reassembly, deciphering, header decompression, control signal processing to recover upper layer packets from the UE 350. Upper layer packets from the controller/processor 375 may be provided to the core network. The controller/processor 375 may be responsible for error detection using an ACK and/or NACK protocol to support HARQ operations.
Referring to FIG. 4, in an aspect, an example of managing measurement reports and handling SRVCC procedure is illustrated in a flowchart 400. In this example, if a Proxy Call Session Control Function (PCSCF) address of the current call is the same as a previous call, the network shall behave or configure the same as the previous call. In this case, the SRVCC (e.g., bSRVCC) capability may be kept the same during the calls under the same network. An example procedure of the present disclosure is discussed in more details below and shown in FIG. 4.
In an aspect, at block 402, after identifying a newly-associated PCSCF address, a UE, such as UE 12, may configure or set the SRVCC (e.g., bSRVCC) capability of the network (e.g., network entity 14 or network entity 20) to “not supported. ”
After the first call, at block 404, UE 12 may obtain the SRVCC (e.g., bSRVCC) capability of the network from a message, an indication, or one or more commands (e.g., 183 and/or 180 commands) that is received from network entity 14 or network entity 20, and may record or store the SRVCC capability of the network at UE 12 (e.g., in memory 130) .
In an aspect, at block 406, in a following voice call (e.g., a new VoLTE call) , if the network (e.g., network entity 14 or network entity 20) requests event B2 measurement (s) , at block 408, UE 12 may check or identify the SRVCC capability that stored in UE 12, for example, UE 12 may determine whether SRVCC (e.g., bSRVCC) is supported by the  network entity  14 or 20, based on stored information at UE 12.
In an example, if UE 12 determines that SRVCC is supported by the  network entity  14 or 20 based on stored information (e.g., SRVCC capability of the network) at UE 12, then at block 410, UE 12 may report the event B2 measurement to the  network entity  14 or 20.
In another example, if UE 12 determines that SRVCC is not supported by the  network entity  14 or 20 based on stored information (e.g., SRVCC capability of the network) at UE 12, then at block 412, UE 12 may not report the event B2 measurement to the  network entity  14 or 20. For instance, UE 12 may delay or block sending event B2 measurement to the  network entity  14 or 20. In some cases, the UE 12 may delay or block sending event B2 measurement to the  network entity  14 or 20 until the UE 12 receives or obtains updated SRVCC capability of the  network entity  14 or 20. For example, the updated SRVCC capability of the  network entity  14 or 20 may indicate that the  network entity  14 or 20 supports SRVCC (e.g., bSRVCC) .
In some examples, UE 12 may passively wait if UE 12 determines that SRVCC is not supported by the  network entity  14 or 20 based on the stored information (e.g., SRVCC capability of the network) at the UE 12, until the UE 12 receives the updated information. In some cases, a timer may or may not be configured when UE 12 is waiting for the updated information. In an aspect, the UE 12 may receive the updated information from the network (e.g., from network entity 14 or 20) in one or more messages or signals. For instance, UE 12 may receive an INVITE message for a mobile terminated (MT) call, or make a mobile originated (MO) call successfully over VoLTE that has an SIP message (e.g., including 183 or 180 commands) , or make an MO call and failed but received a SIP message having 183 commands. In any of the above discussed calls, the updated information of the network SRVCC capability may be available or sent to UE 12.
Referring to FIG. 5, in an operational aspect, a UE, such as UE 12 in FIG. 1, may perform one or more aspects of a method 500 (or the SRVCC procedure illustrated in the flowchart 400) for managing one or more measurement reports and handover procedures in a wireless communications system (e.g., a 2G/3G or LTE system) . For example, one or more of the processors 103, memory 130, modem 108, transceiver 106, handover management component 40, network SRVCC capability component 42, storing component 44, SRVCC support determining component 46, and/or measurement reporting component 48, may be configured to perform one or more aspects of the method 500.
In an aspect, at block 502, the method 500 may include receiving, by a user equipment (UE) from a network entity, a message including information of SRVCC capability of the network entity. In an aspect, for example, the handover management component 40, and/or network SRVCC capability component 42, e.g., in conjunction with one or more of the processors 103, memory 130, modem 108, and/or transceiver 106, may be configured to receive (via transceiver 106) a message including information of the SRVCC capability of the  network entity  14 or 20. In some examples, the message may be received by the UE 12 after a first call, and the message may include an indication, or one or more commands such as 180 or 183 commands, to indicate the SRVCC capability of the  network entity  14 or 20.
In another aspect, at block 504, the method 500 may include storing, by the UE, the information of the SRVCC capability of the network entity. In an aspect, for example, the handover management component 40, and/or storing component 44, e.g., in conjunction with one or more of the processors 103, memory 130, modem 108, and/or transceiver 106, may be configured to store the information of the SRVCC capability of the  network entity  14 or 20. In an example, the storing component 44 of the UE 12 may record or store the information of network SRVCC capability (e.g., bSRVCC capability) in the memory 130, and the information may be used in one or more subsequence calls.
In an aspect, at block 506, the method 500 may include receiving, by the UE from the network entity, a request for a measurement report. In an aspect, for example, the handover management component 40, and/or measurement reporting component 48, e.g., in conjunction with one or more of the processors 103, memory 130, modem 108, and/or transceiver 106, may be configured to receive (via the transceiver 106) a request for a measurement report from the  network entity  14 or 20. In an example, a second or following call (e.g., a new VoLTE call) may be initiated, and the network (e.g., network entity 14 or 20) may send the UE 12 a request for reporting event B2 measurement (s) .
In another aspect, at block 508, the method 500 may include determining, by the UE and in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information. In an aspect, for example, the handover management component 40, storing component 44, and/or SRVCC support determining component 46, e.g., in conjunction with one or more of the processors 103, memory 130, modem 108, and/or transceiver 106, may be configured to check the network SRVCC capability in response to receiving the request (at block 506) , and to determine whether  the network (e.g., network entity 14 or 20) supports SRVCC procedures based on the stored information (at block 504) . For example, the UE 12 may check the memory 130 for the stored information about network SRVCC capability of the  network entity  14 or 20.
In an aspect, at block 510, the method 500 may include transmitting, by the UE to the network entity, the measurement report in response to a determination that the SRVCC is supported by the network entity. In an aspect, for example, the handover management component 40, SRVCC support determining component 46, and/or measurement reporting component 48, e.g., in conjunction with one or more of the processors 103, memory 130, modem 108, and/or transceiver 106, may be configured to transmit (via transceiver 106) the measurement report to the  network entity  14 or 20, in response to a determination that the SRVCC is supported by the  network entity  14 or 20. In an example, the stored information about network SRVCC capability may indicate that the  network entity  14 or 20 supports SRVCC (e.g., bSRVCC) procedures.
In another aspect, at block 512, the method 400 may optionally include delaying, by the UE, sending the measurement report in response to a determination that the SRVCC is not supported by the network entity. In an aspect, for example, the handover management component 40, SRVCC support determining component 46, and/or measurement reporting component 48, e.g., in conjunction with one or more of the processors 103, memory 130, modem 108, and/or transceiver 106, may be configured to delay sending the measurement report in response to a determination that the SRVCC is not supported by the network entity. In an example, the stored information about network SRVCC capability may indicate that the  network entity  14 or 20 does not support SRVCC (e.g., bSRVCC) procedures. In this case, the UE 12 may be configured to delay or block sending the measurement report until the UE 12 obtains updated information of the network SRVCC capability. For example, the UE 12 may receive updated information of the network SRVCC capability indicating that the SRVCC is now supported by the  network entity  14 or 20. In some cases, the updated information of the network SRVCC capability may be received via a new message or indication, for example, one or more 183 or 180 commands in a new message sent from the  network entity  14 or 20.
For purposes of simplicity of explanation, the methods discussed herein are shown and described as a series of acts, it is to be understood and appreciated that the method (and further methods related thereto) is/are not limited by the order of acts, as some acts  may, in accordance with one or more aspects, occur in different orders and/or concurrently with other acts from that shown and described herein. For example, it is to be appreciated that a method could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a method in accordance with one or more features described herein.
Several aspects of a telecommunications system have been presented with reference to a 4G LTE system. As those skilled in the art will readily appreciate, various aspects described throughout this disclosure may be extended to other telecommunication systems, network architectures and communication standards, for example, 5G NR.
By way of example, various aspects may be extended to other communication systems such as High Speed Downlink Packet Access (HSDPA) , High Speed Uplink Packet Access (HSUPA) , High Speed Packet Access Plus (HSPA+) and TD-CDMA. Various aspects may also be extended to systems employing Long Term Evolution (LTE) (in FDD, TDD, or both modes) , LTE-Advanced (LTE-A) (in FDD, TDD, or both modes) , CDMA2000, Evolution-Data Optimized (EV-DO) , Ultra Mobile Broadband (UMB) , IEEE 802.11 (Wi-Fi) , IEEE 802.16 (WiMAX) , IEEE 802.20, Ultra-Wideband (UWB) , Bluetooth, and/or other suitable systems. The actual telecommunication standard, network architecture, and/or communication standard employed will depend on the specific application and the overall design constraints imposed on the system.
It is to be understood that the specific order or hierarchy of steps in the methods disclosed is an illustration of exemplary processes. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the methods may be rearranged. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented unless specifically recited therein.
The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language of the claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” Unless specifically stated otherwise, the term “some” refers to one or more. A phrase referring to “at least  one of” a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover: a; b; c; a and b; a and c; b and c; and a, b and c. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.
Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage medium may be any available medium that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, 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 means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (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 medium. Disk and disc, as used herein, include compact disc (CD) , laser disc, optical disc, digital versatile disc (DVD) , floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media.
The previous description of the disclosure is provided to enable a person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the common principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Furthermore, although elements of the described aspects and/or embodiments may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated. Additionally, all or a portion of any aspect and/or embodiment may be utilized with all or a portion of any other aspect and/or embodiment, unless stated otherwise. Thus, the disclosure is not to be limited to the examples and  designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
SOME FURTHER EXAMPLE EMBODIMENTS
An example method of wireless communications, comprising: receiving, by a user equipment (UE) from a network entity, a message including information of single radio voice call continuity (SRVCC) capability of the network entity; storing, by the UE, the information of the SRVCC capability of the network entity; receiving, by the UE from the network entity, a request for a measurement report; determining, by the UE and in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information; and transmitting, by the UE to the network entity, the measurement report in response to a determination that the SRVCC is supported by the network entity.
The above example method, further comprising: delaying, by the UE, sending the measurement report in response to a determination that the SRVCC is not supported by the network entity.
The above example method, wherein the delaying comprises delaying sending the measurement report until the UE obtains updated information of the SRVCC capability of the network entity.
The above example method, wherein the updated information indicates that the SRVCC is supported by the network entity.
One or more of the above example methods, wherein the measurement report is an event B2 measurement report.
One or more of the above example methods, wherein the SRVCC is an SRVCC before ringing phase or before an alerting stage (bSRVCC) .
One or more of the above example methods, wherein the message comprises an indication, or one or more commands including the information.
One or more of the above example methods, wherein the request for the measurement report is triggered by a voice over Long Term Evolution (VoLTE) call.
An example apparatus for wireless communications, comprising: a received configured to receive signals; a transmitter configured to transmit signals; a memory configured to store instructions; and at least one processor communicatively coupled with the receiver, the transmitter, and the memory, wherein the at least one processor is configured to execute the instructions to: receive, via the receiver, a message from a  network entity including information of single radio voice call continuity (SRVCC) capability of the network entity; store the information of the SRVCC capability of the network entity; receive, via the receiver, a request for a measurement report from the network entity; determine, in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information; and transmit, via the transmitter, the measurement report to the network entity in response to a determination that the SRVCC is supported by the network entity.
The above example apparatus, wherein the at least one processor is configured to execute further instructions to delay sending the measurement report in response to a determination that the SRVCC is not supported by the network entity.
The above example apparatus, wherein the at least one processor is configured to execute further instructions to delay sending the measurement report until the apparatus obtains updated information of the SRVCC capability of the network entity.
The above example apparatus, wherein the updated information indicates that the SRVCC is supported by the network entity.
One or more of the above example apparatuses, wherein the measurement report is an event B2 measurement report.
One or more of the above example apparatuses, wherein the SRVCC is an SRVCC before ringing phase or before an alerting stage (bSRVCC) .
One or more of the above example apparatuses, wherein the message comprises an indication, or one or more commands including the information.
One or more of the above example apparatuses, wherein the request for the measurement report is triggered by a voice over Long Term Evolution (VoLTE) call.
An example apparatus for wireless communications, comprising: means for receiving, by a user equipment (UE) from a network entity, a message including information of single radio voice call continuity (SRVCC) capability of the network entity; means for storing, by the UE, the information of the SRVCC capability of the network entity; means for receiving, by the UE from the network entity, a request for a measurement report; means for determining, by the UE and in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information; and means for transmitting, by the UE to the network entity, the measurement report in response to a determination that the SRVCC is supported by the network entity.
The above example apparatus, further comprising: means for delaying, by the UE, sending the measurement report in response to a determination that the SRVCC is not supported by the network entity.
The above example apparatus, wherein the means for delaying comprises means for delaying sending the measurement report until the UE obtains updated information of the SRVCC capability of the network entity.
The above example apparatus, wherein the updated information indicates that the SRVCC is supported by the network entity.
One or more of the above example apparatuses, wherein the measurement report is an event B2 measurement report.
One or more of the above example apparatuses, wherein the SRVCC is an SRVCC before ringing phase or before an alerting stage (bSRVCC) .
One or more of the above example apparatuses, wherein the message comprises an indication, or one or more commands including the information.
One or more of the above example apparatuses, wherein the request for the measurement report is triggered by a voice over Long Term Evolution (VoLTE) call.
An example non-transitory computer-readable medium storing computer code executable by a processor for wireless communications, comprising: code for receiving, by a user equipment (UE) from a network entity, a message including information of single radio voice call continuity (SRVCC) capability of the network entity; code for storing, by the UE, the information of the SRVCC capability of the network entity; code for receiving, by the UE from the network entity, a request for a measurement report; code for determining, by the UE and in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information; and code for transmitting, by the UE to the network entity, the measurement report in response to a determination that the SRVCC is supported by the network entity.
The above example non-transitory computer-readable medium, further comprising: code for delaying, by the UE, sending the measurement report in response to a determination that the SRVCC is not supported by the network entity.
The above example non-transitory computer-readable medium, wherein the code for delaying comprises code for delaying sending the measurement report until the UE obtains updated information of the SRVCC capability of the network entity.
The above example non-transitory computer-readable mediums, wherein the updated information indicates that the SRVCC is supported by the network entity.
One or more of the above example non-transitory computer-readable mediums, wherein the measurement report is an event B2 measurement report.
One or more of the above example non-transitory computer-readable mediums, wherein the SRVCC is an SRVCC before ringing phase or before an alerting stage (bSRVCC) .
One or more of the above example non-transitory computer-readable mediums, wherein the message comprises an indication, or one or more commands including the information.
One or more of the above example non-transitory computer-readable mediums, wherein the request for the measurement report is triggered by a voice over Long Term Evolution (VoLTE) call.

Claims (30)

  1. A method of wireless communications, comprising:
    receiving, by a user equipment (UE) from a network entity, a message including information of single radio voice call continuity (SRVCC) capability of the network entity;
    storing, by the UE, the information of the SRVCC capability of the network entity;
    receiving, by the UE from the network entity, a request for a measurement report;
    determining, by the UE and in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information; and
    transmitting, by the UE to the network entity, the measurement report in response to a determination that the SRVCC is supported by the network entity.
  2. The method of claim 1, further comprising:
    delaying, by the UE, sending the measurement report in response to a determination that the SRVCC is not supported by the network entity.
  3. The method of claim 2, wherein the delaying comprises delaying sending the measurement report until the UE obtains updated information of the SRVCC capability of the network entity.
  4. The method of claim 3, wherein the updated information indicates that the SRVCC is supported by the network entity.
  5. The method of claim 1, wherein the measurement report is an event B2 measurement report.
  6. The method of claim 1, wherein the SRVCC is an SRVCC before ringing phase or before an alerting stage (bSRVCC) .
  7. The method of claim 1, wherein the message comprises an indication, or one or more commands including the information.
  8. The method of claim 1, wherein the request for the measurement report is triggered by a voice over Long Term Evolution (VoLTE) call.
  9. An apparatus for wireless communications, comprising:
    a receiver configured to receive signals;
    a transmitter configured to transmit signals;
    a memory configured to store instructions; and
    at least one processor communicatively coupled with the receiver, the transmitter, and the memory, wherein the at least one processor is configured to execute the instructions to:
    receive, via the receiver, a message from a network entity including information of single radio voice call continuity (SRVCC) capability of the network entity;
    store the information of the SRVCC capability of the network entity;
    receive, via the receiver, a request for a measurement report from the network entity;
    determine, in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information; and
    transmit, via the transmitter, the measurement report to the network entity in response to a determination that the SRVCC is supported by the network entity.
  10. The apparatus of claim 9, wherein the at least one processor is configured to execute further instructions to delay sending the measurement report in response to a determination that the SRVCC is not supported by the network entity.
  11. The apparatus of claim 10, wherein the at least one processor is configured to execute further instructions to delay sending the measurement report until the apparatus obtains updated information of the SRVCC capability of the network entity.
  12. The apparatus of claim 11, wherein the updated information indicates that the SRVCC is supported by the network entity.
  13. The apparatus of claim 9, wherein the measurement report is an event B2 measurement report.
  14. The apparatus of claim 9, wherein the SRVCC is an SRVCC before ringing phase or before an alerting stage (bSRVCC) .
  15. The apparatus of claim 9, wherein the message comprises an indication, or one or more commands including the information.
  16. The apparatus of claim 9, wherein the request for the measurement report is triggered by a voice over Long Term Evolution (VoLTE) call.
  17. An apparatus for wireless communications, comprising:
    means for receiving a message from a network entity including information of single radio voice call continuity (SRVCC) capability of the network entity;
    means for storing the information of the SRVCC capability of the network entity;
    means for receiving a request for a measurement report from the network entity;
    means for determining, in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information; and
    means for transmitting the measurement report to the network entity in response to a determination that the SRVCC is supported by the network entity.
  18. The apparatus of claim 17, further comprising:
    means for delaying sending the measurement report in response to a determination that the SRVCC is not supported by the network entity.
  19. The apparatus of claim 18, wherein the means for delaying comprises means for delaying sending the measurement report until the apparatus obtains updated information of the SRVCC capability of the network entity.
  20. The apparatus of claim 19, wherein the updated information indicates that the SRVCC is supported by the network entity.
  21. The apparatus of claim 17, wherein the measurement report is an event B2 measurement report.
  22. The apparatus of claim 17, wherein the SRVCC is an SRVCC before ringing phase or before an alerting stage (bSRVCC) .
  23. The apparatus of claim 17, wherein the message comprises an indication, or one or more commands including the information.
  24. The apparatus of claim 17, wherein the request for the measurement report is triggered by a voice over Long Term Evolution (VoLTE) call.
  25. A non-transitory computer-readable medium storing computer code executable by a processor for wireless communications, comprising:
    code for receiving a message from a network entity including information of single radio voice call continuity (SRVCC) capability of the network entity;
    code for storing the information of the SRVCC capability of the network entity;
    code for receiving a request for a measurement report from the network entity;
    code for determining, in response to receiving the request, whether an SRVCC is supported by the network entity based on the stored information; and
    code for transmitting the measurement report to the network entity in response to a determination that the SRVCC is supported by the network entity.
  26. The non-transitory computer-readable medium of claim 25, further comprising:
    code for delaying sending the measurement report in response to a determination that the SRVCC is not supported by the network entity.
  27. The non-transitory computer-readable medium of claim 26, wherein the code for delaying comprises code for delaying sending the measurement report until the apparatus obtains updated information of the SRVCC capability of the network entity.
  28. The non-transitory computer-readable medium of claim 27, wherein the updated information indicates that the SRVCC is supported by the network entity.
  29. The non-transitory computer-readable medium of claim 25, wherein the measurement report is an event B2 measurement report.
  30. The non-transitory computer-readable medium of claim 25, wherein the SRVCC is an SRVCC before ringing phase or before an alerting stage (bSRVCC) .
PCT/CN2019/079249 2018-03-29 2019-03-22 Techniques for handling single radio voice call continuity WO2019184816A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNPCT/CN2018/081069 2018-03-29
PCT/CN2018/081069 WO2019183879A1 (en) 2018-03-29 2018-03-29 Techniques for handling single radio voice call continuity

Publications (1)

Publication Number Publication Date
WO2019184816A1 true WO2019184816A1 (en) 2019-10-03

Family

ID=68059183

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/CN2018/081069 WO2019183879A1 (en) 2018-03-29 2018-03-29 Techniques for handling single radio voice call continuity
PCT/CN2019/079249 WO2019184816A1 (en) 2018-03-29 2019-03-22 Techniques for handling single radio voice call continuity

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/081069 WO2019183879A1 (en) 2018-03-29 2018-03-29 Techniques for handling single radio voice call continuity

Country Status (1)

Country Link
WO (2) WO2019183879A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102647693A (en) * 2011-02-18 2012-08-22 中兴通讯股份有限公司 Method and system for realizing radio voice call continuity (RVCC)
CN104756548A (en) * 2014-06-30 2015-07-01 华为技术有限公司 Switching method, base station, and mobile management body
CN104994542A (en) * 2015-07-08 2015-10-21 华为技术有限公司 Control method of inter-system detection events and user equipment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102647693A (en) * 2011-02-18 2012-08-22 中兴通讯股份有限公司 Method and system for realizing radio voice call continuity (RVCC)
CN104756548A (en) * 2014-06-30 2015-07-01 华为技术有限公司 Switching method, base station, and mobile management body
CN104994542A (en) * 2015-07-08 2015-10-21 华为技术有限公司 Control method of inter-system detection events and user equipment

Also Published As

Publication number Publication date
WO2019183879A1 (en) 2019-10-03

Similar Documents

Publication Publication Date Title
CN111034277B (en) Techniques for mode selection and cell selection/reselection
US10651990B2 (en) Techniques for improving URLLC communications in new radio
US10798627B2 (en) User equipment centric mobility (UECM) in radio resource control (RRC) dedicated mode
EP2992731B1 (en) Method and apparatus for device to device relay selection
RU2534033C2 (en) Method and apparatus for inferring user equipment interference suppression capability from measurements report
US10462713B2 (en) Techniques for handover procedure management
JP6490813B2 (en) Techniques for managing radio access inter-technology handover for high gain user equipment
US11012112B2 (en) Techniques for flexible resource allocation
JP6189425B2 (en) Feedback to improve rate prediction in bursty interference
CN109644182B (en) UE network mobility during incoming IMS call setup to a preferred network
US10117280B2 (en) Techniques for receiving packets over aggregated connections in wireless communications
JP2017526246A (en) Handover management in air-to-ground wireless communication
US9237485B2 (en) Deferred measurement control reading of system information block (SIB) messages
US11102676B2 (en) Techniques for using downlink control information in new radio
US20160286447A1 (en) Techniques for maintaining data continuity in offloading wireless communications
US9307452B2 (en) Method and apparatus for decreasing LTE re-acquisition delay in S102-less CSFB
US20170019934A1 (en) Buffer status reporting during multimedia service call setup
WO2019184816A1 (en) Techniques for handling single radio voice call continuity

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: 19777778

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19777778

Country of ref document: EP

Kind code of ref document: A1