Interworking between 3GPP and non-3GPP networks for call handover

Abstract

An apparatus configured to generate, for transmission to a first network, a first message comprising a handover capability request relating to the first network and a second network, wherein the first network is a cellular network and the second network is a non-cellular network, process a second message indicating the first network supports a handover capability between the first network and the second network, determine a handover from the first network or the second network to the network is to be performed, determine, based on the second message, that handover from the one of the first network or the second network to the other one of the first network or the second network is allowed and perform a handover from the one of the first network or the second network to the other one of the first network or the second network.

Description

Interworking Between 3GPP and Non-3GPP Networks for Call HandoverInventors: Krisztian Kiss, Sridhar Prakasam and Sudeep Manithara VamananBackground

[0001] User equipment (UE) may encounter a variety of network types as a user moves or as network conditions change. Transitions between networks may be referred to as handovers. Efficient and seamless handover operations are critical for both call continuity and user experience. Handovers with respect to voice over Wi-Fi (VoWiFi) to and from voice over long term evolution (VoLTE) and voice over new radio (VoNR) remain in need of further definition.Summary

[0002] Some example embodiments are related to an apparatus having processing circuitry configured to generate, for transmission to a first network, a first message comprising a handover capability request relating to the first network and a second network, wherein the first network is a cellular network and the second network is a non-cellular network, process, based on signaling from the first network, a second message indicating the first network supports a handover capability between the first network and the second network, determine a handover from the one of the first network or the second network to an other one of the first network or the second network is to be performed, determine, based on the second message, that handover from the one of the first network or the second network to the other one of the first network or the second network is allowed and perform a handover from the one of the first network or thesecond network to the other one of the first network or the second network.

[0003] Other example embodiments are related to a method for receiving a first message comprising a handover capability request relating the first network and a second network, wherein the first network is a cellular network and the second network is a non-cellular network and transmitting a second message indicating the first network supports a handover capability for calls between the first network and the second network.Brief Description of the Drawings

[0004] Fig. 1 shows an example network arrangement according to various example embodiments.

[0005] Fig. 2 shows an example UE according to various example embodiments.

[0006] Fig. 3 shows an example base station, according to various example embodiments.

[0007] Fig. 4 shows a call flow related to VoLTE handovers to VoWiFi according to various example embodiments.

[0008] Fig. 5 shows a call flow related to VoWiFi handovers to VoLTE according to various example embodiments.

[0009] Fig. 6 shows a call flow related to handovers from VoNR to VoWiFi according to various example embodiments.

[0010] Fig. 7 shows a method diagram that is a generalized method applicable to the call flows of Figs. 4-6 according to various example embodiments.Detailed Description

[0011] The example embodiments may be further understood with reference to the following description and the related appended drawings, wherein like elements are provided with the same reference numerals. The example embodiments relate to interworking between 3GPP access and non-3GPP access to support handover of calls.

[0012] The example embodiments are described with regard to a user equipment (UE) . However, reference to a UE is merely provided for illustrative purposes. The example embodiments may be utilized with any electronic component that may establish a connection to a network and is configured with the hardware, software, and / or firmware to exchange information and data with the network. Therefore, the UE as described herein is used to represent any electronic component.

[0013] The example embodiments are also described with reference to a 5G New Radio (NR) network, a Long Term Evolution (LTE) network and a Wireless Local Area Network (WLAN) . In these examples, the 5G NR network and the LTE network are considered to be the 3GPP access networks and the WLAN is considered to be the non-3GPP access network. However, the example embodiments may also be implemented for use with other types of 3GPP networks (e.g., 5G-advanced, 6G, etc. ) and other types of non- 3GPP networks (e.g. , 802.11xx networks, 802.16xx networks, Wi-Fi networks, HotSpot networks, etc. ) , e.g., any networks thatsupport interworking between 3GPP networks and non-3GPP networks. Throughout this description, 3GPP networks may also be referred to as cellular network and non-3GPP networks may also be referred to as non-cellular networks.

[0014] Throughout this description, the term "call" may refer to either a voice call and / or video call. Additionally, the term call may refer to communications in which an audio (voice only) call transitions to a video call, as well as video calls that transition to audio-only calls. Calls may transition between video calls and audio-only based on user input with an application running on the UE .

[0015] Throughout this description it will be described that a UE will determine that a handover between a first network and a second network should be initiated. In one example provided below, the handover is initiated based on the UE measuring signals transmitted by the first network and / or the second network. However, there may be other reasons for the UE to initiate a handover. The exact reason for the UE initiating the handover is outside the scope of this disclosure, e.g., the example embodiments may be used regardless of the reason for initiating the handover.

[0016] Various issues exist with the interworking policies of 3rdGeneration Partnership Project (3GPP) networks (e.g., Long Term Evolution (LTE) , New Radio (NR) , etc., ) and non-3GPP (e.g., Wi-Fi) . Typically, an individual UE manufacturer customizes the handover (HO) logic for VoWiFi to / from VoLTE / VoNR without any standardized signaling or logic. Existing VoWiFi implementations (specifically with respect to VoLTE HO) are managed by a UE . TheUE has local knowledge about the interworking between the non- 3GPP access and the 3GPP access to the evolved packet core (EPC) . Based on this knowledge, a UE may manage handover between the 3GPP and non-3GPP networks.

[0017] The global deployment of the 5G core (5GC) has increased the complexity of network interoperability dramatically, considering the interplay between Non-3GPP InterWorking Function (N3IWF) / Trusted Non-3GPP Gateway Function (TNGF) , VoNR, evolved Packet Data Gateway (ePDG) / EPC and VoLTE. This complexity is further increased considering the various interworking policies implemented in different Virtual Public Land Mobile Networks (VPLMNs) along with other local policy changes. A standardized signaling and logic is necessary to manage handovers between 3GPP and non-3GPP voice calls and provide a better experience for users. The example embodiments relate to signaling and logic to better facilitate handover between 3GPP and non-3GPP voice calls.

[0018] A UE may be best suited to make a handover decision because the UE knows local network conditions of both the 3GPP and non-3GPP networks. To make this decision though, the UE needs to know the interworking policy of the network (s) in advance to avoid handover failures and call drops. It is proposed herein that the network should provide the interworking policy to the UE between 3GPP and non-3GPP access including the support of handover capabilities. The support indication may include various factors such as user subscription, local configuration, network congestion, VPLMN deployment, etc.

[0019] The interworking policies of the example embodiments may not differ for each packet data network (PDN) connection / protocol data unit (PDU) session. Instead, the network may provide the policy to the UE during initial EPC attach procedures and / or 5GC registration procedures. In the 5G case, an Access and Mobility Management Function (AMF) may receive both a 3GPP and non-3GPP interworking policy from a unified data manager (UDM) . The AMF may then provide the policy to the UE in the registration accept message. In the 4G / LTE case, the mobility management entity (MME) may receive the policy from a home subscriber server and provide it to the UE in an attach accept message. These procedures will be discussed in greater detail with respect to the call flow diagrams in Figs. 4-6.

[0020] The 3GPP and non-3GPP interworking policies of the example embodiments may be adjusted dynamically by a network operator during the lifetime of a particular registration / network attachment. In the 5GC case, this may be achieved using the UE Configuration Update procedure. In the LTE case, this may be achieved using the tracking area update procedure. The example embodiments may use non-access stratum (NAS) mobility management signaling to avoid impacts to Internet Key Exchange version 2 (IKEv2) signaling messages. The example embodiments may also include 3GPP and non-3GPP interworking policies in broadcast information. As described above, the example embodiments relate to operations and logic for enhanced 3GPP and non-3GPP call handover.

[0021] Fig. 1 shows an example network arrangement 100 according to various example embodiments. The example network arrangement 100 includes a UE 110. The UE 110 may be any type ofelectronic component that is configured to communicate via a network, e.g., mobile phones, tablet computers, desktop computers, smartphones, embedded devices, wearables, Internet of Things (loT) devices, etc. An actual network arrangement may include any number of UEs being used by any number of users. Thus, the example of a single UE 110 is merely provided for illustrative purposes.

[0022] The UE 110 may be configured to communicate with one or more networks. In the example of the network arrangement 100, the network with which the UE 110 may wirelessly communicate may include components of one or more of a fifth generation (5G) new radio (NR) radio access network (RAN) 120, a long-term evolution (LTE) RAN 122 and a wireless local area network (WLAN) 124. However, the UE 110 may also communicate with other types of networks (e.g., 5G cloud RAN, a next generation RAN (NG-RAN) , a legacy cellular network, 6G RAN, etc.) and the UE 110 may also communicate with networks over a wired connection. Therefore, the UE 110 may have a 5G NR chipset to communicate with the NR RAN 120, an LTE chipset to communicate with the LTE RAN 122 and an ISM chipset to communicate with the WLAN 124.

[0023] The 5G NR-RAN 120 and the LTE-RAN 122 may be portions of cellular networks that may be deployed by cellular providers (e.g., Verizon, AT&T, T-Mobile, etc.) . These networks 120, 122 may include, for example, cells or base stations (Node Bs, eNodeBs, HeNBs, eNBS, gNBs, gNodeBs, macrocells, microcells, small cells, femtocells, etc.) that are configured to send and receive traffic from UEs that are equipped with the appropriate cellular chip set. The WLAN 124 may include any type of wirelesslocal area network (Wi-Fi, Hot Spot, IEEE 802. llx networks, etc . ) .

[0024] Any association procedure may be performed for the UE 110 to connect to the 5G NR-RAN 120 or the LTE-RAN 122. For example, as discussed above, the 5G NR-RAN 120 may be associated with a particular cellular provider where the UE 110 and / or the user thereof has a contract and credential information (e.g., stored on a SIM card) . Upon detecting the presence of the 5G NR-RAN 120, the UE 110 may transmit the corresponding credential information to associate with the 5G NR-RAN 120. More specifically, the UE 110 may associate with a specific cell or base station (e.g., gNB 120A) . For access to LTE services, a similar association procedure may be performed with the LTE RAN 122 via a specific cell or base station (e.g., eNB 122A) . However, as mentioned above, reference to the 5G NR-RAN 120 and the LTE-RAN 122 is merely for illustrative purposes, the example embodiments may apply to any type of RAN.

[0025] The network arrangement 100 also includes a cellular core network 130, the Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 may be considered to be the interconnected set of components that manages the operation and traffic of the cellular network. It may include the evolved packet core (EPC) for the LTE network and / or the fifth generation core (5GC) for the 5G network. The cellular core network 130 also manages the traffic that flows between the cellular network and the Internet 140. The IMS 150 may be generally described as an architecture for delivering multimedia services to the UE 110 using the IP protocol. The IMS 150 may communicate with the cellular corenetwork 130 and the Internet 140 to provide the multimedia services to the UE 110. The network services backbone 160 is in communication either directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 may be generally described as a set of components (e.g., servers, network storage arrangements, etc.) that implement a suite of services that may be used to extend the functionalities of the UE 110 in communication with the various networks .

[0026] Fig. 2 shows an example UE 110 according to various example embodiments. The UE 110 will be described with regard to the network arrangement 100 of Fig. 1. The UE 110 may represent any electronic device and may include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. The other components 230 may include, for example, an audio input device, an audio output device, a battery that provides a limited power supply, a data acquisition device, ports to electrically connect the UE 110 to other electronic devices, sensors to detect conditions of the UE 110, etc.

[0027] The processor 205 may be configured to execute a plurality of engines for the UE 110. For example, the engines may include a handover engine 235 for performing operations related to handing over a call to / from 3GPP / non-3GPP networks. These example operations will be described in greater detail below .

[0028] The above referenced engine being an application(e.g., a program) executed by the processor 205 is only anexample . The functionality associated with the engines may also be represented as a separate incorporated component of the UE 110 or may be a modular component coupled to the UE 110 , e . g . , an integrated circuit with or without firmware . For example , the integrated circuit may include input circuitry to receive signals and processing circuitry to process the signals and other information . The engines may also be embodied as one application or separate applications . In addition, in some UEs , the functionality described for the processor 205 is split among two or more processors such as a baseband processor and an applications processor . The example embodiments may be implemented in any of these or other configurations of a UE .

[0029] The memory arrangement 210 may be a hardware component configured to store data related to operations performed by the UE 110 . The display device 215 may be a hardware component configured to show data to a user while the I / O device 220 may be a hardware component that enables the user to enter inputs . The display device 215 and the I / O device 220 may be separate components or integrated together such as a touchscreen . The transceiver 225 may be a hardware component configured to establish a connection with the 5G-NR RAN 120 . Accordingly, the transceiver 225 may operate on a variety of di f ferent frequencies or channels ( e . g . , set of consecutive frequencies ) .

[0030] The transceiver 225 includes circuitry configured to transmit and / or receive signals ( e . g . , control signals , data signals ) . Such signals may be encoded with information implementing any one of the methods described herein . The processor 205 may be operably coupled to the transceiver 225 and configured to receive from and / or transmit signals to thetransceiver 225. The processor 205 may be configured to encode and / or decode signals (e.g., signaling from a base station of a network) for implementing any one of the methods described herein .

[0031] Fig. 3 shows an example base station 300 according to various example embodiments. The base station 300 may represent the gNB 120A or any other access node (such as an eNB) through which the UE 110 may establish a connection and manage network operations .

[0032] The base station 300 may include a processor 305, a memory arrangement 310, an input / output (I / O) device 315, a transceiver 320, and other components 325. The other components 325 may include, for example, an audio input device, an audio output device, a battery, a data acquisition device, ports to electrically connect the base station 300 to other electronic devices and / or power sources, etc.

[0033] The processor 305 may be configured to execute a plurality of engines for the base station 300. For example, the engines may include a handover engine 330 for configuring the UE 110 with interworking policies related to 3GPP and non-3GPP handover policies. These example operations are described in greater detail below.

[0034] The memory arrangement 310 may be a hardware component configured to store data related to operations performed by the base station 300. The I / O device 315 may be a hardware component or ports that enable a user to interact with the base station 300. The transceiver 320 may be a hardware component configuredto exchange data with the UE 110 and any other UE in the network arrangement 100. The transceiver 320 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . Therefore, the transceiver 320 may include one or more components (e.g., radios) to enable the data exchange with the various networks and UEs.

[0035] The transceiver 320 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals) . Such signals may be encoded with information implementing any one of the methods described herein. The processor 305 may be operably coupled to the transceiver 320 and configured to receive from and / or transmit signals to the transceiver 320. The processor 305 may be configured to encode and / or decode signals (e.g., signaling from a UE) for implementing any one of the methods described herein.

[0036] Fig. 4 shows a call flow 400 related to VoLTE handovers to VoWiFi according to various example embodiments. The call flow 400 features the UE 110, a 3GPP RAN 404 which, in this case, may be considered to be the LTE RAN 122. Also shown in the call flow 400 is a 3GPP-CN 406 (e.g., the evolved packet core (EPC) of an LTE network) which manages the traffic that flows between the cellular network and the Internet. Further shown in the call flow 400 is the ePDG 402 which secures data transmission between the UE 110 connected to the 3GPP RAN 404 and the non-3GPP access such as Wi-Fi (e.g., the WLAN 124) .

[0037] In 410, the UE 110 transmits an attach / tracking area update (TAU) request to the 3GPP-CN 406. The attach request may be transmitted when the UE 110 is initially entering thecoverage area of the LTE-RAN 122, when the UE 110 is turned on, or when the UE 110 is switched out of airplane mode. The TAU request may be transmitted as the UE moves within the coverage area of the LTE-RAN 122. The attach / TAU request 410 may include a request for the LTE-RAN 122 network capability of interworking between non-3GPP and 3GPP for voice and / or video calls. In 412, the 3GPP-CN 406 transmits a corresponding attach / TAU accept message to the UE 110. The message 412 may include the LTE-RAN 122 network capability of interworking between the 3GPP access network and the non-3GPP access network for voice and / or video calls .

[0038] In 414, it may be considered that the UE 110 is actively participating in a VoLTE call. Throughout this description it may be considered that the UE 110 includes the necessary hardware and software to perform calls (e.g., the UE 110 includes one or more phone applications allowing the UE 110 to initiate calls (e.g., mobile originating (MO) ) and / or receive calls (e.g., mobile terminating (MT) ) .

[0039] In 415, the UE 110 may determine that a handover from LTE (e.g., VoLTE) to Wi-Fi (e.g., VoWiFi) should be initiated. The UE 110 may still be engaged in the VoLTE call at this time. The handover may be based on signal measurements of the 3GPP RAN 404 and a Wi-Fi network. For the purposes of this example, it may be considered that the UE 110 knows the Wi-Fi network (e.g., the UE 110 has already associated with the WLAN 124) or the WiFi network is an open network capable of connecting with uncredentialed UEs.

[0040] In 416, the UE 110 determines whether the network indicated handover support for VoLTE to non-3GPP access in the message 412. If the network does not support the handover, the call remains on VoLTE. In the example of Fig. 4, the call flow diagram 400 proceeds under the assumption that the network indicated handover support. While the operations 415 and 416 are depicted as occurring at separate times, they may also occur simultaneously .

[0041] In 418, the UE 110 successfully establishes an Internet Protocol Secure (IPSec) Tunnel with the ePDG 402. One of skill in the art will appreciate that an IPSec Tunnel is a secure networking protocol that authenticates and encrypts data packets to provide encrypted communications between two or more devices. Encryption and authentication procedures are used for secure calls on public Wi-Fi networks.

[0042] In 420, the UE 110 performs a handover of the call from the 3GPP network (e.g., LTE RAN 122) to the Wi-Fi network (e.g., WLAN 124) and is now operating on a VoWifi call.

[0043] Fig. 5 shows a call flow 500 related to VoWiFi handovers to VoLTE according to various example embodiments. The call flow 500 may be the reverse of the handover call flow 400 of Fig. 4. The call flow 500 features the UE 110, an ePDG 502, a 3GPP-RAN 504, and a 3GPP CN 506. These network elements are substantially similar to the ePDG 402, the 3GPP-CN 406, and 3GPP RAN 404 shown and described with reference to Fig. 4.

[0044] In 508, it may be considered that the UE 110 is actively participating in a VoWiFi call. As described above,this may be on a known and credentialed network, or it may be on a public network.

[0045] The UE 110 may also be in a coverage area of an LTE network (e.g. , LTE RAN 122) . The UE 110 may be in the coverage area when the VoWiFi call starts or the UE 110 may enter the LTE coverage area after the VoWiFi has been initiated. In 510, the UE 110 transmits an Attach / TAU request to the 3GPP CN 506. The request 510 may include an indication of VoWiFi capability.

[0046] In 512, the 3GPP CN 506 transmits an attach / TAU accept message to the UE 110. The message 512 may include the network capability of interworking between 3GPP and non-3GPP for calls.

[0047] In 513, the UE 110 determines a handover from Wi-Fi(e.g., non-3GPP access) to VoLTE (e.g., 3GPP access) should be initiated .

[0048] In 514 the UE 110 determines whether the network indicated handover support for non-3GPP access (e.g. , Wi-Fi) to VoLTE in the message 512. If the network does not support the handover, the call remains on VoWiFi. In the example of Fig. 5, it may be considered that the call flow diagram 500 proceeds under the assumption that the network indicated handover support. While the operations 513 and 514 are depicted as occurring at separate times, they may also occur simultaneously.

[0049] In 516, the UE 110 transmits a PDN connectivity request message to the 3GPP CN 506. Included in the message 516 is an indication that the UE is requesting a handover from VoWiFi to VoLTE.

[0050] In 518, the UE 110 and the 3GPP GN 506 begin to establish radio bearers. One of skill in the art will appreciate that radio bearers comprise signaling radio bearers (SRB) which are used for control signaling, and data radio bearers (DRB) which carry user data.

[0051] In 520, the 3GPP GN 506 transmits an activate default EPS bearer context request message to the UE 110. In 522, the UE 110 transmits an activate default EPS bearer context accept message to the 3GPP GN 506.

[0052] In 524, the UE 110 completes the handover from VoWiFi to VoLTE. The call that began on VoWiFi in 508 now continues as a VoLTE call.

[0053] Fig. 6 shows a call flow 600 related to handovers from VoNR to VoWiFi according to various example embodiments. The call flow 600 features the UE 110, an ePDG / N3IWF 602, a 3GPP-RAN 604, and a 3GPP GN 606. In this example, the 3GPP-RAN 604 may be considered to be the NR-RAN 120 and the 3GPP GN 606 may be considered to be the 5G core (5GC) . The ePDG / N3IWF 602 may include both ePDG functionality and N3IWF functionality to facilitate handovers from a 5GC network.

[0054] In 608, the UE 110 transmits a registration reguest to the 3GPP GN 606. The message 608 may include an indication of VoWiFi capability.

[0055] In 610, the 3GPP GN 606 transmits a registration accept message to the UE 110. The message 610 may include anindication of network capability of interworking between non- 3GPP and 3GPP networks for calls.

[0056] As described above, the 3GPP and non-3GPP interworking policy may be dynamically updated during the lifetime of the registration / network attachment. An example of such an update is provided in Fig. 6. For example, in 612, the 3GPP GN 606 transmits a configuration update command to the UE 110. The update command 612 may include an indication of network capability of interworking between non-3GPP and 3GPP networks for calls. The UE 110 may update its networking configuration based on the received command 612.

[0057] In 614, it may be considered that the UE 110 is actively participating in a VoNR call via the 3GPP RAN 604.

[0058] In 615, the UE 110 determines a handover from VoNR to VoWiFi should be initiated. In 616, the UE 110 determines whether the network supports handover from VoNR to VoWiFi, based on at least one of the message 610 or the update command 612.The call flow diagram 600 proceeds under the assumption that the handover is supported. While the determination 615 and the determination 616 are depicted as occurring at separate times, they may also occur simultaneously.

[0059] In 618, the UE 110 successfully establishes an IPSec Tunnel with the ePDG / N3IWF 602. In 620, the handover from VoNR to VoWiFi is complete.

[0060] Fig. 7 shows a method diagram 700 that is a generalized method applicable to the call flows of Figs. 4-6according to various example embodiments. The method diagram 700 is described from the perspective of the UE 110.

[0061] In 702, the UE 110 requests handover capabilities from the 3GPP network for a serving and a target network. The handover may be between a 3GPP network (e.g., LTE, NR, 5G- advanced, 6G, etc. ) and a non-3GPP network (e.g., WiFi) . In a first example, the handover request may be from a non-3GPP network to a 3GPP network . In the first example, the serving network may be a Wi-Fi network (e.g. , VoWiFi) and the target network may be the 3GPP LTE network (e.g. , VoLTE) . In a second example, the handover request may be from a 3GPP network to a non-3GPP network. In the second example, the serving network may be a 3GPP LTE network (e.g., VoLTE) and the target network may be a Wi-Fi network (e.g. , VoWiFi) . Other possible initial conditions are possible, in accordance with aspects described in Figs. 4, 5, and 6.

[0062] Returning to the first example, in 704, the UE 110 receives the handover capabilities of the 3GPP network based on the request 702 (for example, with an Attach accept message) .

[0063] In 705, the UE 110 begins a call (voice / video) on the serving network. In this example, the call begins on Wi-Fi (e.g., VoWiFi over WLAN 124) .

[0064] In 706, the UE 110 determines if a handover is needed from the serving network (e.g. , WLAN 124) to the target network (e.g., LTE-RAN 122) . If the answer to 706 is no, the UE 110 proceeds to the end and does not continue the method diagram700, e.g., the call continues on the WiFi network. If the answer to 706 is yes, the UE 110 proceeds to 708.

[0065] In 708, the UE 110 determines whether the network indicated handover support from the serving network to the target network. If the answer to 708 is no, the UE 110 proceeds to the end and does not perform a handover from the serving network to the target network. If the answer to 708 is yes, the UE 110 proceeds to 710.

[0066] In 710, the UE 110 performs various connection operations to the target network, completing the handover. The operations 710 may for example, be PDN reguests, bearer establishment, IP sec tunnel establishment, etc. Upon the completion of 710, the UE 110 successfully handed over the call that began in 705 from the serving network to the target network .

[0067] A method of the second example (e.g. , involving a handover from VoLTE to VoWiFi) may include aspects similar to those described in Fig. 7.

[0068] However, in 705, according to the second example, the UE 110 may begin a call ( voice / video ) on a serving network (e.g., 3GPP network) implementing VoLTE. In 706, the UE 110 may determine if a handover is needed from a serving 3GPP network to a target non-3GPP network. In 708, the UE 110 may determine whether the network indicated handover support from the serving 3GPP network to the target non-3GPP network. In 710, the UE 110 may perform various connection operations to the target non-3GPP network, completing the handover.Examples

[0069] In a first example , a method, comprising generating, for transmission to a first network, a first message comprising a handover capability request relating to the first network and a second network, wherein the first network is a cellular network and the second network is a non-cellular network, processing, based on signaling from the first network, a second message indicating the first network supports a handover capability between the first network and the second network, determining a handover from the one of the first network or the second network to an other one of the first network or the second network is to be performed, determining, based on the second message , that handover from the one of the first network or the second network to the other one of the first network or the second network is allowed and performing a handover from the one of the first network or the second network to the other one of the first network or the second network .

[0070] In a second example , the method of the first example , wherein the first network is a Long Term Evolution ( LTE ) network and the second network is a Wi-Fi network .

[0071] In a third example , the method of the second example , wherein the first message comprises a tracking area update ( TAU) request or an attach request and the second message comprises a corresponding tracking area update ( TAU) accept or an attach accept .

[0072] In a fourth example , the method of the third example , wherein, prior to determining the handover, the UE participatesin a call via one of the first network or the second network, and wherein the call comprises a voice over LTE (VoLTE) call on the first network before the handover and a voice over Wi-Fi (VoWiFi) call on the second network after the handover.

[0073] In a fifth example, the method of the fourth example, further comprising establishing an internet protocol secure (IP Sec) tunnel with an evolved Packet Data Gateway (ePDG) function of the first network.

[0074] In a sixth example, the method of the fourth example, wherein the call comprises a voice call or a video call.

[0075] In a seventh example, the method of the third example, wherein, prior to determining the handover, the UE participates in a call via one of the first network or the second network, and wherein the call comprises a voice over Wi-Fi (VoWiFi) call on the second network before the handover and a voice over LTE (VoLTE) call on the first network after the handover.

[0076] In an eighth example, the method of the seventh example, further comprising generating, for transmission to the first network, a packet data network (PDN) request comprising a handover request to the first network, processing, based on signals received from the first network, an activate default evolved packet system (EPS) bearer context request and generating, for transmission to the first network, an activate default EPS bearer context response.

[0077] In a ninth example, the method of the seventh example, wherein the call comprises a voice call or a video call.

[0078] In a tenth example, the method of the first example wherein the first network is a New Radio (NR) network and the second network is a Wi-Fi network.

[0079] In an eleventh example, the method of the tenth example, wherein prior to determining the handover, the apparatus participates in a call via one of the first network or the second network, and wherein the call comprises a voice over NR (VoNR) call on the first network before the handover and a voice over Wi-Fi (VoWiFi) call on the second network after the handover .

[0080] In a twelfth example, the method of the eleventh example, wherein the first message comprises a registration request and the second message comprises a registration accept or a UE configuration update.

[0081] In a thirteenth example, the method of the twelfth example, further comprising establishing an internet protocol secure (IP Sec) tunnel with (i) an evolved Packet Data Gateway (ePDG) function or (ii) a Non-3GPPP Inter-Working Function (N3IWF) of the first network.

[0082] In a fourteenth example, the method of the eleventh example, wherein the call comprises a voice call or a video call .

[0083] In a fifteenth example, the method of the tenth example, wherein, prior to determining the handover, the apparatus participates in a call via one of the first network orthe second network, and wherein the call comprises a voice over Wi-Fi (VoWiFi ) call on the second network before the handover and a voice over NR (VoNR) call on the first network after the handover .

[0084] In a sixteenth example, the method of the fi fteenth example , wherein the call comprises a voice call or a video call .

[0085] In a seventeenth example , a processor configured to perform any of the methods of the first through sixteenth examples .

[0086] In an eighteenth example , a user equipment (UE ) configured to perform any of the methods of the first through sixteenth examples .

[0087] In a nineteenth example, a method, comprising receiving a first message comprising a handover capability request relating the first network and a second network, wherein the first network is a cellular network and the second network is a non-cellular network and transmitting a second message indicating the first network supports a handover capability for calls between the first network and the second network .

[0088] In a twentieth example, the method of the nineteenth example , wherein the first network is a Long Term Evolution ( LTE ) network and the second network is a Wi-Fi network .

[0089] In a twenty first example , the method of the twentieth example , wherein the first message comprises a tracking areaupdate (TAU) request or an attach request and the second message comprises a corresponding tracking area update (TAU) accept or an attach accept.

[0090] In a twenty second example, the method of the twenty first example, wherein a call for handover comprises a voice over LTE (VoLTE) call on the first network before handover and a voice over Wi-Fi (VoWiFi) call on the second network after handover .

[0091] In a twenty third example, the method of the twenty first example, wherein the call comprises a voice over Wi-Fi (VoWiFi) call on the second network before handover and a voice over LTE (VoLTE) call on the first network after handover.

[0092] In a twenty fourth example, the method of the twenty third example, further comprising receiving a packet data network (PDN) request comprising a handover request, sending an activate default evolved packet system (EPS) bearer context request and receiving an activate default EPS bearer context response .

[0093] In a twenty fifth example, the method of the nineteenth example, wherein the first network is a New Radio (NR) network and the second network is a Wi-Fi network.

[0094] In a twenty sixth example, the method of the twenty fifth example, wherein the first message comprises a registration request and the second message comprises a registration accept or a UE configuration update.

[0095] In a twenty seventh example , the method of the nineteenth example , wherein the call comprises a voice call or a video call .

[0096] In a twenty eighth example , one or more processors configured to perform any of the methods of the nineteenth through twenty seventh examples .

[0097] In a twenty ninth example , a cellular core network configured to perform any of the methods of the nineteenth through twenty seventh examples .

[0098] Those skilled in the art will understand that the above-described example embodiments may be implemented in any suitable software or hardware configuration or combination thereof . An example hardware platform for implementing the example embodiments may include , for example, an Intel x86 based platform with compatible operating system, a Windows OS , a Mac platform and MAC OS , a mobile device having an operating system such as iOS , Android, etc . The example embodiments of the above described method may be embodied as a program containing lines of code stored on a non-transitory computer readable storage medium that , when compiled, may be executed on a processor or microprocessor .

[0099] Although this application described various embodiments each having different features in various combinations , those skilled in the art will understand that any of the features of one embodiment may be combined with the features of the other embodiments in any manner not speci fically disclaimed or which is not functionally or logicallyinconsistent with the operation of the device or the stated functions of the disclosed embodiments .

[0100] It is well understood that the use of personally identi fiable information should follow privacy policies and practices that are generally recogni zed as meeting or exceeding industry or governmental requirements for maintaining the privacy of users . In particular, personally identifiable information data should be managed and handled so as to minimi ze risks of unintentional or unauthori zed access or use , and the nature of authori zed use should be clearly indicated to users .

[0101] It will be apparent to those skilled in the art that various modi fications may be made in the present disclosure , without departing from the spirit or the scope of the disclosure . Thus , it is intended that the present disclosure cover modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalent .

Claims

What is claimed :1 . An apparatus comprising processing circuitry configured to : generate , for transmission to a first network, a first message comprising a handover capability request relating to the first network and a second network, wherein the first network is a cellular network and the second network is a non-cellular network; process , based on signaling from the first network, a second message indicating the first network supports a handover capability between the first network and the second network; determine a handover from the one of the first network or the second network to an other one of the first network or the second network is to be performed; determine , based on the second message , that handover from the one of the first network or the second network to the other one of the first network or the second network is allowed; and perform a handover from the one of the first network or the second network to the other one of the first network or the second network .2 . The apparatus of claim 1 , wherein the first network is a Long Term Evolution (LTE ) network and the second network is a Wi-Fi network .3 . The apparatus of claim 2 , wherein the first message comprises a tracking area update ( TAU) request or an attach request and the second message comprises a corresponding tracking area update ( TAU) accept or an attach accept .4 . The apparatus of claim 3 , wherein, prior to determining the handover, the UE participates in a call via one of the firstnetwork or the second network, and wherein the call comprises a voice over LTE (VoLTE ) call on the first network before the handover and a voice over Wi-Fi (VoWiFi ) call on the second network after the handover .5 . The apparatus of claim 4 , wherein the processing circuitry is configured to : establish an internet protocol secure ( IP Sec) tunnel with an evolved Packet Data Gateway ( ePDG) function of the first network .6 . The apparatus of claim 3 , wherein, prior to determining the handover, the UE participates in a call via one of the first network or the second network, and wherein the call comprises a voice over Wi-Fi (VoWiFi ) call on the second network before the handover and a voice over LTE (VoLTE ) call on the first network after the handover .7 . The apparatus of claim 6 , wherein the processing circuitry is configured to : generate , for transmission to the first network, a packet data network ( PDN) request comprising a handover request to the first network; process , based on signals received from the first network, an activate default evolved packet system (EPS ) bearer context request ; and generate , for transmission to the first network, an activate default EPS bearer context response .

8. The apparatus of claim 1, wherein the first network is a New Radio (NR) network and the second network is a Wi-Fi network .

9. The apparatus of claim 8, wherein prior to determining the handover, the apparatus participates in a call via one of the first network or the second network, and wherein the call comprises a voice over NR (VoNR) call on the first network before the handover and a voice over Wi-Fi (VoWiFi) call on the second network after the handover.

10. The apparatus of claim 9, wherein the first message comprises a registration request and the second message comprises a registration accept or a UE configuration update.

11. The apparatus of claim 10, wherein the processing circuitry is configured to: establish an internet protocol secure (IP Sec) tunnel with (i) an evolved Packet Data Gateway (ePDG) function or (ii) a Non-3GPPP Inter-Working Function (N3IWF) of the first network.

12. The apparatus of claim 8, wherein, prior to determining the handover, the apparatus participates in a call via one of the first network or the second network, and wherein the call comprises a voice over Wi-Fi (VoWiFi) call on the second network before the handover and a voice over NR (VoNR) call on the first network after the handover.

13. A method performed by a core network of a first network, comprising :receiving a first message comprising a handover capability request relating the first network and a second network, wherein the first network is a cellular network and the second network is a non-cellular network; and transmitting a second message indicating the first network supports a handover capability for calls between the first network and the second network .14 . The method of claim 13 , wherein the first network is a LongTerm Evolution ( LTE ) network and the second network is a Wi-Fi network .15 . The method of claim 14 , wherein the first message comprises a tracking area update ( TAU) request or an attach request and the second message comprises a corresponding tracking area update ( TAU) accept or an attach accept .16 . The method of claim 15, wherein a call for handover comprises a voice over LTE (VoLTE ) call on the first network before handover and a voice over Wi-Fi (VoWiFi ) call on the second network after handover .17 . The method of claim 15, wherein the call comprises a voice over Wi-Fi (VoWiFi ) call on the second network before handover and a voice over LTE (VoLTE ) call on the first network after handover .18 . The method of claim 17 , further comprising : receiving a packet data network ( PDN) request comprising a handover request ;sending an activate default evolved packet system (EPS ) bearer context request ; and receiving an activate default EPS bearer context response .19 . The method of claim 13 , wherein the first network is a New Radio (NR) network and the second network is a Wi-Fi network .20 . The method of claim 19, wherein the first message comprises a registration request and the second message comprises a registration accept or a UE configuration update .

Images