US11032746B2

US11032746B2 - Voice service handover

Info

Publication number: US11032746B2
Application number: US16/624,419
Authority: US
Inventors: Francisco FAUS GREGORI; Alistair GOMEZ
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2017-06-23
Filing date: 2018-06-06
Publication date: 2021-06-08
Anticipated expiration: 2038-06-06
Also published as: US20200221352A1; WO2018234037A1; CN110771204B; EP3643113A1; CN110771204A

Abstract

A user entity (UE) such as a smartphone is configured to connect to both WiFi and a Long Term Evolution (LTE) cellular network for voice and data services. For voice, the UE supports both Voice over LTE (VoLTE) and Voice over WiFi (VoWiFi). When the UE is connected to VoWiFi and roaming from a first WiFi access point to a second WiFi access point, the UE and Mobility Management Entity in the cellular network carry out a preparatory handover to VoLTE to prevent service loss in the event of an unsuccessful VoWiFi connection from the second WiFi access point.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a National Phase entry of PCT Application No. PCT/EP2018/064878, filed Jun. 6, 2018, which claims priority from European Patent Application No. 17177601.6 filed Jun. 23, 2017, each of which is fully incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates to voice data communications and in particular to a method for improving the reliability of a voice service during device movement.

BACKGROUND

Long Term Evolution (LTE) is an all Internet Protocol (IP) packet switching based cellular network architecture for replacing the older Third Generation (3G) cellular networks.

Mobile network operators (MNOs) have established and maintain LTE cellular networks to provide network coverage to subscribers over a geographical area such as a country. The LTE network has a Radio Access Network (RAN) for providing wide area geographic wireless coverage to subscriber user entity (UE) devices. Wireless data exchanged between the UE and RAN are converted and carried by a wired backhaul network to an Evolved Packet Core (EPC) which provides management functions and also gateways to external networks.

The RAN is formed of a number of cellular base stations, each providing radio communication over a geographic range of several kilometers. The MNO will manage the deployment of cellular base stations so the coverage of each base station overlaps with its neighboring base stations in order to provide an optimal balance between network coverage and base station deployment.

A subscriber UE/mobile device such as a smartphone can connect to the RAN via one of the base stations. The UE is authenticated by core network entities such as the Mobility Management Entity (MME) against a user directory known as a Home Subscriber Server (HSS) and then can communicate with external networks.

Due to the coverage overlap between base stations, at any given location the mobile device will often be within range of a number of base stations forming the RAN. The UE is configured to measure the signal strength to each base station and select the base station providing the strongest cellular signal connection. Being mobile, when the mobile device changes location, a different one of the base stations in the RAN may provide a stronger signal connection. In this case the mobile device will be either moved to the new base station by the existing base station when the mobile device is active in a call using a process known as handover, or when the mobile device is idle, it may itself decide to camp on a different base station in a process known as idle mode reselection.

While base stations provide wide area geographic coverage, there will often be coverage gaps due to local interference. Furthermore in densely populated areas, a base station may be overloaded due to a high number of mobile devices.

Wi-Fi offload is a way of using non-cellular wireless networks to fill in coverage gaps and reduce cellular network load. Wireless local area networks (WLANs) generated by Access Points (APs) operating in accordance with the Institute of Electrical and Electronic Engineers (IEEE) 802.11 family of protocols known as WiFi™ can be used to provide non-cellular network based wireless connectivity between mobile devices. External networks such as the Internet can be accessed via a backhaul such as a broadband link.

APs and therefore WLANs are often located in indoor locations and therefore can be used where there are cellular network coverage gaps or in densely populated areas to provide a different path for cellular network traffic into the cellular network core. This reduces the load on the RAN of cellular network base stations.

To support non RAN access paths, the EPC includes an evolved Packet Data Gateway (ePDG) for providing access to core network services and also Internet Multimedia Services (IMS) from “non-trusted” access networks.

LTE and WiFi therefore provide data connectivity between a UE, cellular network services hosted in the IMS and external network resources.

The MMTel is hosted in an IP Multimedia Sub-System (IMS) for replacing traditional voice services. With LTE, the traditional circuit switched voice services are replaced with Voice over Long Term Evolution (VoLTE). When the UE is connected to a WLAN, the UE communicates with the same IMS voice service and is known as Voice over WiFi (VoWiFi) or WiFi calling. VoLTE and VoWiFi are therefore two equivalent communication paths for voice data to travel from a telephony dialer application in a UE.

With the presence of the additional access path into the cellular network, the cellular network system is configured to support voice service handover from VoLTE to VoWiFi and from VoWiFi to VoLTE so that the most suitable macrocell or Wireless access point is used at any given location and time.

Typically when a UE is actively using IMS voice services, the following handovers are common:

- VoLTE to VoLTE (in the case of moving from the coverage area of a macrocell to another macrocell),
- VoLTE to VoWiFi when entering an indoor location (such as a user arriving home and connecting to their home WLAN) or
- VoWiFi to VoLTE when leaving an indoor location (such as a user leaving their home WLAN).

A fourth scenario exists: VoWiFi to VoWiFi migration whereby the UE can handover from one Wi-Fi access point to another Wi-Fi access point.

VoWiFi to VoWiFi has a higher risk of failure due to the short range of each individual access point and the movement of the mobile device. In the event of a failure to connect to the new access point, the mobile device may be unable to reconnect to the original wireless access point.

This will result in a disconnected call and following the disconnection, the mobile device will need to initiate a connection to VoLTE via a macrocell. However the extra delay will be detrimental to customer experience since a call was dropped during the failed handover.

To mitigate this problem, the typical process is to replace a direct VoWiFi to VoWiFi handover with two handovers, namely VoWiFi to VoLTE handover followed by a VoLTE to VoWiFi handover to a new access point.

Such a process is inefficient due to the overhead of the second handover but is regarded as a better solution than an unreliable handover mechanism.

SUMMARY

Aspects of the disclosure are directed to this problem.

In one aspect, an embodiment of the present disclosure provides a method of operating a mobility management entity in a cellular network core in response to a connection request from a cellular client device for connectivity to a voice service accessible via the cellular network core, the method comprising: receiving a request by the cellular client device to access the voice service; analyzing the request to identify the presence of an identifier indicating that the request is a provisional request; if the request contains the identifier, performing a first subset of operations from a set of operations to establish a link between the mobile device and the voice service; determining whether a further instruction to complete the link between the mobile device and the voice service has been received within a predetermined period of time; and if the further instruction has been received, processing a second subset of operations to complete the link between the mobile device and the voice service.

In a further aspect, an embodiment of the present disclosure provides an apparatus in a cellular network core for managing, a connection request from a cellular client device for connectivity to a voice service accessible via the cellular network core, comprising: means for receiving a request by the cellular client device to access the voice service; means for analyzing the request to identify the presence of an identifier indicating that the request is a provisional request; means for performing a first subset of operations from a set of operations to establish a link between the mobile device and the voice service, if the request contains the identifier; means for determining whether a further instruction to complete the link between the mobile device and the voice service has been received within a predetermined period of time; and means for processing a second subset of operations to complete the link between the mobile device and the voice service if the further instruction has been received.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present disclosure will now be described with the aid of the accompanying Figures in which:

FIG. 1 schematically shows a system overview of the first embodiment;

FIG. 2 schematically shows a system of FIG. 1 after the UE shown in FIG. 1 has changed location;

FIG. 3 schematically shows a functional component view of the UE;

FIG. 4 is a flowchart showing the operation of the provisional link manager;

FIG. 5 is a flowchart showing the operation of the VoLTE/VoWiFi handover controller;

FIG. 6 schematically shows a functional block diagram of the Multimedia Mobility Entity (MME) illustrated in FIG. 1; and

FIG. 7 is a flowchart showing the operation of the MME in the first embodiment.

DESCRIPTION

System Overview

FIG. 1 shows an overview of the main components in a telecommunications communication system 1 according to the first embodiment. The system 1 has several functional subsystems:

a Long Term Evolution (LTE) cellular network 3 infrastructure;

non-cellular network infrastructure

5 including a local network and Internet Service Provider (ISP) architecture; and

an IP Multimedia Subsystem (IMS) 7.

The LTE cellular network 3 provides cellular network client/mobile devices, known as User Entities (UE) such as mobile telephones 9 with data and voice services using a packet-switched IP network. The LTE cellular network 3 includes an Evolved Packet Core (EPC) 11 and a radio access network (RAN) formed of cellular base stations known as eNodeBs 13 for connecting services and resources in the EPC 11 to the UEs 9. The EPC 11 contains control functions such as a Multimedia Mobility Entity (MME) 31, a Home Subscriber Server (HSS) 33, and a Policy Configuration Rules Function (PCRF) 35. For routing data packets into and out of the EPC 11, there are a number of Serving Gateways (SGW) 37 connected to the eNodeBs 13 and Packet Gateways (PGW) 39 connected to external resources such as the Internet 23 and the IMS 7.

The IMS 7 is an IP data network which provides a unified service architecture for all networks. Multiple services can be provided on a single control/service layer even though the access networks may be different. The IMS 7 therefore reduces the need for duplication in data services/applications. The VoLTE and VoWiFi voice calling services are hosted in an application server within the IMS 7 which in this embodiment is provided by a service known as the Multimedia Telephony Service (MMTel) 15.

The non-cellular network infrastructure 5 includes a plurality of wireless access point/modem router devices 17, each device hereinafter referred to as a hub 17, each of which is located at a user premises such as a home, shop or office. Each hub 17 generates a wireless local area network (WLAN) 19 in accordance with the IEEE 802.11 family of standards, in this embodiment 802.11ac, to allow communication between the hub 17 and the UEs 9. The routing functionality of the hub 17 also allows communication between the UE and other WLAN only devices and also wired Local Area Network (LAN) devices such as a computer 10. The routing function also provides for external network access, in this embodiment each hub 17 communicates with an Internet Service Provider (ISP) 21 via an xDSL modem (not shown) which routes data packets via a wide area network such as the Internet 23 to external servers and remote users.

In this embodiment, the hubs 17 are managed by the same entity and therefore are configured to generate WLANs having the same service set identifier (SSID), i.e. network name and having similar wireless network configurations.

The LTE cellular network 3 allows UEs 9 to access the EPC 11 services via a non-cellular network such as a WLAN 19. The LTE cellular network 3 also includes an Evolved Packet Data Gateway (ePDG) 25 which is a termination point for secure data tunnels, in this case using the IP Security (IPSec) protocol, with the UE 9 over non-trusted 3^rdGeneration Partnership Project (3GPP) systems. The WLAN 19 is “non trusted” in that it is not owned by the cellular network. The ePDG and use of data tunnels allows UE data to be routed into the EPC 11 for processing within the LTE cellular network 3 and IMS 7 network.

Behavior of UE for Using the WLAN and LTE Interfaces

The UE 9 has both WLAN and LTE radio interfaces for accessing the non-cellular network infrastructure 5 and the LTE cellular network 3 respectively and furthermore is configured to support voice calls over VoWiFi and VoLTE respectively.

Since an eNodeB 13 of the LTE network 3 has a larger geographical coverage range than the WLANs 19, in most areas the UE will be connected to the LTE network 3 and will use the LTE network for data services including VoLTE for voice calls.

However, when the UE is within range of a WLAN 19 such as shown in FIG. 1, there is overlap in the connectivity ranges of the two different access networks, and the UE 9 can connect to data services using either the cellular interface or the WLAN interface. A typical default UE policy is that a WLAN connection is preferred. So when a UE is connected to the LTE network 3 and it detects a known WLAN 19, the UE 9 will try to use the WLAN 19 for data services, for example email, web browsing, etc. In the case of more time critical applications such as VoWiFi voice services, these services would be used only if the WLAN signal quality is higher than a signal minimum strength threshold which should ensure a minimum quality of experience for the user. If the signal strength is not sufficient, then the UE may use the WLAN for data services and maintain a VoLTE link to the cellular network.

Therefore upon detection of a known WLAN 19, the UE 9 will enable its WLAN interface and provided the signal strength is sufficient, it will disable its cellular interface causing any existing cellular data services to also be disconnected. In the case of the WLAN signal strength being too low to support VoWiFi, then the LTE connection will be maintained to support only VoLTE while other data services will use the WLAN 19.

This change is generally transparent to the user of the UE as it has little impact to the operation of services such as file transfers and web browsing. Where a plurality of WLANs is available to a UE 9, the UE will measure the signal strength to each of the WLANs and typically select the strongest one for connection.

In the example shown in FIG. 1, the UE 9 has connected to WLAN 19 a generated by hub 17 a and a data tunnel is established via the ISP 21 to the ePDG 25 of the UE's subscribed cellular network. Since the WLAN signal strength is sufficiently high, UE 9 can establish a VoWiFi session with the MMTel 15 voice service in the IMS 7.

FIG. 2 shows the network system shown in FIG. 1 at a later point in time where the UE 9 has moved to a different location which is closer to the second WLAN 19 b of the second hub 17 b. Although the distances are not drawn to scale, the UE 9 can be assumed to have travelled far enough from the first hub 17 a that the signal strength has deteriorated such that the signal strength to the hub 17 a is much lower than the signal strength to hub 17 b.

Unlike a base station 13 in a cellular network, the hub 17 in a WLAN setting is not responsible for UE movement decisions between hubs. The decision to select a new hub 17 is taken by the UE 9 itself and this movement will be referred to as roaming to differentiate this WLAN to WLAN connection behavior from the handover and idle mode reselection behavior of the UE when connected to a cellular network.

According to the standard behavior, when the signal strength to the hub 17 a has dropped below a predetermined threshold, the UE 9 will send probe requests for other hubs 17 within range. When the UE determines that the signal strength to the WLAN of a second hub 17 b is higher than the current connection to the WLAN of the first hub, and in some cases also above a second threshold margin, the UE will roam to the second hub 17 b, involving the standard authentication (if any) and association, so that connectivity to data services of the UE can be restored via the second hub 17 b.

In this embodiment the UE 9 has the necessary credentials to connect to either

hub

17 a,17 b. The

hubs

17 a,17 b form part of a hotspot network such that they share the same SSID and layers 2/3 connectivity configuration. In this way the hubs have different PHY and data link layer identity information, but the differences are transparent to the higher network layers of the device.

While the roaming operation may not be particularly noticeable to time insensitive applications such as file transfers and web browsing, active voice applications over VoWiFi are particularly sensitive to any disruptions that may occur during the change of hub 17.

Due to the relatively short range of Wi-Fi networks, if the UE 9 is moving quickly through the coverage area of a WLAN, it may be able to connect to the WLAN for general data access, but not be able to establish the further VoWiFi connection required for voice communications before it has left the range of WLAN 19. In a case where the UE cannot maintain a connection to the EPC 11 and IMS 7, the user experience will suffer and be manifested as a dropped call or being unable to make a new call. A WLAN 19 b connection may also fail when the UE does not have the correct credentials for accessing the WLAN 17 b, or when a WLAN 19 b fails at the time of connection, etc.

Since it is not possible to determine in advance whether the WLAN selected by the UE will be able to support VoWiFi, the conventional approach is to disable the ability for VoWiFi to VoWiFi handovers. Instead the UE can be configured so that whenever the UE switches to a different WLAN, it will perform a VoLTE connection from VoWiFi before subsequently trying to handover back to VoWiFi via the hub 17 b.

However this processing incurs a large time penalty as the two handovers are established and completed.

In the first embodiment, the UE 9 will try to move directly from one hub 17 a to another hub 17 b to maintain a VoWiFi connection without a full intermediary VoLTE handover.

Pre-Emptive Processing

To prevent the earlier discussed issues with service breaks due to failed WLAN to WLAN roaming, the processing of the UEs 9 and EPC 11 are modified to allow a pre-emptive handover to VoLTE without committing full resources to the VoLTE handover.

The UE 9 is modified so that will attempt a direct VoWiFi to VoWiFi handover, but to prepare for the case that the roaming to hub 17 b is not successful, the UE 9 and MME 31 of the EPC 11 coordinate to begin establishing a VoLTE handover with the LTE network so that if the connection to the hub 17 b is not successful, the handover to VoLTE can be established more quickly.

System Components

UE Internals

FIG. 3 shows the internal components of a UE 9 in accordance with the first embodiment.

UE

9 is a mobile device such as a smartphone having a processor, persistent and working memory, LTE modem, Wi-Fi chipset, screen and input etc. (not shown).

When software instructions stored in an area of the permanent storage are executed by the processor, the UE 9 can be regarded as a set of functional components working in conjunction with the hardware elements.

As shown in FIG. 3, the UE functional components include a set of applications and services layer 61, an operating system 63, a data link controller 65, an LTE interface 67 and a Wi-Fi interface 69.

The Application and services layer 61 contains a variety of apps such as the telephony voice app 71 for enabling the user to make IMS voice calls using VoLTE or VoWiFi and other related services such as the Short Messaging Service (SMS) for sending text messages. Other apps such as VoIP calls and productivity applications which interact directly with the user would also be present in this layer.

The Operating system 63 provides the interface between the physical hardware of the UE 9 and the applications and services layer and the user. Typical UE operating systems include iOS™ and Android™. In this embodiment, the OS includes a VoWiFi/VoLTE handover controller 73 and a provisional link manager 75 which will be explained later when other components have been introduced.

The LTE interface 67 includes the antenna and transceiver hardware and also software to control the operation of the LTE hardware to allow the UE 9 to communicate with external data resources via an LTE network.

The Wi-Fi interface 69 includes a suitable antenna, transceiver hardware and software to allow the hardware to communicate with a WLAN 19.

The data link controller 65 is positioned between the Operating System and the LTE interface and the Wi-Fi interface 69 and is responsible for choosing one of the relevant interfaces for use by the UE to access data resources.

As mentioned earlier, when only Wi-Fi is available, the data link controller will ensure that the WiFi interface is used to carry data traffic to external networks. When only LTE is available, the opposite will occur where the LTE link carries the traffic. In the event that both Wi-Fi and LTE are present, then typically the UE is configured to favor the Wi-Fi interface since this offloads UE data traffic from the LTE network.

Components in the First Embodiment

In the first embodiment, the UE also contains a VoWiFi/VoLTE handover controller 73 and provisional link manager 75 in the Operating System 63 and a Wi-Fi roaming detector 77 in the data link controller 65.

The Wi-Fi roaming detector 77 is responsible for monitoring the behavior of the Wi-Fi interface and detect when the UE attempts to move from an existing WLAN connection with a first hub, to a new WLAN provided by a second hub.

The Wi-Fi roaming detector 77 is placed into a ready state when the UE starts to send probe requests to determine if there are surrounding hubs since this is a sign that the signal strength to the hub 17 a is deteriorating. When the UE 9 actually tries to initiate authentication and association with the hub 17 b, then the VoWiFi/VoLTE handover controller 73 triggers the pre-emptive processing to mitigate an unsuccessful roaming as will be described below.

While the data link controller 65 manages whether the LTE or WLAN interface is used by the UE, the VoWiFi/VoLTE handover controller 73 is responsible for managing the voice link to the IMS. For example, this controller 73 will manage the conventional VoLTE to VoWiFI handovers and also VoWiFi to VoLTE handovers.

In the first embodiment, a LTE provisional link manager 75 forms part of the VoWiFi/VoLTE controller 73 and performs processing with regard to the VoWiFi service when the UE roams to a different access point. When this function is notified by the Wi-Fi roaming detector that the UE is roaming to a new Wi-Fi access point, the LTE provisional link manager 75 establishes a VoLTE provisional link to the IMS voice service via the cellular network as a contingency in case the roaming operation to the new WLAN is not successful for maintaining the VoWiFi service.

If the Wi-Fi roam is successful, then VoWiFi session can be recovered from the new access point and the resources that have been allocated within the EPC can be recovered. However, if the Wi-Fi roam is not successful, then the remaining steps to connect to VoLTE can be completed so that any interruption in service can be minimized.

The operation of the modified UE and MME will now be explained with reference to the following flowcharts.

Flowchart of the Operation of the UE

FIG. 4 shows the processing carried out by the provision link manager 75 when a notification is received from the Wi-Fi roaming detector 77 that a Wi-Fi access point roaming operation is taking place.

In s1, a notification is generated and sent to the VoWiFi/VoLTE handover controller 73 that a provisional request for VoLTE is required.

After notifying the VoWiFi/VoLTE handover controller 73, in s3, the provisional link manager 75 waits a predetermined period of time to allow for a VoWiFi connection to be successfully established. The standard procedure will be to first join the WLAN 17 b and then establish a data link to the MMTel service 15 of the IMS.

In s5, after the predetermined period of waiting time has elapsed, the success of the VoWiFi connection is determined based on whether a notification has been received from the Wi-Fi roaming detector 77. If the VoWiFi connection is successful, then in this embodiment in s7 the VoWiFi/VoLTE handover controller 73 is notified that the provisional VoLTE connection is not required and processing ends.

However, if in s5 the VoWiFi connection was not unsuccessful, then the provisional link to enable handover to VoLTE must be utilized to avoid a voice service disconnection.

Now that the VoLTE connection is required and resources have been committed, it is preferable to avoid the situation where a late response VoWiFi success message could interfere with the initiated VoLTE handover. Therefore a way to hold off any late VoWiFi messages is required and in this embodiment, in s9 the provisional link manager 75 blocks the network port used by VoWiFi at the OS level.

In s11, the provisional link manager 75 notifies the VoLTE/VoWiFi controller 73 to continue with establishing the VoLTE link and then in s13 waits for a second predetermined period of time to allow time for the VoLTE handover to complete.

After the second predetermined period has elapsed, in s15 a test is carried out to check whether the VoLTE handover has occurred. If the VoLTE handover was successful, then in s17 the block on the network port used for VoWiFi is maintained to prevent possible flip flopping between VoLTE and VoWiFi now that a connection has been established. Then processing ends for this roaming cycle.

Conversely, if the VoLTE handover has not successfully completed, in s19 the network port used by VoWiFi is unblocked so that a connection to VoWiFi may be again attempted. However at this point there is likely to be a break in service such as a missed call. Then processing ends for this roaming cycle.

The above flowchart shows the operation of the UE 9 in response to changing location such that it will leave the range of a currently connected hub 17. The process will be repeated each time the UE 9 needs to roam to a different hub 17.

Flowchart of the Operation of the VoLTE/VoWiFi Handover Controller

FIG. 5 shows the operation of the VoLTE/VoWiFi handover processor 73 in the first embodiment to implement the pre-emptive VoLTE processing when a VoWiFi to VoWiFi roam is detected.

The process begins when a notification is received from the provisional link manager 75 that a VoLTE provisional link is required. In s21, in response to the notification, the VoWiFi/VoLTE handover controller 73 initiates a connection to a base station of the cellular network and once a Radio Resource Control (RRC) cellular session has been established, the VoWiFi/VoLTE handover controller 73 sends a modified attach request to the MME 31. The modification in the attach request is the addition of a “Handover Preparation” field which can be interpreted by the MME 31.

In s23, the VoWiFi/VoLTE controller 73 waits for an update message from the provisional link manager 75 regarding the result of the VoWiFi roaming procedure as described in s7 or s11 in FIG. 4.

After a predetermined period of time has elapsed, a message from the provisional link manager 75 should have been received and the contents of the message are analyzed in s25 to determine whether the message is to confirm the requirement for a VoLTE handover or not.

If the message is a confirmation that the VoLTE handover is required (because the VoWiFi roam operation failed), then in s27 the VoWiFi/VoLTE controller 73 sends a confirmation message to the MME 31 so that the provisional VoLTE handover prepared by the MME 31 can proceed. Processing by the VoWiFi controller ends after this until the next time the UE is connected to VoWiFi and attempts to handover to another hub in the network.

Alternatively, if the message is a notification to cancel the VoWiFi handover because the VoWiFi roam operation was successful, then the VoLTE/VoWiFi handover controller 73 will delete any allocated resources in s29 and processing ends.

Components of the MME

FIG. 6 shows the functional components of the MME in the first embodiment.

The MME 31 contains an eNodeB interface 81, a HSS interface 83, an SGW interface 85, a session and mobility management controller 87, an LTE attach request processor 89 and a Tracking Area list 91.

As is conventional, the MME 31 is an entity within the cellular EPC for managing the control plane and therefore contains a number of network interfaces for communication with other entities of the cellular network.

The eNodeB interface 81 is used by the MME 31 to communicate with any eNodeBs in the cellular network such as macrocells and small cells forming the radio access network (RAN) of the cellular network. The link between the eNodeB interface 81 and the eNodeBs forming the RAN is known as the S1-MME interface.

The HSS interface 83 is used by the MME to communicate with the HSS of the cellular network and to access subscriber information about an attaching UE. In particular, the MME accesses the HSS to obtain authentication vectors for the attaching UE. The link between the HSS interface 83 and the HSS is known as the S6 a interface.

The SGW interface 85 is used by the MME to connect a UE to a one of the external networks accessible via the cellular EPC. The link between the SGW interface 83 and the SGWs is known as the S11 interface.

The MME also includes a function for session and mobility management 87 to manage UE handover to different eNodeBs in the RAN as the UE moves around the geographic coverage area and therefore needs to be connected to a different eNodeB of the cellular network RAN.

An LTE attach request processor 89 is responsible for processing new UEs which have enabled their radios and wish to connect to the cellular network. These UEs may have just been switched on, or may be leaving the range of a WLAN. As part of the handshake to join the cellular network via an eNodeB of the cellular network, the UE will send an LTE attach request to an eNodeB which in turn forwards that request to the MME. The message includes UE voice capabilities and preferences.

The LTE attach request processor 89 and the session mobility management controller 87 access a Tracking area list 91. The eNodeBs forming the RAN are grouped by geographic location, each group known as a tracking area (TA). The tracking area list 91 is used by the LTE attach request processor 89 to store the initial tracking area of the UE when it joins the cellular network.

The tracking area list 91 is used by the Session and mobility management controller 87 to record which tracking area a UE is currently in and if it changes at a boundary between tracking areas, the identity of the new associated tracking area.

The LTE attach request processor 89 and the session and mobility management controller 87 also determine a suitable SGW 37 for the UE 9 to use and communicate with SGWs 37 on the cellular network via the SGW interface 85.

The LTE attach processor 89 and the other components function in a conventional way to process UE requests to join the cellular network.

In the first embodiment, the LTE attach processor 89 contains additional processing to deal with the VoWiFi to VoWiFi roaming behavior of the UE.

In particular, the LTE attach processor 89 is configured to determine when an incoming LTE Attach request is a provisional attach request in accordance with the above described operation of the UE in the first embodiment and to carry out a provisional process until a full handover is required.

Flowchart of the Operation of the MME

FIG. 7 shows the processing of an MME in the first embodiment for VoLTE registration when a handover preparation field is present in the Attach message received from the VoWiFi/VoLTE controller 73 of the UE.

In s31, the MME authenticates the UE with data retrieved from an authentication, authorisation and accounting (AAA) server (not shown) and Home Subscriber Server (HSS) 33 to verify whether the UE is an authorized UE for the cellular network.

Assuming the UE 9 is authenticated, in s33, the MME 31 sends an Update Location message to the HSS 33 to record the new location of the UE 9.

In embodiments s31 and s33 are conventional aspects of an LTE attach request process, however in the first embodiment, the behavior of the MME 31 is modified so that in s35 the attach request is analyzed to determine the presence of the handover preparation field indicating that a provisional VoLTE handover is required because the UE is attempting a VoWiFi to VoWiFi roaming operation and not a more conventional VoLTE to VoLTE or VoWiFi to VoLTE handover.

In s31 and s33, UE authentication and location update can be regarded as a first subset of the processing operations carried out in a VoLTE registration.

If the attach request does not contain a positive indication of the handover preparation field, then processing moves to s41 where the remaining conventional steps of a handover process are performed with respect to the SGW, PGW and IMS and processing ends.

If the Attach request does contain the handover preparation field, then in s37 the MME 31 is configured to pause the conventional handover process before significant resources have been allocated to the apparent UE handover. In this way the MME 31 is prepared to accept a VoLTE handover but has not committed to serving that UE with the establishment of bearers and IMS registration, etc.

In s37 the MME 31 waits for a predetermined period of time set at a value which enables the UE 9 to determine whether the VoWiFi handover was successful.

After the expiry of the predetermined time period, in s39 the MME 31 checks whether a handover completion message has been received. If such a message has been received, the VoWiFi roaming process was not successful and therefore the pre-emptive VoLTE link needs to be completed. In s41 the MME carries out a second subset of operations required for a VoLTE registration, to establish a VoLTE link between the UE and the IMS. In this embodiment the second subset includes:

validating the mobile device capabilities and Quality of Service (QoS) parameters;

selecting a serving gateway (SGW) and packet data gateway (PGW) and establishing a default bearer for the mobile device;

making modifications to the bearer as required; and

performing an IMS registration.

After the LTE and VoLTE registration tasks have been performed, processing ends.

In contrast, if in s39 a message has not been received after the time period in s35, then it is assumed that the VoLTE link is not required because the VoWiFi roaming operation was successful. In this case any resources allocated to the UE are freed and processing ends.

In the first embodiment, components of the UE and the MME interact to provide a pre-emptive solution to prevent service interruption following a failed VoWiFi roaming operation. In the event that the VoWiFi handover is successful the pre-emptive processing at the MME 31 can be reverted without wasting significant resources. However, in the event of a VoWiFi handover failure, the VoLTE backup link can be restored more quickly than a conventional process due to the time saving of the pre-emptive authentication and tracking area update.

Alternatives and Modifications

In the embodiment, the handover preparation field is part of the LTE attach message sent from the UE. In an alternative, the handover preparation field is included in the IMS attach or as a separate dedicated message.

In the embodiment, when a provisional VoLTE link has been requested and provisional link manager has determined that the VoWiFi roam has not been established in time, the provisional link manager 75 disables access to the VoWiFi network port before requesting completion of the VoLTE link. This is to prevent a late VoWiFi completion interfering with the VoLTE handover, while still allowing other applications to use the WLAN for data services.

In an alternative, the port operations at s9, s17 and s19 are not performed by the provisional link manager 75 which may be result in the UE being connected to both VoLTE and VoWiFi before the voice application chooses one of the two data links.

In a further alternative, to simplify the network interfaces, the provisional link manager is configured to cause the WiFi interface to be disabled when a VoLTE link is required. This causes the UE to use the cellular network for both voice and data services.

In the embodiment, the system is described in terms of an LTE network which supports a packet based voice service. Other packet network based voice services could be used.

In the embodiment, the MME performs a pre-emptive/provisional VoLTE handover in response to an indication from the VoWiFi/VoLTE handover manager that a provisional link is required during a VoWiFi to VoWiFi roam. Once the UE has carried out an RRC connection request with a base station, the MME performs a Location Update with the HSS and receives a location update answer from the HSS. Once this step is complete, the provisional VoLTE handover is paused. The number of steps carried out at the MME in the first subset are kept to a minimum to save resources.

In an alternative, the first subset contains processing operations from the second sub-set such as determining UE capabilities. The operations in the first and second subsets can be altered in dependence of the processing capabilities of the MME and can also vary in accordance with processing load at different times of the day and/or in accordance with historic data relating to how often a full VoLTE handover is required after a provisional request.

Insofar as embodiments of the disclosure described are implementable, at least in part, using a software-controlled programmable processing device, such as a microprocessor, digital signal processor or other processing device, data processing apparatus or system, it will be appreciated that a computer program for configuring a programmable device, apparatus or system to implement the foregoing described methods is envisaged as an aspect of the present disclosure. The computer program may be embodied as source code or undergo compilation for implementation on a processing device, apparatus or system or may be embodied as object code, for example.

Suitably, the computer program is stored on a carrier medium in machine or device readable form, for example in solid-state memory, magnetic memory such as disk or tape, optically or magneto-optically readable memory such as compact disk or digital versatile disk etc., and the processing device utilizes the program or a part thereof to configure it for operation. The computer program may be supplied from a remote source embodied in a communications medium such as an electronic signal, radio frequency carrier wave or optical carrier wave. Such carrier media are also envisaged as aspects of the present disclosure.

It will be understood by those skilled in the art that, although the present disclosure has been described in relation to the above described example embodiments, the disclosure is not limited thereto and that there are many possible variations and modifications which fall within the scope of the claims.

The scope of the present disclosure includes any novel features or combination of features disclosed herein. The applicant hereby gives notice that new claims may be formulated to such features or combination of features during prosecution of this application or of any such further applications derived therefrom. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the claims.

Claims

The invention claimed is:

1. A method of operating a mobility management entity in a cellular network core in response to a connection request from a cellular client device for connectivity to a voice service accessible via the cellular network core, the method comprising:

receiving a request by the cellular client device to access the voice service;

analyzing the request to identify a presence of an identifier indicating that the request is a provisional request;

if the request contains the identifier, performing a first subset of operations from a set of operations to establish a link between the cellular client device and the voice service;

determining whether a further instruction to complete the link between the cellular client device and the voice service has been received within a predetermined period of time; and

if the further instruction has been received, processing a second subset of operations to complete the link between the cellular client device and the voice service.

2. The method according to claim 1, wherein the first subset of operations comprise authenticating the cellular client device and updating a location of the cellular client device location.

3. The method according to claim 1, wherein the second subset of operations comprises establishing a data bearer between the cellular client device and a packet data gateway and establishing a voice session with the voice service.

4. The method according to claim 1, wherein if the further instruction is not received within a predetermined time, determining that a cellular client device does not require access to the voice service and performing a de-allocation operation to recover allocated resources.

5. The method according to claim 1, wherein the voice service resides at an Internet Multimedia Sub-System accessible via the cellular network.

6. The method according to claim 1, wherein the cellular network operates in accordance with a Long Term Evolution cellular network protocol and the method is performed by a mobility management entity.

7. An apparatus in a cellular network core for managing a connection request from a cellular client device for connectivity to a voice service accessible via the cellular network core, comprising:

a receiver configured to receive a request by the cellular client device to access the voice service; and

a processor configured to:

analyze the request to identify a presence of an identifier indicating that the request is a provisional request;

perform a first subset of operations from a set of operations to establish a link between the cellular client device and the voice service, if the request contains the identifier;

determine whether a further instruction to complete the link between the cellular client device and the voice service has been received within a predetermined period of time; and

process a second subset of operations to complete the link between the cellular client device and the voice service if the further instruction has been received.

8. The apparatus according to claim 7, wherein the first subset of operations comprise authenticating the cellular client device and updating a location of the mobile device.

9. The apparatus according to claim 7, wherein the second subset of operations comprise establishing a data bearer between the cellular client device and a packet data gateway and establishing a voice session with the voice service.

10. The apparatus according to claim 7, wherein if the further instruction is not received within a predetermined time, the processor is further configured to determine that a cellular client device does not require access to the voice service and perform a de-allocation operation to recover allocated resources.

11. The apparatus according to claim 7, wherein the voice service resides at an Internet Multimedia Sub-System accessible via the cellular network.

12. The apparatus according to claim 7, wherein the cellular network operates in accordance with a Long Term Evolution cellular network protocol and the apparatus is a mobility management entity.

13. A non-transitory computer-readable storage element storing processor executable instructions which, when executed by a programmable processor, cause a mobile device to operate a mobility management entity in a cellular network core in response to a connection request from a cellular client device for connectivity to a voice service accessible via the cellular network core, by:

receiving a request by the cellular client device to access the voice service;