Abstract:
One aspect includes a method of operating a user terminal adapted for wireless telecommunications using any of a plurality of different radio access technologies including a Circuit Switched, CS, access and a Packet Switched, PS access. The PS access includes access via a Long Term Evolution, LTE, network and WiFi access via a Wireless Local Area Network, WLAN. The method includes: (i) making a determination to switch from a PS LTE access to a WiFi access, (ii) switching to WiFi access, and (iii) ignoring or rejecting a command received to hand over to a CS access. Other aspects include a user terminal, a telecommunications network entity, and a method of operating a telecommunications network entity.

Description:
TECHNICAL FIELD 
       [0001]    The present invention relates to methods and apparatus in a telecommunications network for resolving conflicts that can arise when handing over calls between different wireless networks. In particular solutions are presented for resolving a competing Single Radio Voice Call Continuity handover and a handover to a WiFi access. 
       BACKGROUND 
       [0002]    IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) and Session Description Protocol (SDP) to set up and control calls or sessions between user terminals (or user terminals and application servers). Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. 
         [0003]    A User Equipment (UE) can access the IMS by attaching to an access network. If the access network is a Packet Switched (PS) network, such as an Evolved Packet Core (EPC)/Long Term Evolution (LTE) access network, an IMS session can be set up by the UE using SIP signalling. However, many existing access networks only support Circuit Switched (CS) technology for telephony with good enough quality of service, and procedures are well established for dealing with the provision of media and services to a UE accessing the IMS via a CS access network. 
         [0004]    There are many occasions when during a call/session it is required to transfer or hand over the call/session from one access network to another. Single Radio Voice Call Continuity (SRVCC) is described in 3GPP TS 23.237 and 3GPP TS 23.216, which specify procedures for handover of a voice call from a PS access to a CS access (e.g. transfer of a VoIP IMS session from an evolved UMTS Radio Access Network—E-UTRAN—to a UTRAN or GSM Edge RAN—GERAN). 
         [0005]    Accordingly, Voice over LTE (VoLTE) networks and devices that support co-existence with CS technology will normally have support for SRVCC. 3GPP TS 24.402 specifies procedures for non-3GPP access with the introduction of EPC integrated WLAN. This integrates WLAN as an additionally supported access technology to LTE and CS for a voice service (VoWiFi). However situations can arise where a competing or ‘race’ condition arises between a SRVCC (LTE to CS) handover and a WLAN handover (LTE to WiFi), when a UE leaves LTE coverage. 
         [0006]    More particularly, when a user device that supports VoLTE, VoWiFi and CS voice communications as well as SRVCC is attached to a LTE access and has an ongoing call that experiences a drop of signal quality, the device may decide to initiate a voice call handover to WiFi (if available). At the same time, the serving eNodeB (radio access node in LTE) may decide to initiate a SRVCC handover based on measurement reports received from the device. If these competing handover procedures are allowed to continue unchecked a potential call failure may occur. 
         [0007]    The embodiments presented herein address these problems, noting that it is normally desirable to maintain PS connectivity in order to maintain communication enrichments such as conversational video. 
       SUMMARY 
       [0008]    One aspect includes a method of operating a user terminal adapted for wireless telecommunications using any of a plurality of different radio access technologies including a Circuit Switched, CS, access and a Packet Switched, PS access. The PS access includes access via a Long Term Evolution, LTE, network and WiFi access via a Wireless Local Area Network, WLAN. The method includes: (i) making a determination to switch from a PS LTE access to a WiFi access, (ii) switching to WiFi access, and (iii) ignoring or rejecting a command received to hand over to a CS access. 
         [0009]    Another aspect includes a method of operating a telecommunications network entity to control which of a plurality of different radio access technologies is used to support a session of a user terminal. The radio access technologies include a Circuit Switched, CS, access and a Packet Switched, PS access. The PS access includes access via a Long Term Evolution, LTE, network and WiFi access. The method comprises: receiving a Session Initiation Protocol, SIP, re-INVITE message from a user terminal, the message indicating that the user terminal is attached to the network via a WiFi access; and sending instructions to other network entities to ensure that the terminal continues with the WiFi access and is not handed over to a CS access. 
         [0010]    Another aspect includes a user terminal adapted for wireless telecommunications using any of a plurality of different radio access methods including a Circuit Switched, CS, access and a Packet Switched, PS access. The PS access includes access via a Long Term Evolution, LTE, network and WiFi access. The user terminal is capable of switching between the different radio access methods. The user terminal is configured (i) to make a determination to switch from a PS LTE access to a WiFi access, and (ii) after switching to WiFi access to ignore or interrupt a command received to hand over to a CS access. 
         [0011]    Another aspect includes a telecommunications network entity configured as an Access Transfer Control Function, ATCF. The entity includes an interface for sending and receiving communications to/from other entities in the network, a processor, and memory having instructions implemented by the processor. On receiving a Session Initiation Protocol, SIP, re-INVITE message from a user terminal indicating that the user terminal is attached to the network via a WiFi access, the processor causes the entity to send instructions to other network entities to ensure that the terminal continues with the WiFi access and is not handed over to a Circuit Switched, CS, access. 
         [0012]    It is an advantage that IP (PS) connectivity can be maintained and that a coherent mechanism is provided for handling the situation where competing conditions arise between a SRVCC handover and a UE-initiated handover to WiFi. This minimizes the risk of call failure, and ensures that a call continues on a PS access whenever possible. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0013]      FIG. 1  illustrates schematically an IMS network in association with a cellular network architecture of a Packet Service access network; 
           [0014]      FIG. 2  illustrates schematically the principal network components involved in a SRVCC handover of a call from a PS access to a CS access. 
           [0015]      FIG. 3  is a signal diagram for a normal SRVCC handover of a call. 
           [0016]      FIG. 4  is a signal diagram of an embodiment of a procedure for avoiding a handover race condition in one set of circumstances. 
           [0017]      FIG. 5  is a signal diagram is a signal diagram of an embodiment of a procedure for avoiding a handover race condition in another set of circumstances. 
           [0018]      FIG. 6  is a schematic block diagram of a User Equipment (UE). 
           [0019]      FIG. 7  is a schematic block diagram of a network entity. 
       
    
    
     DETAILED DESCRIPTION 
       [0020]      FIG. 1  illustrates schematically how the IMS fits into the 3GPP cellular network architecture in the case of a Packet Service access network. As shown in  FIG. 1  control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer  1 , also referred to as the bearer plane and through which signals are directed to/from user equipment (UE) accessing the network. The entities within the connectivity layer  1  that connect an IMS subscriber to IMS services form a network that is generally referred to as the IP-Connectivity Access Network, IP-CAN (which in this case is the 3GPP Packet Service access network). The middle layer is the Control Layer  4 , and at the top is the Application Layer  6 . 
         [0021]    The IMS  3  includes a core network  3   a,  which operates over the middle, Control Layer  4  and the Connectivity Layer  1 , and a Service Network  3   b.  The IMS core network  3   a  includes nodes that send/receive signals to/from the 3GPP Packet Service access network at the Connectivity Layer  1  and network nodes that include Call/Session Control Functions (CSCFs)  5 , which operate as SIP proxies within the IMS in the middle, Control Layer  4 . The top, Application Layer  6  includes the IMS service network  3   b.  Application Servers (ASs)  7  are provided for implementing IMS service functionality. 
         [0022]    As shown in  FIG. 1 , a User Equipment (UE) can access the IMS by attaching to an access network and then over the Connectivity Layer  1 , which is part of a Packet Switched (PS) domain. For example, the UE may attach via an Evolved Packet Core (EPC)/Long Term Evolution (LTE) access. In that case an IMS session can be set up by the UE using SIP signalling. However, many existing access networks operate only using Circuit Switched (CS) technology, but a UE may also access IMS services via a CS domain  8 . Although the CS domain will not handle SIP, procedures are well established for dealing with the provision of media and services between the IMS and a UE using a CS access. 
         [0023]    There are many occasions when during a call/session it is required to transfer or hand over the call/session from one access network to another. There are a variety of factors that are used to determine when a call needs to be handed over to another access network. In general, the access network determines, based on the cells for which the UE reports measurements, when the conditions arise that require a request to be made to the core network for the call to be handed over. 
         [0024]      FIG. 2  illustrates schematically the principal network components involved in a Single Radio Voice Call Continuity (SRVCC) handover of an emergency call from a PS access network (which in the illustration is a LTE access network as exemplified by the eNodeB  21  base station) to a CS access network (which in the illustration is a GSM/WCDMA access network containing a NodeB  26  base station). A UE  20  accesses an IMS network over the PS access network. The UE  20  is capable of accessing both the CS and the PS access network and has corresponding interfaces for each type of access.  FIG. 2  shows the UE  20  in two positions: UE  20   a  using its PS access capability before the handover and UE  20   b  using its CS capability after the handover. 
         [0025]    The UE  20   a  initiates a call over the PS access and the call is routed to an end point (in this case a remote UE  30 ) via the IMS, as shown by the dashed line arrows  201 - 203 , followed by the solid arrows  204 ,  205 . Handover of the call from the PS to the CS access is controlled by a Mobile Management Entity (MME)  28 . After the handover of the call to the CS access, the call is routed from the UE 20   b  via the IMS as shown by the dotted line arrows  205 - 209 , followed by the solid arrows  204 ,  205 . 
         [0026]    The principal network entities shown for the PS access include the eNodeB  21 , and a Packet Data Network Gateway and a Serving Gateway (PGW &amp; SGW)  22 , hereafter referred to as S/PGW  22 . The call is routed via the IMS entities, Proxy-Call/Session Control Function (P-CSCF)  23  and an Interrogating-CSCF, which assigns a Serving CSCF, as illustrated by (I/S-CSCF)  25 . For the CS access, the principal network entities through which the call is routed include the NodeB  26 , and a Mobile Switching Centre (MSC) Server  27 . Also shown in  FIG. 2  in the IMS network is an Access Transfer Control Function (ATCF)  24 , and Session Call Continuity Application Server (SCC AS)  34 . 
         [0027]      FIG. 3  is a signal flow diagram illustrating the signalling that occurs in a SRVCC handover of a call. The network entities shown at the top of the diagram have the same reference numerals as those shown in  FIG. 2 , and illustrates an SRVCC handover of an ongoing multimedia telephony (MMTel) call  301  from a PS to a CS access. As shown the call  301  proceeds via the S/P-GW  22 , which shown in  FIG. 3  together with the MME  28 . The handover will transfer the call to a CS access, via the Target MSC/MGW  27 , which will become the anchoring node. At step  302  measurement reports sent by the UE  20  to the access network, E-UTRAN  36 , are analysed by the access network and determine, at step  303 , that a SRVCC handover to a CS access is required. A handover required indication  304  is sent to the MME  28 , which sends a handover request  305  to the MSC/MGW  27 , including information as to the target RAN  26  to which the call is to be handed over. Signals  306  and  307  between the MSC/MGW  27  and target RAN  26  prepare for the handover. Once established, the MSC/MGW  27  sends a SIP INVITE  308  including the new routing information for the handed over call to the I-CSCF  25 , which, at  309 , forwards this to the P-CSCF/ATCF  23 / 24 . At step  310 , the P-CSCF/ATCF  23 / 24  finds the anchored session, and at step  311  sends a command to an Access Transfer Gateway (not shown) to route the media via the CS access. 
         [0028]    The MSC/MGW  27  sends a PS to CS response  312  to the MME  28 , which sends a handover (HO) command  313  to the E-UTRAN  36 , which sends a handover command  314  to the UE  20 . Note that these steps may occur in parallel with steps  308  to  311  and it is not necessarily the case that the SIP INVITE  308  is received and acted upon in the IMS network before the UE  20  has received the handover command from the E-UTRAN at step  314 . At step  315  the UE retunes to the GERAN CS access. This results, as shown at step  316 , in handover detection, a suspension of procedures and handover detection at the target MSC/MGW  27 . Completion of the procedures is a shown at steps  317  to  326 . Importantly, at step  323  the P-CSCF/ATCF  23 / 24  sends a SIP INVITE to the SCC AS  34 , which, at step  324 , results in all media components except for the active voice/audio session being removed. Also, at step  322  the MSC/MGW  27  sends a location update to the user&#39;s Home Location Register (HLR). Finally, the signals shown at  326  complete the process and the voice call proceeds via the CS access. 
         [0029]    As previously explained, problems can arise if the UE decides to try to move to a WiFi access at the same time that a SRVCC handover is initiated. The embodiments described below establish a procedure that makes the IMS network and UE favor the handover to WiFi and abort the SRVCC handover. The procedures apply for cases when the UE detects and initiates a handover to WiFi before it has received a SRVCC handover command to hand over to a CS access. The procedures include features that impact the device (UE), as well as features that impact the IMS network. 
         [0030]    The UE, once it has decided to connect to WiFi, is configured not to act on a handover command when received from the LTE network, either by ignoring the command or by sending a reject message, and to send a SIP re-INVITE to the IMS network as soon as WiFi connectivity is established. The SIP re-INVITE includes an indication that WiFi is in use. 
         [0031]    In the IMS network, if a SRVCC INVITE has been received from an MSC before the re-INVITE is received from the UE with the indication of WiFi access, the IMS network will re-establish the session over the WiFi access, and will remove the session via the MSC. In the IMS, once the UE has sent the re-INVITE to announce its current access to be WiFi, a state parameter is set that will reject an incoming SRVCC INVITE from an MSC. This state will be cleared after a configurable timeout or when a new re-INVITE is received from the UE indicating that it is no longer communicating via WiFi access. 
         [0032]      FIG. 4  illustrates a procedure that provides a solution to this problem in a first scenario. In this case, as shown at step  401 , the SRVCC handover procedures are initiated in the network and a handover command  402  is sent to the UE (step  314  if  FIG. 3 ). Now, instead of the UE  20  retuning (step  315  in  FIG. 3 ), the UE  20  either ignores the handover command, or, as shown, sends a handover rejection  403  to the E-UTRAN  36 , and as soon as it is connected to WiFi sends a re-INVITE  404  to the IMS specifying a cause  48   x  (where x is a numeral in the range 0-9, to be assigned) or other indication that the UE is now using a WLAN connection. However, in this scenario the handover command is sent to the UE before the SIP INVITE (step  308  in  FIG. 3 ) is received and acted upon in the IMS network. At step  405  the P-CSCF/ATCF  23 / 24  forwards the re-INVITE to the SCC AS  34 , and 2000K messages  406 ,  407  are returned to the UE. Next, at step  408 , the P-CSCF/ATCF  23 / 24  sets a current access network parameter to WLAN, so that any subsequent SRVCC request message will be rejected. Thus, as shown at step  409 , when the anchor MSC/MGW  27  sends an INVITE specifying the connection routing for the SRVCC handover to CS access (as at step  308  of  FIG. 3 ). At step  410  the P-CSCF/ATCF  23 / 24  rejects this, because it has already set the current access parameter to WLAN at step  408 , by sending a  4 xx (where x and y are numerals in the range 0-9, to be assigned) error message  411  (i.e. an appropriate error message having an error code in the  400  range) via the I-CSCF  25  to the anchor MSC/MGW  27 . This is acknowledged at step  412 . At step  413  the MME  28  sends a PS to CS cancel notification to the target MSC/MGW  27 . Accordingly, as indicated at step  414 , because the session continues using WiFi, which maintains PS access, there is no need to remove the PS media components (as at step  328  of the SRVCC handover procedures illustrated in  FIG. 3 ). 
         [0033]      FIG. 5  shows the signalling sequence for the scenario where the SIP INVITE (step  308  in  FIG. 3 ) is received and acted upon in the IMS network before the re-INVITE is sent by the UE  20 . As shown, once the SRVCC handover procedures have been initiated in the network a handover command  501  is sent to the UE (step  314  in  FIG. 3 ). The UE  20  either ignores the handover command or, as shown, responds by sending a handover rejection  502  to the E-UTRAN  36 . At step  503  the Anchor MSC/MGW  27  sends an INVITE to the IMS to initiate the SRVCC handover procedure. At step  504  the ATGW (not shown) is ordered to start redirecting media from PS to CS access (step  311  of  FIG. 3 ). At step  505  a SIP 2000K message is sent to the anchor MSC/MGW  27  and this is acknowledged at step  506 . At step  507 , the P-CSCF/ATCF  23 / 24  forwards the SRVCC SIP INVITE to the SCC AS  34 , which returns a SIP  200  OK at step  508 . At step  509  the SCC AS  34  initiates a fallback timer. This is a standard procedure (see 3GPP TS 24.237) used to allow the call to fall back to the PS access if the quality of the communications recover to an acceptable level before the timer has timed out, or if for any reason the UE  20  cannot complete the SRVCC handover. 
         [0034]    Now, at step  510 , the UE  20  has successfully connected to WiFi via a WLAN and sends a SIP re-INVITE to the IMS (in the same way as it did in the  FIG. 4  scenario at step  404 ). This is forwarded to the SCC AS  34  at step  511 . Assuming that this is received before the fallback timer has timed out, then at step  512  a 200 OK message is returned back to the UE  20  and at step  513  the fallback timer is stopped (before it has timed out). Note that if the fallback timer times out before the re-INVITE is received, then the SRVCC handover to CS will proceed, but because the UE is connected to WiFi the call will be dropped. 
         [0035]    Finally, there are two possibilities for completing the process such that the established session with the Anchor MSC/MGW  27  is stopped and the call proceeds using WiFi. These are denoted as options A and B in  FIG. 5 . In option A the P-CSCF/ATCF  23 / 24  sends a SIP BYE  514  to the MSC/MGW  27 , which responds with a SIP 200 OK message  515 . When subsequently the MME  28  sends a PS to CS cancel notification  516 , the anchor MSC/MGW  27  can ignore this because there is no longer any session to be cleared at the ATCF  24  (as shown at step  517 ). In Option B, when a PS to CS cancel notification  518  is received from the MME  28 , the Anchor MSC/MGW  27  sends a SIP BYE  519  with a Q.850 cause to the P-CSCF/ATCF  23 / 24 . This is forwarded at step  520  to the SCC AS  34 , which then returns a SIP 200 OK message  521  via the P-CSCF/ATCF  23 / 24  to the MSC/MGW  27 . 
         [0036]      FIG. 6  is a schematic illustration of the principal functional components of a user terminal  60 , such as UE  20  described above. The user terminal  60  is adapted for wireless telecommunications and includes a transceiver  61  for sending and receiving wireless communications, a processer  62  for executing program instructions and a memory  63  storing program instructions and data. The terminal is configured to be able to communicate using any of a number of different radio access methods and includes functional modules, including a CS module  66  for communicating using a CS access, and PS access modules that include a LTE access module  65  and a WiFi access module  64 . The program instructions in the memory  63  include instructions that enable the terminal  60  to be able to switch between the different radio access methods, and include instructions that enable the terminal (i) to make a determination to switch from a PS LTE access to a WiFi access, and (ii) after switching to WiFi access to ignore or interrupt a command received to hand over to a CS access. The user terminal  60  may also be configured to perform any of the functionality required of the UE  20  described above. 
         [0037]      FIG. 7  is a schematic illustration of the principal functional components of a telecommunications network entity  70  configured as an ATCF, such as the ATCF  24  described above. The network entity  70  includes an interface, or transceiver  71  for sending and receiving communications to/from other entities in the network, a processor  72 , and a memory storing data and instructions implemented by the processor. The instructions cause the processor, on receiving a SIP re-INVITE message from a user terminal indicating that the user terminal is attached to the network via a WiFi access, to send instructions to other network entities to ensure that the terminal continues with the WiFi access and is not handed over to a CS access. The network entity  70  may also include programming instructions that cause the processor  70  to implement any of functions of the P-CSCF/ATCF  23 / 24  described above. 
         [0038]    The embodiments described above provide a solution for allowing IP (PS) connectivity to be maintained and assuring coherent handling in the situation where competing conditions arise between a SRVCC handover and a UE-initiated handover to WiFi. This minimises the risk of call failure, and ensures that a call continues on a PS access whenever possible.