Support of Single Radio Voice call Continuity in Next Generation (5G) Networks

Abstract

Apparatus and methods relating to enabling a wireless device to perform SRVCC when connected to a 3GPP specified gNB and a 5G core network that does not support SRVCC are disclosed. In some embodiments, a method of operation of a wireless device comprises providing an indication to the 5G core network that the UE support SRVCC in EPC mode and receiving instruction to connect to an eNB in EUTRAN and EPC that supports SRVCC to a circuit switched network. In this manner, the gNB and the 5G Core network is not required to support SRVCC. Related embodiments in gNB and a control plane entity in the G core network are also provided.

Claims

1. A method of operation of a wireless device (100, 1111) in a first core network, comprising: sending a message via a first radio access node to a control plane entity in the first core network, the message indicating the wireless device supports Single radio voice call continuity, SRVCC, from a second core network to a third core network; receiving instruction to connect to a neighboring radio access node for connecting to the second core network; and connecting to the second core network via the neighboring radio access node.

2. The method of claim 1 wherein the method further includes sending a radio message to the first radio access node connected to the first core network indicating supported wireless device SRVCC capabilities to at least one of Universal Terrestrial Radio Access Network, UTRAN, Global System for Mobile communication Edge Radio Access network, GERAN, and Code Division Multiplexing Access network, CDMA, from the second core network.

3. The method of claim 1 wherein receiving the instruction comprises receiving a handover command, a handover order, a release with redirect or a registration reject message.

4. The method of claim 1 wherein the first core network is a 5.sup.th generation core network, 5GCN and the second core network is an evolved packet core, EPC and the third core network is a circuit switched core network.

5. The method of claims 1 and 4, wherein the neighboring radio access node is a Long Term Evolution, LTE, evolved Node B, eNB, connected to the EPC network.

6. The method of claim 1 wherein the instruction is received at registration to the Internet Protocol multimedia subsystem, IMS, during establishment of a Voice over Internet Protocol, VoIP, session or after establishment of the VoIP session.

7. The method of claim 1 wherein the instruction is received during registration of the wireless device to the first core network.

8. A wireless device (100, 1111), comprising: at least one transceiver; at least one processor; and memory comprising instructions executable by the at least one processor whereby the wireless device (100, 1111) is operable to: send a message via a first radio access node to a control plane entity in the first core network, the message indicates the wireless device supports Single radio voice call continuity, SRVCC, from a second core network to a third core network; receive instruction to connect to a neighboring radio access node capable to connect to the second core network; and connect to the second core network via the neighboring radio access node.

9. A wireless device (100, 1111) adapted to: send a message via a first radio access node to a control plane entity in the first core network, the message indicates the wireless device supports Single Radio Voice Call Continuity, SRVCC from a second core network to a third core network; receive instruction to conned to a neighboring radio access node capable to conned to the second core network; and connect to the second core network via the neighboring radio access node.

10. The wireless device (100, 1111) of claim 9 further adapted to operate according to the method of any one of claims 2 to 5.

11. The wireless device (100, 1111) of claim 9 further adapted to receive the instruction at registration to the Internet Protocol multimedia subsystem, IMS, during establishment of a Voice over Internet Protocol, VoIP, session or after establishment of the VoIP session.

12. The wireless device (100, 1111) of claim 9 further adapted to receive the instruction during registration of the wireless device to the first core network.

13. A wireless device (100, 1111) comprising: a transmitting module (1201) operable to send a message via a first radio access node to a control plane entity in the first core network, the message indicates the wireless device supports Single Radio Voice Call Continuity, SRVCC from a second core network to a third core network; a receiving module (1202) operable to receive instruction to connect to a neighboring radio access node capable to connect to the second core network; and a connection module (1203) operable to connect to the second core network via the neighboring radio access node.

14. A method of operation of a radio access node (101A, 1120) in a wireless access network connected to a first core network, comprising: receiving information from the first core network indicating at least one of handover to a second core network that provides Single Radio Voice Call Continuity, SRVCC from the second core network to a third core network is supported for a wireless device connected to the first core network, and the wireless device is subject to SRVCC from the second core network to the third core network; and determining whether handover of the wireless device is to be performed to a selected neighboring radio access node that enables SRVCC from the second core network to the third core network is required in accordance with the received information.

15. The method of claim 14 wherein the method further comprises receiving from the wireless device information indicating supported wireless device SRVCC capabilities to at least one of Universal Terrestrial Radio Access Network, UTRAN, Global System for Mobile communication Edge Radio Access network, GERAN, and Code Division Multiplexing Access network, CDMA, from the second core network.

16. The method of claim 14 wherein the wireless device is subject to SRVCC is an indication that the wireless device has registered to receive Voice over Internet Protocol, VoIP services.

17. The method of claim 14 wherein the first core network is a 5.sup.th generation core network, 5GCN and the second core network is an evolved packet core, EPC and the third core network is a circuit switched core network.

18. The method of claim 14 and 15 wherein the selected neighboring radio access node has SRVCC capabilities are compatible with the wireless device SRVCC capabilities.

19. The method of claim 14 wherein the step of determining further comprises determining that radio coverage provided by the wireless access network does not require initiating handover of the wireless device to the neighboring radio access node.

20. A radio access node (101A, 101B) in a wireless access network, comprising: at least one transceiver at least one processor; and memory comprising instructions executable by the at least one processor whereby the radio access node (101A, 101B) is operable to: receive information from the first core network to indicate at least one of handover to a second core network that provides Single Radio Voice Cal Continuity, SRVCC from the second core network to a third core network is supported for a wireless device connected to the first core network, and the wireless device is subject to SRVCC from the second core network to the third core network; determine whether handover of the wireless device is to be performed to a selected neighboring radio access node that enables SRVCC from the second core network to the third core network is required in accordance with the received information.

21. A radio access node (101A, 101B) in a wireless access network, the radio access node adapted to: receive information from the first core network to indicate at least one of handover to a second core network that provides Single Radio Voice Call Continuity, SRVCC from the second core network to a third core network is supported for a wireless device connected to the first core network, and the wireless device is subject to SRVCC from the second core network to the third core network; and determine whether handover of the wireless device is to be performed to a selected neighboring radio access node that enables SRVCC from the second core network to the third core network is required in accordance with the received information.

22. The radio access node (101A, 101B) of claim 21 wherein the first core network is a 5.sup.th generation core network, 5GCN and the second core network is an evolved packet core, EPC and the third core network is a circuit switched core network.

23. The radio access node (101A, 101B) of claim 21 wherein the radio access node is further adapted to using radio coverage provided by the wireless access network to determine if handover of the wireless device to the neighboring radio access node is required.

24. A method of operation of first control plane entity (102) in a first core network, comprising: receiving from a wireless device via a radio access node a message indicating the wireless device supports Single Radio Voice Call Continuity, SRVCC from a second core network to a third core network; sending a radio access network message to the radio access node indicating support of SRVCC from the second core network; and receiving an indication for relocating the wireless device to the second core network or for releasing corresponding wireless device context.

25. The method of claim 24 wherein receiving the indication for relocating the wireless device further comprises receiving a handoff request indicating handover of the wireless device to the second core network for SRVCC from the second core network to the third core network.

26. The method of claim 25 further determining that user plane anchor relocation to the second core network is required and sending a command to the second core network indicating handover of the wireless device with user plane anchor relocation.

27. The method of claim 24, wherein the method further comprises determining the wireless device is subject to SRVCC from the second core network to the third core network and informing the radio access node accordingly.

28. The method of claim 27, wherein the step of determining is based on obtaining information comprising at least one of an indication that Voice over Internet Protocol, VoIP registration by the wireless device, or an indication that VoIP session is established, or an indication that the wireless device is attached to the first core network to receive VoIP services, or voice call continuity service is enabled for the wireless device.

29. A first control plane entity (102) in a first core network, comprising: at least one processor; and memory comprising instructions executable by the at least one processor whereby the first control plane entity (102) is operable to: receive from a wireless device via a radio access node a message indicating the wireless device supports Single Radio Voice Call Continuity, SRVCC from a second core network to a third core network; send a radio access network message to the radio access node indicating support of SRVCC from the second core network; and receive an indication for relocating the wireless device to the second core network or to release corresponding wireless device context.

30. A first control plane entity (102) in a first core network, the first control plane entity adapted to: receive from a wireless device via a radio access node a message indicating the wireless device supports Single Radio Voice Call Continuity, SRVCC from a second core network to a third core network; send a radio access network message to the radio access node indicating support of SRVCC from the second core network; and receive an Indication for relocating the wireless device to the second core network or to release corresponding wireless device context.

31. The first control plane entity (102) of claim 30 is further adapted to determine the wireless device is subject to SRVCC from the second core network to the third core network and informing the radio access node accordingly.

32. The first control plane entity (102) of claim 31, is further adapted to base the determination on obtained information that comprise: an indication that Voice over Internet Protocol, VoIP registration by the wireless device; an indication that VoIP session is established; an indication that the wireless device is attached to the first core network to receive VoIP services, or voice call continuity service is enabled for the wireless device.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0138] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0139] FIG. 1 (Prior art) illustrates a Non-standalone NR scenario where a gNB coexists with an eLTE eNB in the New RAN and uses eLTE eNB to connect to the EPC.

[0140] FIG. 2A (Prior art) illustrates another Non-standalone eLTE scenario where a gNB co-exists with an eLTE eNB in the New RAN.

[0141] FIG. 2B (Prior art) illustrates another non-standalone NR scenario where a gNB co-exists with an eLTE eNB in the New RAN.

[0142] FIG. 2C (Prior art) illustrates another non-standalone NR scenario where a gNB co-exists with an eLTE eNB and eLTE eNB acts as an anchor for control plane connectivity for gNB.

[0143] FIG. 3A (Prior art) illustrates a standalone scenario where only gNBs exist in the New RAN and gNB interfaces to the NGCN.

[0144] FIG. 3B (Prior art) illustrates another standalone scenario where only eLTE eNBs exist in the New RAN and eLTE eNB interfaces to the NGCN.

[0145] FIG. 4 (prior art) illustrates one example of an NGCN functional architecture currently in discussion in 3GPP.

[0146] FIG. 5 illustrates an example of legacy core network co-existence with EPC and NGCN according to one embodiment.

[0147] FIG. 6 illustrates a legacy core networks co-existence with EPC and NGCN to support SRVCC according to another embodiment.

[0148] FIG. 7 illustrates a signaling flow for support of SRVCC from gNB and NGCN to EUTRAN and EPC according to one embodiment.

[0149] FIG. 8 illustrates anchoring of user plane in NGCN following SRVCC handover according to one embodiment.

[0150] FIG. 9A illustrates an exemplary method executed on a wireless device/UE in accordance with an embodiment.

[0151] FIG. 9B illustrates an exemplary method executed on a gNB for determining if a handover to EUTRAN for SRVCC is required in accordance with some embodiment.

[0152] FIG. 10 illustrates an exemplary method on a control plane function in NGCN for supporting handover for SRVCC from New RAN/NGCN to EUTRAN/EPC in accordance with some embodiments.

[0153] FIG. 11 illustrates a circuitry of a user equipment or wireless device according to one embodiment.

[0154] FIG. 12 illustrates a wireless device or user equipment according to other embodiments.

[0155] FIG. 13 illustrates an exemplary embodiment of a gNB according to some embodiments of the present disclosure.

[0156] FIG. 14 illustrates an exemplary embodiment of a virtualized gNB according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

[0157] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0158] A UE herein, is a non-limiting term refers to any type of wireless device communicating over a wireless radio interface with a radio access node such as eLTE eNB, LTE eNB, 5G/NR gNB, WiFi Access point, AP, and connecting to core network nodes over a network interface (e.g., non-access stratum, NAS, or other signaling protocol). Example of network nodes include MME if EPC network, MM entity and SM entity in NGCN. UE also communicate with other network nodes such as Access Network Discovery and selection function, ANDSF, Proxy Call and Session Control function. PCSCF in IP Multimedia Subsystem, IMS, etc. The UE may also communicate with other UEs in a cellular or mobile communication system. Examples of a UE are a Personal Digital Assistant (PDA), a tablet, mobile terminals, a smart phone. Laptop Embedded Equipment (LEE), Laptop Mounted Equipment (LME), Universal Serial Bus (USB) dongles, etc.

[0159] In certain embodiments, radio access nodes may communicate with each other, e.g. via an interface (e.g. X2 in LTE or similar interface). The radio access nodes (e.g., LTE eNB, eLTE eNB, gNB) are also capable of communicating with control plane network entities (e.g., MME, MM entity, SM entity, etc.) via control plane interfaces (e.g., S1-AP/MME. NG2). The radio access nodes are additionally communicating with user plane network entities (e.g., service gateway, SGW, NGCN user plane, UP, functions, etc.) over the respective user plane interfaces (e.g., S1-U, NG3). The radio access nodes supporting different access technologies may be collocated in the same physical node. For example, a base station may support LTE and NR or eLTE and NR or LTE and eLTE. When in collocated mode, the handover from NR to EUTRA may be handled as an intra-node handover to optimize some signaling.

[0160] In this disclosure, Voice over IP session refers to either VoIP or Voice over LTE, VoLTE, or Voice over NR, all interchangeable in this disclosure. The VoIP session is established with or without Interment Protocol Multimedia subsystem, IMS. However, the embodiments herein are described for VoIP sessions established with IMS. The VoIP session includes a voice/audio component and may also include a video component.

[0161] The following embodiments are described using gNB as the radio access node.

[0162] However, it will be understood that the embodiments herein also apply when using an eLTE eNB that does not support SRVCC to UTRAN/GERAN and is connected to NGCN and when using an eLTE eNB that supports SRVCC to UTRAN/GERAN and the eLTE eNB is connected to NGCN. The embodiments enable a UE to change from NGCN to EPC when an SRVCC scenario is possible, however the target cell may be the same as the source cell.

[0163] Embodiments are now provided to describe a scenario involving a UE connected to a gNB and moved to an eNB in EUTRAN where a potential SRVCC could be provided when required.

[0164] FIG. 5 illustrates an example of legacy CS core network coexistence with the EPC where the EPC interworks with the NGCN to support SRVCC. NGCN does not interface nor interwork with CS Core network. FIG. 5 shows the GERAN/UTRAN connected to the CS core network and to an EPC. The CS core network interworks with the EPC, more specifically with the MME in the EPC via the Sv interface as specified in 3GPP TS 23.216. The EPC supports UTRAN/GERAN (PS component), EUTRAN (LTE eNBs) and non-3GPP access such as WiFi. The EPC in this disclosure is upgraded to interwork with the NGCN MM entity and/or SM entity for supporting handover of a UE that wants to operate in EPC mode due to potential SRVCC. The NGCN interfaces to gNB over control plane interface, NG2 and user plane interface, NG3. The NGCN also supports WiFi access and other non-3GPP accesses.

[0165] FIG. 6 is another variant of FIG. 5, where the CS network supports CS UTRAN and GERAN and interworks with an upgraded EPC. The upgraded EPC supports UTRAN/GERAN (PS component), EUTRAN (LTE eNBs) as well as Evolved EUTRAN (eLTE eNBs) and non-3GPP access such as WiFi. The EPC is also upgraded to interwork with the NGCN to allow handover of a UE for operating in EPC mode. Similar to FIG. 5, the NGCN interfaces and supports Evolved EUTRAN (eLTE eNBs), NR (gNB) and WiFi access (other non-3GPP accesses may also be supported). NGCN in FIG. 6 also supports interworking with the upgraded EPC. Note that if the UE was initially connected to an eLTE eNB that is connected to both the upgraded EPC and to an NGCN such as the configuration shown in FIG. 6, then the following alternative scenarios are possible: [0166] 1. The UE is attached to the NGCN via the eLTE eNB. The eLTE eNB receives an indication from NGCN that the UE is subject to SRVCC from EUTRAN. Since the eLTE eNB is also connected to EPC it simply initiates a handover/reconnection of the UE from NGCN to EPC. After core network relocation from NGCN to EPC, and if the eLTE eNB supports SRVCC to UTRAN/GERAN then when the UE establishes a VoIP session, the UE may the be subject to SRVCC from the eLTE eNB to UTRAN/GERAN as specified in 3GPP TS 23.216. [0167] 2. Alternatively, when the UE connects to eLTE eNB that supports SRVCC and the UE indicates support for SRVCC from EUTRAN, the eLTE eNB may instead select to connect to an MME in EPC instead of selecting the NGCN at the time of the attach, in which case the UE and the network are ready for SRVCC handover when required as per 3GPP TS 23.216.

[0168] FIG. 7 illustrates a signaling flow for support of SRVCC from gNB 101A and NGCN to EUTRAN eNB 101C and EPC according to one embodiment. In this embodiment the gNB 101A is connected to the NGCN as shown in the configuration of FIG. 5. In the embodiment of FIG. 7, the gNB 101A triggers the handover to eNB 101C only after the UE 100 has established a VoLTE session and the connection for the voice media packets is established over the gNB 101A and the User Plane, UP, function in NGCN.

[0169] Note that the handover initiated by the gNB 101A is different from the well-known SRVCC handover from EUTRAN to CS UTRAN/GERAN which is triggered by UE measurement reports and/or the UE losing coverage of LTE as described in 3GPP TS 23.216. The handover from gNB 101A/NGCN to EUTRAN/EPC is triggered by an indication that the UE is subject to SRVCC and/or support SRVCC from 4G/EUTRAN to UTRAN/GERAN and the establishment of the VoLTE connection. The new RAN (gNB) to EUTRAN handover described in these embodiments is executed in advance of the actual SRVCC handover from EUTRAN to CS UTRAN/GERAN.

[0170] FIG. 7 illustrates an MM entity 102 and an SM entity 103 of the NGCN. The MM entity 101 is described in 3GPP TR 23.799 and 3GPP TS 23.501 as a functional entity that may support MM functions comprises: [0171] termination of New RAN control plane interface, NG2, [0172] termination of NAS or similar interface, NG1, [0173] NAS ciphering and integrity protection, [0174] Mobility Management (tracking of UE location), [0175] establishment and maintenance of the MM context for a UE 100 attaching to the NGCN, [0176] lawful intercept, LI, (for MM events and interface to LI System). [0177] transparent proxy for routing access authentication and SM messages or interacts with SM entity 103 to validate the establishment of a SM context for a UE 100 that has securely established an MM context.

[0178] The Session Management entity 103 is currently described in 3GPP TR 23 799 and 3GPP TS 23.501 as a functional entity responsible for SM functions that may comprise: [0179] UE IP address allocation & management (incl optional Authorization), [0180] selection and control of User Plane, UP, function, [0181] establishing, and managing packet data Sessions on-demand for the UE 100, [0182] termination of interfaces towards Policy control and Charging functions, [0183] Policy & Charging rules handling, including control part of enforcement and quality of service, QoS, [0184] Lawful intercept (for SM events and interface to LI System)

[0185] The NGCN UP function is currently described in 3GPP TR 23.799 and 3GPP TS 23.501 as a functional entity responsible for UP functions that may comprise the following functionality: [0186] Anchor point for Intra-/Inter-RAT mobility (when applicable), [0187] Packet routing & forwarding, [0188] QoS handling for User plane, [0189] Packet inspection and Policy rule enforcement, [0190] Lawful intercept (UP collection), [0191] Traffic accounting and reporting.

[0192] Step 700 of FIG. 7: The UE 100 establishes a radio connection with a gNB 101A for the purpose of attaching to the NGCN. The UE 100 may indicate to the gNB 101A that it supports SRVCC from EUTRAN to UTRAN/GERAN/CDMA and may also include the supported frequencies and the IRAT-ParametersUTRA specified in 3GPP TS 36.331 to indicate the type of actual SRVCC capabilities supported by the UE 100. The connection request also includes an attach ore registration request for the NGCN (but may also be sent separately) which when received by the gNB 101A, is forwarded towards the NGCN to a selected MM entity 102. The UE 100 includes in the registration request message an indication that it supports SRVCC from EUTRAN. The SRVCC from EUTRAN indication may alternatively be sent from the UE 100 to the MM entity 102 in other NAS messages during the attach/registration procedure.

[0193] Step 701: VoLTE support in NGCN is not mandatory by default. However, if NGCN supports Voice over IP service, the MM entity 102 in its response to the UE 100 indicates voice support capability. Note that if VoLTE support is mandatory by default in NGCN, then voice support indication is not required to be sent to the UE 100 as support for voice over IP service is implicitly assumed when the UE 100 is attached to the NGCN.

[0194] At step 702 (which may happen as part of step 701), the MM entity 102 may signal to the gNB 101A support of SRVCC in EPC mode (aka. SRVCC from EUTRAN) or similar indication. This indication is used to indicate that the UE and the NGCN support handover to EUTRAN for the purpose of enabling SRVCC handover from EUTRAN to CS UTRAN/GERAN. The gNB 101A may also receive a separate indication that indicates that the UE is subject to SRVCC from EUTRAN (see method in MM entity and FIG. 10 for more details). The gNB 101A stores the received indications. Note that the indicator UE subject to SRVCC may be received later, when the UE establishes a packet data connection, registers with IMS, or establishes a VoIP session.

[0195] At step 703, the UE 100 registers via the NGCN in the IMS 107 for voice service and/or other IMS services.

[0196] At step 704, If the UE moves to a new gNB, the support of SRVCC in EPC mode is provided to the new gNB over either a direct inter-gNB interface or from the NGCN during context transfer or handover procedure from source gNB 101A to the new gNB. The embodiment of FIG. 7 assumes that handover from source gNB 101A to a new gNB is not required.

[0197] At steps 705, the UE originates or receives a VoLTE call with IMS 107.

[0198] At step 706, through interaction between the application function, AF in IMS 107 (e.g., PCSCF) and policy server function 104 or SM 103 entities in NGCN, a QoS request for voice media is send from NGCN to gNB 101A. The QoS request may include information indicating that the UE is subject to SRVCC from EUTRAN. The gNB 101A receives the indication that the UE is subject to SRVCC from EUTRAN at this step even if has been included in the earlier attach procedure (step 702 above).

[0199] At step 707, the gNB 101A determines based on received and stored SRVCC indicators in previous steps, and stored policy data if the UE should be handed over to EUTRAN or to EPC mode to allow the UE 100 to connect to EPC through a neighbour eNB 101C that can connect to EPC. The handover is therefore triggered by establishment of the VoLTE session established and/or the indication that UE may be subject to SRVCC.

[0200] If gNB 101A determines that handover to an LTE eNB and EPC is required to enable the UE to connect to an SRVCC capable EPC, the gNB 101A connected to NGCN at step 707 sends a handover request to initiate handover to an eNB 101C capable of connecting to an SRVCC capable EPC network. Alternatively, the gNB 101A may also keep the call on NR (gNB 101A) if the radio conditions/coverage do not require performing an SRVCC for the VoLTE call. However, if the radio conditions are changing, then the handover to LTE and EPC is initiated. The handoff request may also indicate if user plane, UP, relocation is required, else the MM entity 102 makes such determination based on the NGCN network policy.

[0201] Several different methods for initiating handover can be used. E.g. handover request from gNB 101A to eNB 101C via an X2 interface or similar interface, or a handover request from gNB 101A to the MM entity 102 or SM entity 103 in NGCN, or gNB 101A sending a release with re-direct to the UE 100 requesting the UE 100 to connect to EUTRAN target cell due to potential SRVCC. FIG. 7 illustrates the scenario where the gNB 101A sends the handoff request to MM entity 102 (or SM entity 103) in NGCN.

[0202] Step 708: handoff execution: The MM entity 102 receives the handoff request message or similar and determines if UP anchor relocation from NGCN to EPC is required (see below 1. Description of UP anchor relocation determination at handover for SRVCC from New RAN and NGCN to EUTRAN and EPC). The MM entity 102 sends a handoff command towards the target LTE eNB (target EUTRAN) via interworking with MME 105 in EPC indicating if UP anchor relocation is required or not. The MM entity 102 indicates in the handoff command the required EPS bearer(s) to setup (including the VoLTE QoS parameters). The MM entity 102 may also indicate that the voice call may be subject to SRVCC handover to CS network. The MME 105 forwards the handoff command to the target eNB 101C. The handover to eNB 101C in EUTRAN is performed. This scenario shows the UP anchor is maintained in NGCN (no relocation performed). The UP connection for the VoLTE session is thus established between the UE 100, eNB 101C and the UP function in NGCN bypassing the SGW and PGW of the EPC and remains as an anchor for the IMS VoLTE/VoIP media session toward the IMS. The UP anchor could remain in NGCN even after the actual SRVCC is performed from EUTRAN to CS EUTRAN/GERAN.

[0203] Step 709: After the handover of the voice media connection of the VoLTE session is performed, the eNB 101C monitors and determines if SRVCC is required based on UE measurement report and other criteria and information as specified in 3GPP TS 23.216. The eNB 101C initiates SRVCC to UTRAN and/or GERAN if required as already standardized in 3GPP, with the difference that the UP anchor remains in NGCN.

1. Description of UP Anchor Relocation at Handover for SRVCC from New RAN and NGCN to EUTRAN and EPC:

[0204] When the UE 100 is attached to NGCN via gNB 101A and is assigned an IP address, the UP function in NGCN provides UP anchor capability for the UE 100. When the IMS VoLTE/VoIP session is established over NGCN and gNB 101A, the UP anchor function in NGCN transmits all SIP signaling and media packets received from the UE 100 to the IMS. Similarly, the UP anchor function receives and transmits to the UE 100 all SIP signaling and media packets received from the IMS for the UE 100. When the MM entity 102 receives a handoff request indicating SRVCC in EPC mode from gNB 101A, The MM entity 102 queries the SM entity 103 to determine if UP anchor relocation to EPC is required. The SM entity 103 may determine based on configured operator policy or policy obtained from the policy server if UP anchor relocation is required for the VoLTE/VoIP service at handover of the UE 100 for SRVCC in EPC mode from gNB 101A and NGCN to EUTRAN and EPC.

[0205] If the SM entity 103 determines that UP relocation is not required, the UE IP address and hence IMS registration are maintained and do not need to be updated by or for the UE 100. The MM entity 102 indicates in a handoff command to the MME that UP anchor relocation is not required. The MME in EPC forwards the handoff command to target eNB 101C in EUTRAN. The handoff command includes the IP address of the UP anchor in NGCN and if a VoLTE/Voice over IP session is in progress, it includes the necessary bearer parameters to establish the necessary bearers for the VoLTE session in EUTRAN. As the EPC/target eNB 101C completes the handover, the UP connection for transporting the voice media packets is established between the UE 100, EUTRAN eNB 101C and the UP anchor function in the NGCN bypassing the SGW and PGW in the EPC. Alternatively, the eNB 101C may establish the S1-U user plane connection to the SGW in EPC. The SGW would then establish the connection(s) to the UP anchor function in NGCM establishing a user plane path from the UE 100 to packet data network and IMS through eNB 101C, bypassing the PGW in EPC. FIG. 8 illustrates an example of UE anchor maintained at NGCN following the handover to EUTRAN for SRVCC.

[0206] If, on the other hand, the SM entity 103 determines that UP anchor should be relocated to the PGW in EPC at handover for SRVCC in EPC mode, the SM entity 103 responds to the MM entity 102 indicating that UP anchor relocation is required. When the MM entity 102 sends a handoff command or similar, to the MME in EPC, it would indicate that UP anchor relocation to PGW is required and if a VoLTE/Voice over IP session is in progress at NGCN, the handoff command includes necessary VoLTE/Voice over IP connection context established at UP anchor in NGCN (e.g., QoS) for the established VoLTE/Voice over IP session. When the EUTRAN receives the handover command, an Evolved packet system, EPS, bearer is established between the UE 100 and the PGW through the eNB 101C and the SGW. The PGW becomes the new anchor for the voice over IP/VoLTE session. The UE IP address may be changed due to UP anchor relocation if NGCN and EPC do not share a common address pool. If the IP address is changed at UP anchor relocation, and the UE is either in IMS registered state or engaged in a VoLTE/voice over IP session, the UE may need to update its IMS registration using the new IP address and may update the other end-point of the VoLTE/Voice over IP session.

[0207] Relocating the UP anchor during handover for SRVCC in EPC mode while a VoLTE/Voice over IP call is in progress may not be effective due to the delay and loss resulting from relocation of the UP anchor and potential change of the IP address that require additional IMS signaling for updating the IMS and the other end-point of the voice session. Therefore, it would be preferable to perform UP anchor relocation if handover for SRVCC in EPC mode is triggered prior to establishment of the VoLTE\Voice over IP session, i.e., following the UE attach in NGCN with presence of the SRVCC in EPC mode indicator.

2. An Exemplary Method Executed at New RAN Nodes, gNB for Determining Handoff for SRVCC from EUTRAN/eNB

[0208] FIG. 9A illustrates an exemplary method 900A executed at a wireless device or UE that supports SRVCC but connects to a core network via gNB that do not support SRVCC to UTRAN/GERAN and CS network. At step 910A, the UE sends a message to the NGCN via the gNB and the message includes an indication that the UE supports SRVCC in EPC mode. The UE may specify support for SRVCC from EUTRAN to UTRAN/GERAN/CDMA, and may include the supported frequencies and may include the IRAT-ParametersUTRA specified in 3GPP TS 36.331. The IRAT-ParametersUTRA is sent to gNB to indicate the type of actual SRVCC capabilities supported by the UE 100 which may include: [0209] srvcc-FromUTRA-FDD-ToGERAN: Indicates whether UE supports SRVCC handover from UTRA FDD PS HS to GERAN CS and/or [0210] srvcc-FromUTRA-FDD-ToUTRA-FDD: Indicates whether UE supports SRVCC handover from UTRA FDD PS HS to UTRA FDD CS and/or [0211] srvcc-FromUTRA-TDD128-ToGERAN: Indicates whether UE supports SRVCC handover from UTRA TDD 1.28 Mcps PS HS to GERAN CS and/or [0212] scc-FromUTRA-TDD128-ToUTRA-TDD128: Indicates whether UE supports SRVCC handover from UTRA TODD 1.28 Mcps PS HS to UTRA TDD 1.28 Mcps CS.

[0213] The message may be an attach or a connection request or other. The connection request or the attach message may include an indication that the connection is for a VoIP connection as well.

[0214] If the UE is allowed to continue over NGCN, it may, at one point request establishment of a VoIP session and establish VoIP bearer.

[0215] At step 920A, the UE receives an instruction from the gNB or the NGCN to handover to a neighboring eNB that supports SRVCC or to release the connection with gNB and connect to eNB. The UE may receive a handover instruction if it has established a user plane connection, or has established a VoIP connection with NGCN, or it may receive a release and connect or release and redirect if the UE has not yet established any user plane connection with NGCN. Alternatively, the UE may receive an attach reject with an appropriate release code indicating to the UE to connect to an eNB and EPC using the EPC Non Access Stratum protocol. At step 930A, the UE connects to the eNB as indicated at step 920A. Once the VoIP connection Is established over eNB and EPC, the eNB and EPC will subsequently provide SRVCC if the UE moves outside the coverage of LTE The procedures for providing SRVCC from EUTRAN (eNB), EPC to UTRAN/GERAN and CS network are as specified in 3GPP TS 23.216.

3. An Exemplary Method Executed at New RAN Nodes, gNB for Determining Handoff for SRVCC from EUTRAN/eNB

[0216] FIG. 9B illustrates an exemplary method 900 executed at a New RAN node e.g., a gNB connected to NGCN, for determining if handover of a UE connected to NGCN through gNB is required. Again, the embodiment is described with gNB but applies to any node that connects to NGCN.

[0217] The gNB receives a message from a UE that comprises an attach request to forward to the MM entity in NGCN. The message may include an indication that it supports SRVCC from EUTRAN to UTRAN/GERAN/CDMA, may include the supported frequencies and may include the IRAT-ParametersUTRA specified in 3GPP TS 36.331. The IRAT-ParametersUTRA is sent to gNB to indicate the type of actual SRVCC capabilities supported by the UE 100 which may include: [0218] srvcc-FromUTRA-FDD-ToGERAN: Indicates whether UE supports SRVCC handover from UTRA FDD PS HS to GERAN CS and/or [0219] srvcc-FromUTRA-FDD-ToUTRA-FDD: Indicates whether UE supports SRVCC handover from UTRA FDD PS HS to UTRA FDD CS and/or [0220] srvcc-FromUTRA-TDD128-ToGERAN: Indicates whether UE supports SRVCC handover from UTRA TDD 1.28 Mcps PS HS to GERAN CS and/or [0221] srvcc-FromUTRA-TDD128-ToUTRA-TDD128: Indicates whether UE supports SRVCC handover from UTRA TDD 1.28 Mcps PS HS to UTRA TDD 1.28 Mcps CS.

[0222] The gNB stores the information received from the UE, selects an MM entity (which may be part of a network slice selection) and forwards the attach request message to the MM entity.

[0223] Step 901: the gNB receives a message from the MM entity in response to the attach request. The message may include support of SRVCC in EPC mode (aka. SRVCC from EUTRAN) or similar indication to indicate that the UE and the NGCN support handover to EUTRAN for the purpose of enabling subsequent SRVCC handover from EUTRAN to CS UTRAN/GERAN connected to a CS core network. It would be understood that the indication may be provided to the gNB in: [0224] Any message during or after the attach procedure. An example of message carrying the indication may be UE context setup or context modification message or similar, or [0225] an embedded indication in a UE radio capabilities information element or similar included in an appropriate message and transmitted to the gNB 101A from the MM entity 102.

[0226] The gNB 101A stores the received indicator from NGCN indicating support for SRVCC in EPC mode. Note that the indicator may be updated at any time by the MM entity. The gNB may, at this time, determine based on the indicator received in this step that UE should be handed over immediately to a neighboring radio access node (e.g. EUTRAN) that supports SRVCC and may perhaps select a neighboring radio access node that has SRVCC capabilities that are compatible with the SRVCC capabilities of the UE if previously received. Additionally, the neighboring radio access node that is selected must be connected to an SRVCC capable EPC. This information could be pre-configured in the gNB or may be received over an inter-RAT interface from the neighboring base stations or may be configured via network management. In this exemplary method, the gNB determined not to immediately trigger a handover of the UE to neighboring radio access nodes that operate in EPC mode only until it has received an indication that the UEs intends to establish or is establishing a Voice over IP call.

[0227] The gNB may receive a second indicator indicating the UE is now subject to SRVCC from EUTRAN or similar. The second indicator can be used to indicate that the UE is establishing or will establish a VoLTE or Voice over IP session or that the VoLTE/Voice over IP session is already established. The second indicator may also indicate voice call continuity from EPC or voice call continuity enabled for the UE. The gNB may receive the second indicator at the same time as the indicator received at step 901, i.e., during the attach procedure or in a different message outside the attach procedure. The information may be received prior or after establishment of the VoLTE\VoIP user plane QoS connection for transporting the corresponding voice media packets.

[0228] Step 902: the gNB determines, after reception of the second indicator, whether the UE should be handed over to a neighboring EUTRAN radio access node (e.g. EUTRAN) that supports SRVCC and where the neighboring radio access node must be connected to an SRVCC capable EPC. Such determination could be based on (but not limited to): [0229] 1) radio network policy indicating whether 5G or NR coverage for VoLTE is ubiquitous or not, and/or [0230] 2) received QoS request indicating QoS for voice media connection or explicit indication that UE is subject to SRVCC and/or [0231] 3) the stored indication support of SRVCC in EPC mode (aka. SRVCC from EUTRAN) previously received at step 702 and/or [0232] 4) if received from the UE at step 700 of FIG. 7, the stored indication SRVCC from EUTRAN to UTRAN/GERAN/CDMA, the supported frequencies and actual SRVCC capabilities of the UE that may be received in the IRAT-ParametersUTRA described in the background as the selected neighboring radio access node could be selected on the basis of compatibility with the UE SRVCC capabilities, and/or [0233] 5) RAT priority for voice service, and/or [0234] 6) Voice call continuity requirements.

[0235] If gNB determined that handover to EUTRAN/EPC for the purpose of SRVCC is required and the user plane has already been established for the UE in NGCN, the gNB connected to NGCN sends a handover request to initiate handover to the eNB. Alternatively, the gNB may also keep the call on NR (gNB 101A) if the radio conditions/coverage do not require a handover to EUTRAN for SRVCC to 2G/3G. However, if these radio conditions are changing, then the handover from New RAN/NGCN to LTE/EPC is initiated. If the user plane is not established, the gNB instructs the UE to move to the neighboring eNB and sends a release to the NGCN.

4. An Exemplary Method Executed at Control Plane, CP, Entity for Supporting Handoff for SRVCC from EUTRAN/eNB

[0236] FIG. 10 illustrates an exemplary method 1000 executed at a control plane entity in NGCN interfacing with the UE via NG1 interface over gNB. The method enables handover of the UE to EUTRAN and EPC and allowing the UE to operate in EPC mode (i.e., connect over LTE NAS to EPC) and receive SRVCC service when required. In this disclosure we refer to the control plane entity as the MM entity that handles mobility management.

[0237] Step 1001: The MM entity receiving from the UE over the NG1 interface an indication that it supports SRVCC from EUTRAN or it is capable to handle SRVCC in EPC mode. The indication is received in initial attach message, or other appropriate messages received over the NG1 interface or it may be received from gNB.

[0238] Step 1002: The MM entity executes the step of processing the attach request and makes the following determinations: [0239] If Voice over IP support is not mandatory by default in NGCN, the MM entity indicates to the UE if NGCN is configured to support Voice over IP, [0240] If Voice over IP support is mandatory by default in NGCN, then voice support indication does not need to be explicitly signaled to the UE. [0241] The MM entity may signal to the gNB two separate indications. The first and second indications may be sent in the same message towards the gNB or at different times in different messages. [0242] The first indication relates to support of SRVCC in EPC mode (aka. SRVCC from EUTRAN) to indicate that the UE and the NGCN support handover to EUTRAN for the purpose of enabling SRVCC handover from EUTRAN to CS UTRAN/GERAN. This indication is preferably sent to the gNB at the time the UE is attached or it may be sent at any other time over different messages. This is a different indication than the one received in the attach request from the UE as it indicates support by both UE and NGCN of handover for SRVCC in EPC mode (aka. SRVCC from EUTRAN). The value of the indicator may indicate (supported/not supported) by the MM entity. The MM entity updates the gNB when the value of the indicator is changed. [0243] The second indication determined or obtained by the MM entity is used to indicate that the UE is subject to SRVCC from EUTRAN (also subject to SRVCC in EPC mode). The second indication can be used if the MM entity has obtained information from the UE and/or other NGCN entities that the UE is establishing or will establish a VoLTE/VoIP session. The second indication may be sent from the MM entity to the gNB during the UE attach procedure or QoS request messages or other messages that may be supported between the MM entity and gNB to indicate the UE intent to establish an VoLTE/VoIP session. More specifically, the MM entity could be able to determine the value of the second indicator even prior to establishment of the VoLTE/Vo IP session. The MM entity may use the following information to determine the second indicator: [0244] Information from the attach/registration message indicating UE is attached to receive IMS services (e.g., IMS VoLTE/Voice over IP Access point name, APN or similar), and/or [0245] Information from a subscriber database as part of the subscription profile that the UE profile indicate voice call continuity is required, or that the user is simply allowed for voice services, and/or [0246] Information from a policy control server function as part of the subscription profile and network policy. Information include, voice service continuity required or voice services to be provided to the UE. [0247] Alternatively, the MM entity may determine the second indication only when the UE is in the process of establishing a VoLTE/VoIP session or when the UE registers with IMS. The MM entity may obtain that information from a policy control function. When the IMS Application Function, AF, receives the request to setup a VoLTE/VoIP session for the UE or an IMS registration from the UE, it signals to the policy control function (for example via the NG5 interface) an indication that the UE is either establishing a voice over IP session or is registering to receive or originate a voice over IP session with IMS. The policy control function informs the MM entity accordingly indicating that the UE is subject to SRVCC from EUTRAN due to the VoLTE/VoIP service being setup or is being established or is likely to be requested (e.g., due to IMS registration). The MM entity determines if it should inform the radio access node (gNB) that the UE is subject to SRVCC in EPC mode and may use other information such as voice call continuity is required as part of the received profile or operator configuration. The MM entity sends the second indicator to the gNB to which the UE is connected indicating the UE is subject to SRVCC in EPC mode. This would allow the gNB to determine if the UE should be handover Immediately to a neighboring radio access node (e.g. EUTRAN) that supports SRVCC in EPC mode or that is able to subsequently handover to a radio access node that supports SRVCC in EPC mode.

[0248] Step 1003: If user plane is already established for the UE, then Upon receiving a handoff request message indicating handover to EUTRAN/EPC for SRVCC, the MM entity executes the step of determining if UP anchor relocation is required. The MM entity initiates sending a message to the SM entity to request if UP anchor relocation from NGCN to EPC is required. Alternatively, the MM entity may obtain that information from the policy control function Upon determining if UP anchor relocation is required (see details in section 1. Description of UP anchor relocation determination at handover for SRVCC from New RAN and NGCN to EUTRAN and EPC), the MM entity sends a handoff command or a similar message towards the target LTE eNB (target EUTRAN) via interworking with MME in EPC indicating if UP anchor relocation is required or not. The MM entity may include in the handoff command information indicating the required EPS bearer(s) to setup (If IMS VoLTE/VoIP session is established or is being established, the corresponding QoS for the voice session may be included) and may indicate that the voice call may be subject to actual SRVCC handover to CS network. If the user plane is not already established for the UE, i.e., if the gNB determines to move the UE after receiving the first indicator, then the MM entity will receive a proper indication to release the UE context. And no further action is required.

[0249] FIG. 11 is a schematic block diagram of an exemplary wireless device/UE 1111, in accordance with certain embodiments described herein. Wireless device 1111 includes circuitry 1118 which may comprise one or more transceivers 1124 to facilitate transmitting wireless signals to and receiving wireless signals from radio access node 1120. Each transceiver 1124 include one or more transmitter 1126 and one or more receiver 1128 coupled to one or more antennas 1130. The circuitry 1118 also comprises one or more processors 1120 and a memory 1122.

[0250] The one or more processors may include any suitable combination of hardware and software implemented in one or more modules to execute instructions and manipulate data to perform some or all of the described functions of wireless device 1111, such as the functions of wireless device 1111 described above. In some embodiments, the one or more processors may include, for example, one or more computers, one or more central processing units (CPUs), one or more processors, one or more applications, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and/or other logic. In certain embodiments, the one or more processors may comprise one or more modules implemented in software. The module(s) provide functionality of the wireless device 1111 in accordance with the embodiments described herein, and in accordance with the steps executed at the wireless device 100 in FIG. 7. In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless device 1111 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0251] The memory is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a one or more processors. Examples of memory include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the one or more processors of wireless device 1111.

[0252] Other embodiments of wireless device 1111 may include additional components beyond those shown in FIG. 11 that may be responsible for providing certain aspects of the wireless device's functionality, including any of the functionality described above and/or any additional functionality (inducing any functionality necessary to support the solution described above). As just one example, wireless device 1111 may include input devices and circuits, output devices, and one or more synchronization units or circuits, which may be part of the one or more processors. Input devices include mechanisms for entry of data into wireless device 1111. For example, input devices may include input mechanisms, such as a microphone, input elements, a display, etc. Output devices may include mechanisms for outputting data in audio, video and/or hard copy format. For example, output devices may include a speaker, a display, etc.

[0253] FIG. 12 is a schematic block diagram of the wireless device/UE 1111 according to some other embodiments of the present disclosure. The wireless device 1111 includes one or more modules 1200 comprising a transmitting module 1201, receiving module 1202 and connecting module 1203, each of which is implemented in software. The module(s) 1200 provide the functionality of the wireless device/UE 1111 described herein.

[0254] FIG. 13 is a block diagram of an exemplary radio access node (e.g. gNB or eLTE eNB connected to NGCN) 1120, in accordance with certain embodiments. Radio access node 1120 includes circuitry which may include one or more of a transceiver, one or more processors, memory, and network interface. In some embodiments, the transceiver facilitates transmitting wireless signals to and receiving wireless signals from wireless device 1111/100 (e.g., via an antenna), the one or more processors executes instructions to provide some or all of the functionalities described above as being provided by a radio access node 1120, the memory stores the instructions for execution by the one or more processors, and the network interface communicates signals to backend network components, such as NGCN entities, a gateway, switch, router, Internet, etc.

[0255] The one or more processors may include any suitable combination of hardware and software implemented in one or more modules to execute instructions and manipulate data to perform some or all of the described functions of radio access node 1120, such as those described above (gNB 101A, eLTE eNB 101B or eNB 101C). In some embodiments, the one or more processors may include, for example, one or more computers, one or more central processing units (CPUs), one or more processors, one or more applications, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and/or other logic. In certain embodiments, the one or more processors may comprise one or more software modules that executes the method at the radio network node in accordance with FIG. 9B and FIG. 7.

[0256] The memory is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a one or more processors. Examples of memory include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information.

[0257] In some embodiments, the network interface is communicatively coupled to the one or more processors and may refer to any suitable device operable to receive input for radio access node 1120, send output from radio access node 1120, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. The network interface may include appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

[0258] Other embodiments of radio access node 1120 may include additional components beyond those shown in FIG. 13 that may be responsible for providing certain aspects of the radio network node's functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solutions described above). The various different types of network nodes may include components having the same physical hardware but configured (e.g., via programming) to support different radio access technologies, or may represent partly or entirely different physical components.

[0259] The one or more processors, interfaces, and memory similar to those described with respect to FIG. 11 may be included in other network nodes (such as core network entities described herein). Other network nodes may optionally include or not include a wireless interface (such as the transceiver described in FIG. 11). Functionalities described may reside within the same radio node or networks entities or may be distributed across a plurality of radios node and/or network entities.

[0260] FIG. 14 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node 1120 according to some embodiments of the present disclosure. This discussion is equally applicable to the NGCN entities such as MM Entity, SM entity, policy control function, MME, PGW, SGW, etc.

[0261] As used herein, a virtualized radio access node 1120 is an implementation of the radio access node 1120 in which at least a portion of the functionality of the radio access node 1120 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the radio access node 1120 includes the control system 20 that includes the one or more processors 22 (e.g., CPUs, ASICs, FPGAs, and/or the like), the memory 24, and the network interface 26 and the one or more radio units 28 that each includes the one or more transmitters 30 and the one or more receivers 32 coupled to the one or more antennas 34. The control system 20 is connected to the radio unit(s) 28 via, for example, an optical cable or the like. The control system 20 is connected via the network interface 26 to one or more processing nodes 36 coupled to or included as part of a network(s) 38. Each processing node 36 includes one or more processors 40 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 42, and a network interface 44.

[0262] In this example, functions 46 of the radio access node 1120 described herein are implemented at the one or more processing nodes 36 or distributed across the control system 20 and the one or more processing nodes 36 in any desired manner. In some particular embodiments, some or all of the functions 46 of the radio access node 1120 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 36. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 36 and the control system 20 is used in order to carry out at least some of the desired functions 46. Notably, in some embodiments, the control system 20 may not be included, in which case the radio unit(s) 28 communicate directly with the processing node(s) 36 via an appropriate network interface(s).

[0263] While not being limited thereto, some example embodiments of the present disclosure are provided below.

Embodiment 1

[0264] A method of operation of a wireless device (100, 1111) in a Next Generation system, comprising: [0265] sending a message via a radio access node to a control plane entity in NGCN, the message indicating the wireless device supports SRVCC in Evolved Packet Core, EPC mode; [0266] receiving instruction to connect to a neighboring radio access node that supports connectivity to an EPC network; and [0267] connecting to the EPC via the neighboring radio access node.

Embodiment 2

[0268] The method of embodiment 1 wherein the method further includes sending a radio message to the radio access node connected to the NGCN indicating supported wireless device SRVCC capabilities to UTRAN and/or GERAN and/or COMA when in EPC mode.

Embodiment 3

[0269] The method of embodiment 1 wherein the instruction to operate in EPC mode is a handover command or handover order or release with redirect to connect to the neighboring radio access node connected to the EPC network.

Embodiment 4

[0270] The method of embodiment 1 and 3, where in the neighboring radio access node is an eNodeB connected to the EPC network.

Embodiment 5

[0271] The method of embodiment 1 wherein the step of receiving instruction to operate in EPC mode is received after the wireless device has registered to IP multimedia subsystem, IMS or has established a Voice over IP session or Video call over IP.

Embodiment 6

[0272] A wireless device (100, 1111), comprising: [0273] at least one transceiver; [0274] at least one processor; and [0275] memory comprising instructions executable by the at least one processor whereby the wireless device (100, 1111) is operable to: [0276] send a message via a radio access node to a control plane entity in NGCN, the message indicating the wireless device supports SRVCC in Evolved Packet Core, EPC mode; [0277] receive instruction to operate in EPC mode via a neighboring radio access node that supports connectivity to an EPC network; and [0278] connect to the EPC via the neighboring radio access node.

Embodiment 7

[0279] A wireless device (100, 1111) adapted to: [0280] send a message via a radio access node to a control plane entity in NGCN, the message indicating the wireless device supports SRVCC in Evolved Packet Core, EPC mode; [0281] receive instruction to operate in EPC mode via a neighboring radio access node that supports connectivity to an EPC network; and [0282] connect to the EPC via the neighboring radio access node.

Embodiment 8

[0283] The wireless device (100, 1111) of embodiment 6 wherein the wireless device (100, 1111) is further adapted to operate according to the method of any one of embodiments 2 to 5.

Embodiment 9

[0284] A method of operation of a radio access node (101A, 1120) in a wireless system connected to a next generation core network, NGCN, comprising: [0285] receiving information indicating that SRVCC in Evolved Packet Core, EPC, mode is supported for a wireless device connected to the NGCN; [0286] determining whether handover of the wireless device to a selected neighboring radio access node that supports SRVCC and operating in EPC mode is required; [0287] if handover is determined, initiating handover of the wireless device to the selected neighboring radio access node operating in EPC mode.

Embodiment 10

[0288] The method of embodiment 9 wherein the method further comprises receiving from the wireless device information indicating supported wireless device SRVCC capabilities to UTRAN and/or GERAN and/or CDMA when in EPC mode.

Embodiment 11

[0289] The method of embodiment 10 wherein SRVCC capabilities of the selected neighboring radio access node are compatible with the wireless device SRVCC capabilities.

Embodiment 12

[0290] The method of embodiment 9 wherein the method further comprises receiving an indication from the NGCN that the wireless device is subject to SRVCC in EPC mode.

Embodiment 13

[0291] The method of embodiments 9 and 12 wherein the step of determining further comprises using the indication that the wireless device is subject to SRVCC in EPC mode to initiate handover to the neighboring radio access node that supports SRVCC and connectivity to an SRVCC capable EPC network.

Embodiment 14

[0292] The method of embodiment 9 wherein the step of determining comprises determining that radio coverage in the wireless system does not require initiating handover of the wireless device to the neighboring radio access node operating in EPC mode.

Embodiment 15

[0293] The method of embodiments 9 and 10 wherein the step of determining further comprises using the indication of support of SRVCC in EPC mode for the wireless device and the supported wireless device SRVCC capabilities to UTRAN and/or GERAN and/or CDMA when in EPC mode to determine if handoff to the neighboring radio access node operating in EPC mode is required.

Embodiment 16

[0294] The method of embodiment 9, wherein the information indicating that SRVCC in EPC mode is supported for the wireless device is received from the wireless device to indicate the wireless device is able to connect to the SRVCC capable EPC network.

Embodiment 17

[0295] The method of embodiment 9, wherein the information indicating that SRVCC in EPC mode is supported for the wireless device is received from the NGCN to indicate the NGCN and the wireless device support handover procedure to the neighboring radio access node connected to the SRVCC capable EPC network.

Embodiment 18

[0296] A radio access node (101A, 101B) in a wireless system, comprising: [0297] at least one processor; and [0298] memory comprising instructions executable by the at least one processor whereby the radio access node (101A, 101B) is operable to: [0299] receive information indicating that SRVCC in Evolved Packet Core, EPC, mode is supported for a wireless device connected to the NGCN; [0300] determine whether handover of the wireless device to a different radio access node operating in EPC mode is required; [0301] if handover is determined, initiate handover of the wireless device to the different radio access node operating in EPC mode.

Embodiment 19

[0302] A radio access node (101A, 101B) in a wireless system, the radio access node adapted to: [0303] receive information indicating that SRVCC in Evolved Packet Core, EPC, mode is supported for a wireless device connected to the NGCN; [0304] determine whether handover of the wireless device to a different radio access node operating in EPC mode is required; [0305] if handover is determined, initiate handover of the wireless device to the different radio access node operating in EPC mode.

Embodiment 20

[0306] The radio access node (101A, 101B) of embodiment 18 wherein the radio access node (101A, 101B) is further adapted to operate according to the method of any one of embodiments 10-17.

Embodiment 21

[0307] A method of operation of first control plane entity (102) in a core network, comprising: [0308] receiving from a wireless device via a radio access node a message indicating the wireless device supports SRVCC in Evolved Packet Core, EPC mode; [0309] sending a radio access network message to the radio access node indicating support of SRVCC in EPC mode in the core network and in the wireless device; [0310] upon receiving a handoff request indicating handover of the wireless device for EPC mode connectivity, determining if user plane anchor relocation to a corresponding EPC network is required; [0311] sending a handoff command to the corresponding EPC network indicating handover of the wireless device to EPC mode and indicating whether the user plane anchor relocation is required.

Embodiment 22

[0312] The method of embodiment 21, wherein the step of determining user plane anchor relocation further comprises sending a message to a second control plane entity (103) responsible for wireless device session management to determine if user plane anchor should remain in the core network or relocated to the EPC network.

Embodiment 23

[0313] The method of embodiment 21, wherein the method further comprises determining that the wireless device is subject to SRVCC in EPC mode and sending to the radio access node information indicating that the wireless device is subject for handover for SRVCC in EPC mode.

Embodiment 24

[0314] The method of embodiment 23, wherein the step of determining is based on information comprising at least one of wireless device performing IMS registration indication, and/or indication of establishment of a voice over IP session, and/or an indication the wireless device is attached to receive voice over IP services and/or that voice call continuity service is enabled for the wireless device.

Embodiment 25

[0315] A first control plane entity (102) in a core network, comprising: [0316] at least one processor; and [0317] memory comprising instructions executable by the at least one processor whereby the first control plane entity (102) is operable to: [0318] receive from a wireless device via a radio access node a message indicating the wireless device supports SRVCC in Evolved Packet Core, EPC mode; [0319] send a radio access network message to the radio access node to indicate support of SRVCC in EPC mode in the core network and in the wireless device; [0320] upon receiving a handoff request indicate handover of the wireless device for EPC mode connectivity, determining if user plane anchor relocation to a corresponding EPC network is required; [0321] send a handoff command to the corresponding EPC network to indicate handover of the wireless device to EPC mode and indicating whether the user plane anchor relocation is required.

Embodiment 26

[0322] A first control plane entity (102) in a core network, the first control plane entity adapted to: [0323] receive from a wireless device via a radio access node a message indicating the wireless device supports SRVCC in Evolved Packet Core, EPC mode; [0324] send a radio access network message to the radio access node to indicate support of SRVCC in EPC mode in the core network and in the wireless device; [0325] upon receiving a handoff request indicate handover of the wireless device for EPC mode connectivity, determining if user plane anchor relocation to a corresponding EPC network is required; [0326] send a handoff command to the corresponding EPC network to indicate handover of the wireless device to EPC mode and indicating whether the user plane anchor relocation is required.
The first control plane entity (102) of embodiment 26 wherein the first control plane entity is further adapted to operate according to the method of any one of embodiments 22-24.
Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.