RESOLVING COMPETING HANDOVER CONDITIONS IN WIRELESS NETWORKS

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.

Claims

1.-2. (canceled)

3. 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 including a Circuit Switched, CS, access and a Packet Switched, PS access, wherein the PS access includes access via a Long Term Evolution, LTE, network and WiFi access, the method comprising: 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.

4. The method of claim 3, further comprising, after receiving the re-INVITE message, and upon receiving a message from a Mobile Switching Centre, MSC, requesting a hand-over to CS access, sending a response rejecting the handover request together with an error indication.

5. The method of claim 3, further comprising, after receiving a message from a MSC requesting a handover to CS access and initiating a handover procedure, and on receiving the re-INVITE message, terminating the handover procedure.

6. The method of claim 5, further comprising, on receiving the message requesting a handover to CS access, initiating a fallback timer, wherein receiving the re-INVITE message stops the fallback timer to terminate the handover procedure.

7. The method of claim 5, further comprising, on receiving the re-INVITE message, sending a message to the MSC to terminate the handover procedure.

8. 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, wherein the PS access includes access via a Long Term Evolution, LTE, network and WiFi access, wherein the user terminal is capable of switching between the different radio access methods, and wherein 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.

9. The user terminal of claim 8, wherein the user terminal is configured to access an IMS network, and on receiving a command to hand over to CS access after making the determination to switch to WiFi access, to send a Session Initiation Protocol, SIP, re-INVITE message to the IMS network as soon as it has established WiFi access.

10. A telecommunications network entity configured as an Access Transfer Control Function, ATCF, comprising: an interface for sending and receiving communications to/from other entities in the network, a processor; and memory having instructions implemented by the processor, wherein, 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.

11. The network entity of claim 10, further configured, after receiving the re-INVITE message and subsequently receiving a message from a MSC requesting a hand-over to Circuit Switched, CS, access, to return a message to the Mobile Switching Centre, MSC, rejecting the handover request together with an error indication.

12. The network entity of claim 10, further configured, on receiving the re-INVITE message after receiving a message from a MSC requesting a handover to CS access, to initiate termination of the handover procedure.

13. The network entity of claim 12, further configured, on receiving the message requesting a handover to CS access, forwarding the message to a Session Call Continuity Application Server, SCC AS, to initiate a fallback timer and on receiving the reINVITE message, forwarding the re-INVITE message to the SCC AS to stop the fallback timer so as to terminate the handover procedure.

Description

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 3a, which operates over the middle, Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a 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 3b. 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 20a using its PS access capability before the handover and UE 20b using its CS capability after the handover.

[0025] The UE 20a 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 UE20b 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 & 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'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 48x (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 4xx (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.