IMS registration management

In a LTE network user devices can access voice application service via Voice over LTE (VoLTE) and Voice over WiFi (VoWiFi). To detect faults in the data link associated with an evolved packet data gateway for providing access by the user device to the LTE network from a non-trusted network which will affect VoWiFi capability, a packet data gateway monitors the status of ePDG and if a fault is detected, the user device is notified that it should connect to voice services via VoLTE.

This application is the U.S. national phase of International Application No. PCT/EP2019/050800 filed Jan. 14, 2019 which designated the U.S. and claims priority to EP Patent Application No. 18152337.4 filed Jan. 18, 2018, the entire contents of each of which are hereby incorporated by reference.

FIELD OF INVENTION

The present invention relates to managing wireless communication services and in particular to a method and apparatus for controlling client device usage of voice service data paths.

BACKGROUND

Cellular data networks provide data connectivity to mobile devices having cellular network interfaces. The network is formed of a network core for handling control plane functions and data packet routing, and a radio access network (RAN) of—typically—macrocell base stations located throughout the coverage area of the mobile network for wireless communication with subscriber mobile devices. An example of a cellular network architecture is Long Term Evolution (LTE). Unlike previous generation second generation (2G) and third generation (3G) cellular networks which offer packet-switched data services over a circuit-switched voice platform, LTE is an all-packet-switched data network architecture that does not support the traditional voice calling platform.

Wireless Local Area Networks (WLANs) operating in accordance with the IEEE 802.11 family of standards (commonly referred to as Wi-Fi™) are common in many user locations and provide data connectivity over a short geographic range. Typically, the wireless local area network is generated and maintained by a wireless Access Point (AP) which acts as a packet routing interface between devices connected to the WLAN (e.g. smartphones, tablets) and local devices connected via a wired Local Area Network (LAN) such as televisions and network attached storage. The wireless access point serves local devices and will typically be co-located, or integrated with an external network interface such as a modem for providing a backhaul link to external networks such as the Internet via an Internet Service Provider's (ISP's) core network. Example backhaul technologies include Digital Subscriber Line (xDSL) copper/fibre and cable based on the Data over Cable Service Interface Specifications (DOCSIS) architecture.

Such a combined AP, routing and modem device will be referred to as a hub throughout the description.

With the change of architecture, there is a need for an alternative way of providing voice communication services. Earlier methods involve Circuit-Switched Fallback (CSFB) to a legacy circuit-switched voice network. To avoid the need for CSFB or a Voice-over-Internet Protocol (VoIP) service, an Internet Multimedia Subsystem (IMS) is connected to the LTE network and hosts a number of applications for use by subscribers of the LTE network, one of which is a telephony application called the MMTel.

When a user of a mobile telephone is connected to the LTE network and makes or receives a voice call, their connection to the MMTel is known as Voice-over-LTE (VoLTE). VoLTE is an example of a Voice-over-Internet Protocol (VoIP) application for allowing voice communication via a LTE cellular network. The voice data is sampled into packets of voice data and the packets are sent over the data network. To prioritise the transmission of voice packets over other types of packet data carried by the LTE network, VoLTE uses optimised headers and priority markings.

Although the packets may arrive in a different order to the transmission order, packet loss is tolerated because latency has a greater negative effect on the quality of experience to the users.

Voice-over-Wi-Fi (VoWiFi) or ‘Wi-Fi Calling’ provides access to the same MMTel voice service as VoLTE, but the voice data link is initially carried from the mobile handset of the user via a WLAN instead of the cellular radio access network of base stations. In VoWiFi, since the IMS is typically only accessible via LTE network and not the public Internet, User Equipment (UE) must access a specific Internet-facing gateway of the LTE network so that voice calls can be made and received using the standard telephony software and packet data is tunneled to and from the cellular network core. VoWiFi therefore extends the cellular network voice service coverage, particularly to indoor locations. VoWiFi also allows for handover to a normal VoLTE service when the mobile device moves to an outdoor location which is outside of the range of the WLAN.

Mobile devices such as smartphones will therefore have both a cellular network interface and a WLAN interface for data connectivity. Traditionally, WLANs offer cheaper, and occasionally faster and more reliable service, especially in indoor locations, so the mobile device can be configured to prefer the WLAN interface for all data connectivity when both WLAN and cellular access are available.

With the conventional processing, the mobile device is only concerned with the quality of the WLAN signal to the hub. As long as the WLAN signal strength is above a signal strength threshold, the mobile device will stay connected to the WLAN even if there is no onward connection to the external networks such as the Internet. This can cause confusion for users because the phone displays a strong WLAN connection (typically via an icon with various bars to indicate signal strength) but the data services cannot connect and incoming calls may be lost.

The present invention seeks, at least, to alleviate the problems identified above.

STATEMENTS OF INVENTION

In one aspect, an embodiment of the present invention provides a method of operating a packet data gateway in a cellular network located in a data path between a user device and a voice service associated with the cellular network, the user device having a cellular network interface and a wireless local area network interface and connected to the voice service via a wireless local area network data path including a wireless local area network and a non-cellular network gateway of the cellular network, the user device being further operable to access the voice service via cellular network path including a cellular radio access network of base stations, the method comprising: receiving a notification that a fault associated with the non-cellular network gateway has occurred; notifying (optionally, instructing) the user device to access the voice service via the cellular network path; and transferring voice registration and voice data packets between the user device and the voice service via the cellular network path.

In a further aspect, an embodiment of the present invention provides a packet data gateway for use in a cellular network located in a data path between a user device and a voice service associated with the cellular network, the user device having a cellular network interface and a wireless local area network interface and connected to the voice service via a wireless local area network data path including a wireless local area network and a non-cellular network gateway of the cellular network, the user device being further operable to access the voice service via cellular network path including a cellular radio access network of base stations, comprising: a receiver for receiving a notification that a fault associated with the non-cellular network gateway has occurred; a transmitter for notifying (optionally, for instructing) the user device to access the voice service via the cellular network path; and wherein the transmitter and receiver are configured to transfer voice registration and voice data packets between the user device and the voice service via the cellular network path.

The invention extends to any novel aspects or features described and/or illustrated herein. The invention extends to methods and/or apparatus substantially as herein described and/or as illustrated with reference to the accompanying drawings. The invention also provides a computer program and a computer program product for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

According to another aspect of the invention, there is provided a computer program containing processor-executable instructions for causing a processor to carry out as method as described above.

The invention also provides a signal embodying a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa. Furthermore, any, some and/or all features in one aspect can be applied to any, some and/or all features in any other aspect, in any appropriate combination. It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.

In this specification the word ‘or’ can be interpreted in the exclusive or inclusive sense unless stated otherwise.

Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

The invention extends to a method of operating a packet data gateway and to a packet data gateway as described herein and/or substantially as illustrated with reference to the accompanying drawings.

SPECIFIC DESCRIPTION

First Embodiment—ePDG Detects Certain Types of Fault with its Internet Link

System Overview

FIG.1shows an overview of the main components in a communications system1according to a first embodiment. The system1has several functional subsystems:a Long Term Evolution (LTE) cellular network3infrastructure;non-cellular network infrastructure5; andan IP Multimedia Subsystem (IMS)7.

The LTE cellular network3provides cellular network client devices, known as User Entities (UE)9such as mobile telephones, with data and voice services using a packet-switched IP network. The LTE cellular network3includes a network core, known as an Evolved Packet Core (EPC)11, and a radio access network (E-UTRAN) formed of eNodeBs13for connecting services and resources in the EPC11to the UEs9. The EPC11contains the standard control functions of a LTE network3core such as a Multimedia Mobility Entity (MME)27, a Home Subscriber Server (HSS)29, and a Policy Configuration Rules Function (PCRF)35. A number of Serving Gateways (SGW)31manage UE access to the EPC via the eNodeBs and a number of Packet Gateways (PGW)33are provided for linking the EPC11to external networks such as the Internet and the IMS5. The EPC11also includes an evolved packet data gateway (ePDG)25so that devices can access the EPC11via non-trusted access networks.

The non-cellular network infrastructure5includes a wireless access point/modem router device17, hereinafter referred to as a hub, located in the home generating a wireless local area network (WLAN)19in accordance with the IEEE 802.11 family of standards to allow communication with UEs9and also WLAN-only devices10such as a computer. For external network access, the hub17communicates with an Internet Service Provider (ISP)21which routes data via a wide area network such as the Internet23to external servers and users. In this embodiment, the UE9can connect to the ePDG25so that voice communication can be performed via the standard telephone application used by the UE, to avoid the need for a separate application as in the case of VoIP.

The LTE network3and non-cellular infrastructure5can be regarded as transport networks concerned with moving data packets between the UEs11and applications. Meanwhile, the IMS7is a Session Information Protocol (SIP) based application and services 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 IMS7therefore reduces the need for duplication in data services/applications.

The IMS7contains a number of Session Information Protocol (SIP) servers collectively known as the Call Session Control Function (CSCF)37. The CSCF37include a Proxy CSCF (P-CSCF)39which acts as a gateway into the IMS7, an Interrogating CSCF (I-CSCF)41which is responsible for assigning Serving CSCF (S-CSCF)43servers to a particular device. Each S-CSCF43handles SIP registrations between devices and application servers15.

The CSCF37links the LTE network3and non-cellular infrastructure5to Application servers15. The voice services used in VoLTE and VoWiFi are hosted in an application server15within the IMS7known as the Multimedia Telephony Service (MMTel)16, hereinafter referred to as the MMTel service.

The function of the VoLTE and VoWiFi voice services are defined in IMS profiles. The IMS profile for VoLTE is defined in 3GPP IR.91 and the IMS profile for VoWiFi is defined in 3GPP IR.51, both of which are incorporated by reference.

VoLTE and VoWiFi Data Plane

FIG.2shows the connections between network components of the LTE network3, non-cellular infrastructure5and IMS5in the VoLTE and VoWiFi data planes that must be established for a UE9to carry out voice communication.

LTE and VoLTE Registration

The LTE network3provides a control plane and data plane so that control data and user data are transported separately across the EPC11. The control plane is responsible for user authentication, gateway selection and device mobility/handover. The data plane is established in accordance with the control plane decisions and is responsible for transporting data packets across the EPC11.

When a UE9is first switched on, the UE9will attempt to register onto the LTE network3by performing a network attach procedure. Firstly the UE9performs a cellular scan for an eNodeB13of the subscribed LTE network3. When a suitable eNodeB13is detected, the UE9connects to the eNodeB13to establish a cellular radio link. The eNodeB13forms part of the radio access network of the LTE network3and so it is responsible for directing traffic into the EPC11to establish the control plane and subsequently the data plane.

The eNodeB13is linked to the MME27which is the main control plane component of the EPC11. The MME27authenticates the UE9onto the LTE network3by conducting a challenge/response protocol based on credentials derived from a SIM (not shown) located in the UE9and details stored in the HSS29.

Once the UE9has successfully authenticated, the MME27establishes the data plane to be used by the UE9for data sessions with external network resources. The Serving Gateway (SGW)31is responsible for carrying data plane packets from the UE9into the EPC11, therefore the MME27allocates one of the SGWs31in the EPC11for use by the UE9based on the location of the connected eNodeB13.

Once allocated, the SGW31will identify an associated PGW33which provides onward connection to external networks such as the Internet23and the IMS7.

The PGW33is also responsible for allocating an IP address for the UE9and establishing an initial data plane communication session, known as a default bearer. The PGW33is a gateway between the UE9located on the LTE network3and external resources. The PGW33therefore updates internal routing tables so that data packets received from external resources and addressed to the IP address of the UE9are routed to the corresponding default bearer for the UE9across the EPC11.

Once the UE9has basic connectivity via the LTE network3, the UE9initiates a VoLTE registration with the IMS7which is an external network.

A telephony application in the UE initiates a SIP handshake routine with the CSCF37(involving the P-CSCF39/I-CSCF41/S-CSCF43) of the IMS7to establish a data session from the UE9to the MMTel16service. The handshake routing includes authenticating the UE9using authentication data stored in an IMS HSS (not shown) or the same HSS29of the EPC11. Once the UE9is authenticated, the CSCF37will create a secure data tunnel51(shown inFIG.3), via the EPC11and eNodeB13of the LTE network3, to the UE9. Details of the data link including the secure data tunnel51will be provided to the PCRF35which translates the requirements into 3GPP standard tasks to be implemented by the EPC11.

Furthermore, since voice has high quality of service (QoS) requirements, the PGW33will establish a new IMS default bearer to the UE9with a higher transmission priority known as a QoS Class Indicator (QCI) level, for example a QCI level of five whereas the overall default bearer has a QCI level of 9. Control packets received from the IMS7are routed through the IMS default bearer instead of the default bearer. Furthermore, when a user of the UE9initiates a VoLTE call or receives a call, an IMS dedicated bearer is established, with much tighter requirements for packet delivery in terms of throughput and latency. In the case of VoLTE, the dedicated bearer may be established with a QCI of 1 indicating that these packets have the highest delivery priority.

After the above sequence of processing, the UE9is wirelessly connected to an eNodeB13of the LTE network3, has been allocated an IP address by the PGW33and also established an IMS default bearer to the MMTel16service.

As shown, the data plane path between the UE and MMTel for VoLTE is:UE→eNodeB→Serving Gateway (SGW)→Packet Gateway (PGW)→CSCF→MMTel service

FIG.3shows a simplified view of the data connection, including the data tunnel51connection between the P-CSCF of the CSCF37and the UE via the EPC.

Returning toFIG.2, the VoWiFi data plane will now be described.

When the UE9is in the range of a WLAN19generated by a wireless access point/router/modem device17, hereinafter referred to as a hub, the UE9will attempt to authenticate and associate onto the WLAN19for data connectivity with external resources. As shown inFIG.1, the hub17is connected to an ISP21via a broadband link based on, for example the Very High Digital Subscriber Line (VDSL) protocol or a cable protocol such as the Data Over Cable Service Interface Specification (DOCSIS). The ISP21then connects the UE9to a wide area network such as the Internet23. The UE9will be assigned a private network IP address and the hub17(which has a public network IP address for the entire local network) carries out network address translation (NAT) to allow a number of devices connected to the WLAN19to share the public IP address.

VoWiFi allows voice and messaging data, normally carried by the eNodeB13radio access network of the LTE network3, to be carried over the WLAN19and broadband link into the EPC11. This is known as Wi-Fi Offload and reduces the processing load on the radio access network of eNodeBs13and can reduce a user's LTE network data charges.

WiFi Offload is enabled by the provision in the EPC11of an Evolved Packet Data Gateway (ePDG)25to provide an entry point into the EPC11via external networks other than the RAN of eNodeBs. In LTE, these non-cellular data networks are defined as non-trusted 3GPP IP systems since they do not necessarily belong to the LTE network operator and therefore data security through the external network cannot be guaranteed.

Unlike the other network components of the EPC11, the ePDG25has a public IP address so that other network devices can discover and establish communication sessions with the ePDG25. However, to secure the communication sessions over the non-trusted 3GPP networks, the ePDG25is configured to establish secure data tunnels61(shown inFIG.4) to the UE9so that intermediary devices in the data link such as the hub17, ISP21and Internet23routing nodes cannot read the contents of the packets. The IP Security (IPSec) protocol is used so that any data packets are encrypted as the travel through the tunnel61to the UE9.

Furthermore, the UE9must provide credentials to prove that it is a valid subscriber of the cellular network before the ePDG25will allow the UE9to use EPC11resources. Since the UEs9in this embodiment can also access the LTE network3, a variant of the Extensible Authentication Protocol (EAP) authentication framework is used such as EAP-AKA where UE9will authenticate based on credentials stored on a Subscriber Identity Module (SIM) (not shown) located in the UE9.

Once authenticated, the ePDG25updates the control plane by notifying the MME27that a UE9that was previously connected to an eNodeB13is now located on a WLAN19. The data plane is then established by creating a default bearer with the PGW33, wherein the PGW33also provides the IP address previously allocated to the UE9to the UE9at the new connection via the ePDG25. In this way, the UE9can still be addressed and located even after a handover to a different access network for voice and messaging services.

Unlike the LTE data plane, the UE9may only use the LTE network3for access to the IMS7and MMTel16service since the UE9can access other remote resources such as email and Internet browsing via the ISP21directly without incurring the overhead of the ePDG25security and tunnelling.

The UE9therefore requests VoWiFi registration which involves establishing an IMS default bearer with a P-CSCF39and SIP session with the MMTel16service wherein a second tunnel63is established between the CSCF37and UE9. From the PGW33to the MMTel16service, the data path is the same as the LTE data plane.

The data path for VoWiFi is therefore:UE→AP→Internet→ePDG→PGW→CSCF→MMTel service.

FIG.4shows a simplified view of the UE VoWiFi data connection, including the data tunnel connection61between the P-CSCF and the UE via the EPC travels via the second data tunnel63between the ePDG and the UE.

WLAN Preference

As described above, the UE9has both WLAN and LTE interfaces and is capable of both VoLTE and VoWiFi call handling. Since an eNodeB13of the LTE network has a larger geographical coverage range than a WLAN19, in general the UE will be connected to the LTE network3and will use VoLTE.

However, when the UE is within range of a WLAN19, there is overlap in the connectivity ranges, and the UE9can connect to data services using either the cellular interface or the WLAN interface. In general, the default UE connection policy is that a WLAN connection is preferred. So when a UE9is connected to the LTE network3for voice and data connectivity and it detects a known WLAN19, the UE9will try to connect to the WLAN19.

Once connected to the WLAN19, the VoWiFi data plane shown inFIG.2andFIG.4will be established so that calls can be made and received over VoWiFi.

After a VoWiFi connection has been established between the UE19and MMTel16service, the standard behaviour is for the UE9to maintain the WLAN19connection until the UE's9location changes such that it is no longer within range of the WLAN19. When the WLAN interface of the UE detects the dropped WLAN19connection, the UE9will activate the LTE interface and once the UE has registered onto the LTE network3via an eNodeB13, VoLTE service will be established so that the UE9can continue to make and receive calls.

However, the conventional UE9behaviour is to only consider the WLAN quality strength and not the overall link to the remote resource. As long as the UE9is connected to a WLAN19with sufficient signal strength, if the onward connection to the ePDG25develops a fault, the UE9will not trigger a switch to LTE and VoLTE to maintain the voice service connection.

In some cases a UE9will have a timer to send a heartbeat signal to the ePDG tunnel61end point, but to save battery, the timer interval is set at a high value of several minutes so it is not able to respond to service loss in a rapid manner. Similarly the UE9dialler application will periodically send a heartbeat or re-registration message via the second data tunnel63to the CSCF37of the IMS7, but the timer is configured to be a high value. During a time period when there is a fault in the VoWiFi link but the UE9is not aware, the MMTel16service will not be able to route calls to the UE9.

In a case where the user of the UE9tries to place a VoWiFi call but is unable to, then the UE9will typically recognise that there is a fault with the VoWiFi link and initiate a VoLTE registration via the LTE network3. Alternatively, the user may manually disable the WLAN interface so that the UE9connects to the LTE network3and carries out a VoLTE registration. However, such a manual intervention negatively impacts the user experience since the first instance of making a call fails.

In this embodiment, the ePDG25and PGW33are configured to monitor for disruptions in connectivity affecting the ePDG link to the Internet23or a fault at the ePDG25which have an impact on the availability of the VoWiFi service to UEs9.

FIG.5is a flowchart showing the overall operation in the first embodiment for a network based VoWiFi fault detection and VoLTE handover process.

In step s1the UE9attaches to the LTE network3via the eNodeB13and has a default bearer from the UE9to the PGW33and in the presence of a WLAN19, in step s3the UE9registers for VoWiFi instead of VoLTE in accordance with the usual preference for WLANs.

During the time that VoWiFi is active, in step s5the ePDG25monitors for link faults to the UE9which may affect the ability to provide VoWiFi even though the local WLAN19link used by the UE9is functional. Such link faults may be caused by connectivity problems between the hub17and the ISP21, the ISP21to the Internet23, Internet23links towards the ePDG25, or a combination all the above factors. If a fault is detected, then in step s7, the ePDG25notifies the PGW33.

In the step s9, the fault message is received by the PGW33and processing is also performed by the PGW33in step s11to determine whether a fault has occurred at the ePDG25itself. Once an ePDG25related fault has been identified, then in step s13the MMTel16is notified so that the MMTel16service is aware of the service disruption so that incoming voice calls can be held. The notification to the MMTel16service is delivered via the PCRF35, the P-CSCF39and S-CSCF43.

In step s15the PGW33uses the default bearer to the eNodeB13to identify the logical location of the UE9and to inform the UE9the requirement for a VoLTE switch.

In step17, the UE9initiates registration for a new IMS VoLTE session and in step s19a VoLTE session is established.

FIG.2also shows an ePDG link status monitor45associated with the ePDG25and an ePDG service loss function47associated with the PGW33.

The ePDG link status monitor45is responsible for detecting faults affecting the data link to the ePDG25via the Internet23which would affect the ability of UEs to access the EPC11and IMS7resources.

The ePDG service loss function47receives fault notifications from the ePDG link status monitor45and also monitors the availability of the ePDG25within the EPC11. Following receipt of this message, the PGW33informs the MMTel16service of the service loss by sending a control plane message via the PCRF35and the CSCF37.

Once notified via the PCRF35, the MMTel16marks the VoWiFi link as inactive. With the above processing, any incoming calls placed during the outage will be successfully diverted to voicemail, but calls cannot be routed to the UE9and equally calls cannot be made by the UE. This is because the UE still believes it is connected to VoWiFi on the basis that the WLAN19is still active.

To cause the UE to override the standard behaviour of preferring WLAN19connections and connect to VoLTE even when the WLAN19is available, the PGW33must inform the UE9that there is a fault with the VoWiFi link.

Since the PGW33allocated the IP address to the UE9when the UE9registered to the LTE network3, the PGW33maintains a default bearer to the UE9over LTE while the UE9is idle on the LTE network3. The PGW33uses this default bearer to notify the UE9to register for VoLTE.

In response, the UE9will enable its LTE interface to register for VoLTE as described above. In the current network architecture, a limitation exists that VoLTE and VoWiFi IMS registrations must always be initiated by the UE9rather than the network3.

Following the operation of the above functions, a fault associated with the ePDG25and VoWiFi service can be detected and the UE9can be notified to switch to VoLTE to maintain voice connectivity.

ePDG Link Status Monitor

FIG.6shows the components of the ePDG link status monitor45in more detail.

The ePDG link status monitor contains a connected client list71, link loss detector73and a PGW notifier75.

The connected client list71stores details of any UEs9which are currently connected to the ePDG25via an IPSec tunnel and therefore registered for VoWiFi.

The link loss detector73is configured to monitor the status of the connection of the ePDG25to the UEs on the connected client list71in order to detect service loss. The loss may only affect a single UE9, a subset of UEs9or all UEs9using VoLTE depending on the source of a fault. For example, a fault at a single hub17may only affect a single UE9, while a fault at the ISP21may affect tens or hundreds of UEs9.

To monitor the connectivity status of a link to a UE9, the link loss detector73performs two tests concurrently:

1) Send periodic heartbeat signals via the tunnel61to the UE9. If the message is not acknowledged, then the connection is deemed to be faulty. In this embodiment this is every 30 seconds

2) Set a timer on the IPSec tunnel61and if a predetermined amount of time has elapsed without any data traffic being received from the tunnel61, infer a faulty UE connection. In this embodiment, the countdown period is every 20 seconds.

The heartbeat and countdown tests are equally valid in determining that a fault has occurred on some part of the data path between the UE9and the ePDG25, and may therefore be implemented independently or in combination.

If either of the monitored test indicates that a fault is present, then the PGW notifier75sends a control message to the ePDG service loss function47.

FIG.7shows the components of the ePDG service loss function47associated with the PGW33. This function47contains an ePDG link status monitor interface81, an ePDG activity checker83, an ePDG status determination function85, an IMS notifier87and a UE notifier89.

The ePDG link status monitor interface81is linked to ePDG link status monitor45so that any fault messages from the PGW notifier75can be received and processed. These messages can be received while the ePDG25is active. To detect the case where the ePDG25itself develops a fault or the communication link between the ePDG25and the PGW33develops a fault, the ePDG activity checker83is configured to periodically send a heartbeat message to the ePDG.

The ePDG status determination function85receives inputs from both the ePDG link status monitor interface81and the ePDG activity checker83. If a fault message is received from either input, the ePDG status determination function85triggers the IMS notifier87to communicate with the IMS7and the UE notifier89to communicate with the UE so that it can register for VoLTE.

With the above processing and interaction between the network components, a UE9can be directed to switch from VoWifi to VoLTE when the network determines that an ePDG25has developed a fault.

Reverting to VoWiFi

The above described processing by the ePDG25and PGW33enables the LTE network3to help the UE9switch over to a VoLTE connection more quickly, in the event of a network failure between the UE9and the ePDG25via an untrusted network or a failure of the PGW33, to minimise service loss to the MMTel16voice service.

Due to data costs to the subscriber of the UE9and infrastructure costs on the LTE network3, it is desirable to re-enable WiFi Offload where possible.

To enable the UE9to make greater use of the available WLANs19, in this embodiment the ePDG25is configured to continue testing the status of the ePDG25to UE9link and if the link between the ePDG25and UE9is restored, the ePDG25will send a Link restored message to the PGW33for onward delivery to the MMTel16service using VoWiFi.

When the PGW33receives a link restored message, it will identify any UEs9which were previously instructed to switch to VoLTE when the ePDG link fault was detected and notify those UEs9using the previous WLAN related default bearer.

When the UE9receives a message from the PGW33, the UE9will decide whether to switch to VoWiFi via the WiFi link or remain on VoLTE based on a device policy. If required, the UE9will initiate a VoWiFi registration.

Alternatives and Modifications

In the embodiment, the PGW33notifies the UE9of a need to switch from VoWiFi to VoLTE using the default LTE bearer. In an alternative, the PGW33creates a new dedicated bearer to communicate with the UE9.

In the embodiment, the PGW33notification is carried out as a link failure is detected on a UE9by UE9basis. This can lead to a lot of internal control messages between the ePDG25and a PGW33.

In an alternative, the ePDG25is configured to log all disconnected UEs9occurring within a set time period, for example every 2 minutes, before notifying the PGW33with a set of UEs9. Such a method will save internal processing, but will increase the time required to respond to a line disconnection which may lead to a slower response time.

In the embodiment, the UE9is instructed to switch to using VoLTE when the VoWiFi connection via the ePDG25is deemed to be non-operational. Therefore the UE9voice service is switched to VoLTE while other data services continue using the WLAN19due to the cost benefits and often higher bandwidth available through WLANs.

In an alternative, the UE9is configured to switch all of the data bearers to LTE when there is a service disruption. Therefore the UE9will not use the WLAN at all but will instead switch all data connections to the LTE network3.