Field of Invention

The present invention relates to wireless data networks and in particular to a method for managing voice service access. Background

Cellular networks

Cellular data networks provide data connectivity to mobile devices such as mobile phones and smartphones 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 macrocell base stations located throughout the coverage area of the mobile network for wireless communication with subscriber user entities (UEs) such as mobile phone and smartphone devices. An example of a cellular network architecture is Long Term Evolution (LTE). Unlike older second generation (2G) and third generation (3G) cellular networks which offer packet switched data services on top of a circuit switched voice platform, LTE is an all-packet switched data network architecture that does not support a traditional voice calling platform.

Voice over LTE (VoLTE) is a packet switched voice service provided by a voice service (MMTel) hosted by application servers in an Internet Multimedia Service (IMS) associated with a cellular network. Voice data is carried between a UE and the voice service via an LTE network as a set of data packets with strict Quality of Service parameters relating to latency and delay. VoLTE aims to reduce the reliance on legacy cellular Circuit Switched Fall Back (CSFB) and Voice over IP services. This will reduce operating overheads and may allow parts of the legacy 2G and 3G platforms to be switched off.

WLAN

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

Such a combined wireless access point, routing and modem device will be referred to as a hub throughout the description. VoLTE/VoWiFi

Cellular signal strength varies according to distance from the transmitter but also due to the presence of obstructions and sources of interference. In buildings or other enclosed areas, the cellular signal can be attenuated such that data communication is not possible. These types of locations are sometimes referred to as coverage gaps. Due to the prevalence of WLANs in many indoor areas where cellular coverage may be locally weak, Wi-Fi offload is often used to transport UE packet data into the cellular network. Voice over Wi-Fi (VoWiFi) or Wi-Fi Calling service has also been deployed by several network operators as an extension of the Wi-Fi Offload concept to voice data. In VoWiFi, the voice dialler client in the UE links to the same MMTel voice service used in VoLTE and therefore VoWiFi can be regarded as an alternative data path between the UE and the voice service in the IMS. In particular, the WLAN used by the UE for VoWiFi is treated as a non-3GPP access network to the LTE network. Voice calls are made and received using the standard telephony client software and data packets carrying voice data are tunnelled to and from a publically accessible network gateway of the cellular network core known as an evolved packet data gateway (ePDG). VoWiFi extends the cellular network reach to indoor locations where the cellular signal is traditionally weaker and furthermore allows handover to a normal VoLTE or legacy voice services when the mobile device moves to an outdoor location.

VoLTE and VoWiFi are available to UEs such as smartphones having both a cellular network interface and a WLAN interface for data connectivity. In conventional systems the UE has an access network selection policy which can be configured on the device to either prioritise connecting to a WLAN network over a cellular network or vice-versa (i.e. to prefer cellular access over WLAN). Similarly, the UE can decide whether to connect to VoLTE or VoWiFi for voice services based on the availability of a WLAN and/or a cellular access network. If a WLAN is available and WLAN has been set as preferred access, the UE will attempt to connect to the VoWiFi service by establishing a secure communication tunnel to the ePDG of the subscriber cellular network. Once established, the mobile device will establish a session with the MMTel voice service in the IMS to implement VoWiFi. Cellular network operators see this behaviour as advantageous because it offloads traffic from the radio access network of their cellular network onto a non-3GPP network thereby freeing up network resources.

However, this simplistic access network selection behaviour in UEs can lead to bad quality calls or calls being missed due to the assumption by the UE is that the WLAN and VoWiFi link will always be more stable and higher performing than the cellular environment.

VoWiFi services can suffer from Quality of Experience (QoE) issues if the network selected is not suitable due to congestion amongst other issues. Conventional mechanisms to select the best access network for voice services are based mostly on device decisions based on static policies or basic dynamic information received from the network (e.g. Wi-Fi signal strength), but visibility is limited to the information available to the device and the mechanisms that have been implemented on each specific device type (i.e. dependent on device manufacturer implementation).

Embodiments of the present invention relate to these issues.

Statements of Invention In one aspect, an embodiment provides a method of operating a network gateway in a cellular network to control access of at least one mobile device to a voice service accessible via the cellular network, the mobile device being connected to the network gateway via a wireless access router and wide area network, WAN, the method comprising: receiving a request from the mobile device to access the voice service; measuring performance metrics for a non-cellular wireless network link to the mobile device; requesting observed network information from the mobile device; and comparing the quality of the non-cellular wireless network link to the mobile device against the respective quality of at least one observed network; if the quality of the non-cellular wireless network link is greater than the quality of an available observed network, allowing the request to proceed to the cellular network; and if the quality of at least one of the observed networks is higher than the current non-cellular wireless network link, rejecting the voice service request of the mobile device.

In another aspect, an embodiment provides an apparatus for controlling access of at least one mobile device to a voice service accessible via a cellular network the mobile device being connected to the network gateway via a wireless access router and wide area network, WAN, comprising: a wide area network interface; a secure data tunnel controller for receiving a request from the mobile device to access the voice service via the wide area network interface; means for measuring performance metrics for a non-cellular wireless network link to the mobile device; means for requesting observed network information from the mobile device; and means comparing the quality of the non-cellular wireless network link to the mobile device against the respective quality of at least one observed network; an access controller configured to: allow the request to proceed to the cellular network, if the quality of the non-cellular wireless network link is greater than the quality of an available observed network; and reject the voice service request of the mobile device, if the quality of at least one of the observed networks is higher than the non-cellular wireless network link.

Figures

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

Figure 1 schematically shows an overview of a telecommunications system according to a first embodiment;

Figure 2 schematically shows the functional components of a wireless routing device according to a first embodiment; Figure 3 is a flowchart showing the overall processing steps carried out by the wireless routing device and a user entity in the first embodiment;

Figure 4 is a flowchart showing the processing of step s5 of Figure 3 in more detail;

Figure 5 is a flowchart showing the processing of step sll of Figure 3 in more detail;

Figure 6 schematically shows the functional components of a UE illustrated in Figure 1 in the first embodiment;

Figure 7 is a flowchart showing the operation of the UE;

Figure 8 schematically shows an overview of a telecommunications system according to a second embodiment;

Figure 9 schematically shows the functional components of an ePDG illustrated in Figure 8; and Figure 10 is a flowchart showing the processing of an ePDG in the second embodiment. Description System overview Figure 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 devices, known as User Entities (UE) such as mobile telephones 9 with data and voice services using a packet-switched IP network in contrast to the older circuit switched networks. The LTE cellular network 3 includes a network core 11 and a radio access network formed of eNodeBs 13 for connecting services and resources in the network core 11 to the UEs 9. The network core 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 network core, 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 15 within the IMS 7 which in this embodiment is provided by a service known as the Multimedia Telephony Service (MMTel).

The non-cellular network infrastructure 5 includes a wireless access point/modem router device 17, hereinafter referred to as a hub, located in a user premises such as a user's home, generating 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 with UEs 9 and also WLAN only devices such as a computer 10. For external network access, the hub 17 communicates with an Internet Service Provider (ISP) 21 which routes data via a wide area network such as the Internet 23 to external servers and users.

Due to the ability of the LTE cellular network 3 to allow UEs 9 to access the network core 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 acts as a termination point for secure data tunnels, in this case using the IP Security (IPSec) protocol, with the UE 9 over non-trusted 3 ^rd Generation Partnership Project (3GPP) systems. This allows UE data to be routed into the EPC network core 11 for processing within the LTE cellular network 3 and IMS 7 network.

The UE 9 has both WLAN and LTE radio interfaces for accessing the non-cellular network infrastructure and the LTE cellular network respectively and the UE 9 supports VoLTE, VoWiFi and CSFB voice calls. To highlight the difference between UEs 9 and other connected WLAN devices 10, the computer 10 only has a WLAN interface and therefore can only access the WLAN 19 of the hub 17 but not the cellular network 3 since it does not have an interface capable of sending and receiving LTE signals.

Behaviour of UE for using the WLAN and LTE interfaces

As mentioned above, the UE 9 has both WLAN and LTE interfaces and is capable of both VoLTE and VoWiFi call handling. Since an eNodeB 13 of the LTE network has a larger geographical coverage range than a WLAN 19, in most areas the UE will be connected to the LTE network 3 and will use VoLTE.

However, when the UE is within range of a WLAN 19 such as shown in Figure 1, there is overlap in the connectivity ranges, and the UE 9 could 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 and it detects a known WLAN, the UE will try to use the WLAN for data services.

Therefore upon detection of a known WLAN, the UE 9 will enable its WLAN interface and disable its cellular interface causing any existing cellular services to also be disconnected. 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. However, the general UE policy of preferring WLANs to cellular data interfaces can have an impact on the Quality of Experience for users of voice services using VoWiFi instead of VoLTE.

In the first embodiment, the Wi-Fi access point performs a network selection decision on behalf of the UE based on any available information relating to the presence and connection quality of alternative networks available in order to steer the UE to a network which provides the best path to the voice service. In particular, even when VoWiFi is available via the Wi-Fi access point, the connection may be steered to VoLTE if the quality of the VoWiFi connection is deemed to be insufficient to provide voice access.

Hub

Figure 2 shows the internal components of the hub 17 in the first embodiment. The hub 17 contains a number of network interfaces for communication with various types of network device. For wireless local devices, there is a Wireless Local Area Network (WLAN) interface 31 for communication with wireless devices using a wireless protocol such as the IEEE 802.11 family of wireless LAN standards known as Wi-Fi. In this embodiment, the WLAN interface 31 is compliant with the 802.11ac Wi-Fi standard for WLAN operation. For wired LAN devices there is an Ethernet interface 33 in accordance with the IEEE 802.3 standards. For connectivity to the Internet Service Provider (ISP), the hub 17 has a Wide Area Network (WAN) interface 35 which in this embodiment is a modem compliant with the Digital Subscriber Line (xDSL) family of standards such as Very High Speed DSL (VDSL) modem.

The hub 17 also contains a central processor and memory (not shown). The memory contains computer program code which, when executed by the processor, define a number of software functional units which are described below.

The hub 17 contains a packet routing function 37 which is responsible for managing the flow of data packets between the three interfaces 31, 33, 35. The packet routing function 37 processes the headers of incoming packets received on the three interfaces 31, 33, 35 and determines where to send the packets for onward delivery to the intended packet destination. The packet routing function 37 will also include functions such as Network Address Translation (NAT) for directing packets between the local interfaces 31, 33 and the WAN interface 35.

The hub 17 contains a VoWiFi monitor function 39 which is responsible for determining whether a UE should be allowed to use a VoWiFi service provided by its cellular network provider. The VoWiFi monitor function 39 is configured to process requests for VoWiFi service from a UE 9 and either allow or deny the registration request in accordance with an assessment of the VoWiFi network requirements with regard to the presence of alternative networks.

In this way, the hub 17 acts as an admission controller to devices requesting VoWiFi and selectively allows access to VoWiFi in accordance with whether a VoWiFi session is the most suitable network.

The VoWiFi monitor function 39 has a VoWiFi request detection function 41, an admission control decision function 43, a policy database 45 and a network device status query function 47.

The VoWiFi request detection function 41 is linked to the WLAN controller 31 and also an ePDG public address store 51 and a connected client list 49. The VoWiFi request detection function 41 is configured to monitor the data travelling between the WLAN interface 31 and the WAN interface 35. In particular the function is looking for traffic directed to the ePDG 25 of the cellular network associated with the UE 9. The VoWiFi request detection function 41 processes flows of data packets traversing the hub to identify the subset of data packets which are addressed to the IP address of the ePDG for that UE's 9 cellular network.

Once a new request is detected, the admission control decision function 43 is notified and is operable to determine whether the request for VoWiFi should be allowed. The admission control decision function 43 first notifies a network device status query 47 with the address of the UE 9.

The network device status query function 47 carries out two processes, firstly it instructs the identified UE to scan for any available networks present via its Wi-Fi and cellular network interfaces. In addition to the list of available networks, performance metrics are also included in the UE's response. Once retrieved, the admission control decision function 43 processes the performance metrics in conjunction with threshold values pre-stored in a policy database 45 to determine the quality of each detected network. After processing, if the VoWiFi link is deemed to be the most suitable available network, the VoWiFi request is forwarded to the ePDG so that a VoWiFi session can be established in a conventional manner. However, if the performance of the VoWiFi path is lower than an alternative detected WLAN or cellular network, then the request is denied and the admission control decision function 43 will send a message to the UE notifying it of the identity of the most suitable network.

In response to the notification, the UE will initiate a connection to the recommended network.

Overall operation of the system Figure 3 shows a flowchart of the overall steps carried out by the various components in the first embodiment.

The process begins at the UE 9. In step si, as is conventional, when the mobile device's WLAN controller is enabled and detects the presence of a WLAN, the UE's existing access network selection mechanism will select Wi-Fi as the preferred radio access network (RAN) and initiate a connection to the WLAN.

In step s3, once the UE has associated and authenticated with the WLAN, the UE will initiate registration onto the VoWiFi service by sending a request to the ePDG in order to establish a secure data tunnel in accordance with the IP Security (IPSec) standard into the cellular network core 11.

In accordance with the first embodiment, the VoWiFi request detection function 41 of the wireless access point is configured to detect the initial message containing the IPSec request from the mobile device to the ePDG. In step s5, once a request has been detected, the wireless access point will delay forwarding the IPSec request to the destination ePDG until it has determined whether an alternative access would be suitable for VoWiFi services.

In step s7 the network device status query function 47 of the wireless access point communicates with a client on the mobile device. A request is sent asking for additional information from the mobile device, in particular to identify any other radio networks (cellular and/or non-cellular Wi-Fi) networks are visible to the mobile device.

In step s9, the UE scans for alternative networks (cellular networks and WLANs) and responds to the hub with any alternative network information including at least a network identifier and observed signal strength information. In step sll, the admission control decision function 43 of the hub evaluates the quality of the observed available networks. More details of this step will be provided below.

In step sl3, the quality of the VoWiFi link via the current WLAN and the quality of the best alternative network are compared.

If the quality score of the VoWiFi link is higher or the same as the cellular network score, then in step sl5 the IPSec request is forwarded to the ePDG so that the mobile device can register for VoWiFi service.

However, if the quality of the cellular signal is determined to be higher than the quality score for the VoWiFi link, then in step sl7 the admission control function will select the cellular network and therefore the IPSec request is dropped. This will cause the UE to assume that VoWiFi is not available when no IPSec response is received before a time out period.

Furthermore, the admission control function will provide the identity of the recommended alternative network used in the quality assessment as the network to be used by the UE for voice service. A message containing the identity of the alternative network is transmitted from the admission control function to the client running on the UE. Once the UE has received the notification along with the timeout of the IPSec request, the UE is configured to connect to the recommended network for voice services.

Further details of the operational steps in Figure 3 will now be described. Step s5 - VoWiFi request detection Figure 4 is a flowchart showing the processing of step s5 in more detail. In this embodiment, the VoWiFi request detection function 41 in the hub is configured to use IP Flow detection to detect the submission of a new request from the UE to connect to an ePDG associated with the UE.

In step s21, the VoWiFi request detection function 41 accesses a pre-stored list of ePDG IP addresses corresponding to cellular networks that are available in the area of the hub. The ePDGs are edge gateways of the cellular network that allow devices on non-trusted 3GPP networks to access cellular core network services and resources, such as the MMTel voice service residing on the IMS. ePDGs are therefore publically accessible to devices located on public networks such as the Internet.

Once the list has been loaded, in step s23 the VoWiFi request detection function 41 monitors incoming packets received from the WLAN interface of the hub to listen for new IP Flow sessions between a UE connected to the hub's WLAN and a known ePDG. This is achieved by analysing the source and destination addresses in the headers of incoming IP packets. When a new packet is received from the UE in step s25 the VoWiFi request detection function checks to see whether the destination field in the packet header is addressed to a known ePDG address. If the packet is not addressed to an ePDG, then the ePDG detection processing ends and the packet is routed as normal to its destination.

If the test determines that the packet is addressed to a known ePDG IP address, in step s27, the VoWiFi request detection function next checks the existing VoWiFi client list 49 to determine whether the packet is part of an existing IP Flow that has already been recorded as an existing VoWiFi session. If the packet does correspond to an existing VoWiFi IP Flow to an ePDG, processing ends and the packet is forwarded as usual. However, if the packet does relate to a new IP Flow for VoWiFi, in step s29 the packet is blocked by the wireless access point and in step s31 the VoWiFi admission control function is notified that the processing of the first embodiment to determine the optimal radio access network is required and then processing moves to step s7. In step s7 as shown in Figure 3, the hub requests alternative network information from the UE. The interaction with the UE to provide such information will be discussed after the overall processing of the hub has been described.

Step s9 - receive reply from UE

In this embodiment, the UE will respond with a set of available networks in a manner that is similar to the response sent to a cellular network eNodeB during cellular handover.

Examples of UE responses are set out below. Example 1. A number of different alternative networks are returned including LTE networks, a Wi-Fi network and a legacy 3G network which can provide voice services using CSFB.

Detected Network Signal Strength (dBm) Frequency (Mhz)

LTE 1 -77 800

LTE 2 -80 3200

Wi-Fi 1 -30 2412 (2.4Ghz Wi-Fi Channel 1)

HSPA -70 1900

Example 2. No other alternative networks are detected.

Detected Network Signal Strength (dBm) Frequency (Mhz)

- - -

Example 3. A low signal strength alternative network is located.

Detected Network Signal Strength (dBm) Frequency (Mhz)

LTE 1 -120 2600

Once the UE has replied to the query from the network device status query function 47 with a list of observed networks and any measured metric data about those networks, the admission control decision function 43 processes the collected data to determine whether to allow the connection to VoWiFi.

Step sll - determine performance of local and alternative networks Figure 5 is a flowchart showing the processing of step sll in more detail.

As mentioned above, a VoWiFi link between a UE and IMS voice service is formed of several separate networks. Namely a local WLAN between the UE and hub, a public network broadband link between the hub and ePDG, and a private cellular network link between the ePDG and the IMS. To evaluate the quality of the VoWiFi link, the admission control function 43 obtains performance metrics for two of the component links, namely the WLAN and the broadband sections to derive a quality for the VoWiFi link. In this embodiment, it is assumed that the cellular network core 11 will not be performance limiting to the VoWiFi service. In step s41, the admission control function 43 determines the WLAN link quality by comparing the current status of the WLAN against a set of thresholds, stored in the policy database 45. The load of the WLAN is determined based on, for example, the number of connected WLAN devices and the current throughput of the WLAN. For example, if the hub does not have any active data sessions, then the quality of the WLAN is deemed to be high. Alternatively, if there are multiple high definition video streaming sessions or file transfers, then the quality is deemed to be low.

Once the WLAN performance has been measured, in step s43, the admission control function 43 determines the current performance of the broadband link by sending a series of ping requests to a server of the broadband network or the Internet. In this embodiment, the ping requests are sent to the ePDG by the UE. The response packets will provide information about the delay, jitter and packet loss experienced on the link. These metrics are compared against respective thresholds stored in the policy database 45 to determine whether the broadband link is sufficient to carry VoWiFi sessions.

In step s45, the admission control function determines whether the current number of VoWiFi sessions established via the hub is higher than a threshold. For example, the network operator policy defines a threshold number of three active VoWiFi sessions.

In step s47, the information from the WLAN link, broadband link and VoWiFi session tests are combined and mapped to a quality score reflecting the ability of the WLAN and broadband link to the ePDG to carry VoWiFi calls. In particular, the worst performing aspect of the VoWiFi link will be identified as the rate limiting step. In general, if both the WLAN and broadband links are performing at a high level, then the final quality score will be high. However, if the WLAN link is lightly loaded but the broadband link appears to be congested, the final score will be low to reflect the bottleneck imposed by the broadband link. Alternatively, if the broadband link is performing well but the WLAN link is congested, the final score is also low, this time to reflect the WLAN bottleneck.

Steps s41 to s47 allow the admission control function to determine information about the local environment's ability to support a VoWiFi session. The hub cannot however determine information about the environment of the UE since it is in a different location and does not have cellular network interfaces. Therefore, in step s49, the information about alternative networks visible to the mobile device is retrieved from the network device status query function and in step s51 a quality score is derived for each of the detected networks. This quality score is derived using a respective conversion table suitable for each radio access network technology.

Example signal strength to quality conversion table for LTE networks, HSPA networks and Wi-Fi networks are shown below.

Applying the mappings to the detected alternative networks shown in example table 1:

Following the conversions, the alternative network having the highest score is selected and processing returns to step sl3 where the quality of the WLAN/broadband link is compared against the quality of the selected alternative network. In the case of example scan 1 above, LTEl is chosen as the alternative network candidate because it has a slightly higher signal strength despite being mapped to the same quality score. Returning to step sl3 in Figure 3. In the example, the VoWiFi link has been assigned a score of 4, and the alternative network score is also 4.

Therefore processing proceeds to step sl5 because the VoWiFi link score is the same as the alternative network score and therefore there will be no benefit to switching to the alternative network. In step sl5, the IPSec request from the UE is forwarded to the ePDG so that the UE can register for VoWiFi. The VoWiFi client list is also updated with the new entry of existing VoWiFi sessions and processing ends.

However, if there were detected problems in at least one of the VoWiFi link segments, then in step sl3 the alternative network LTE1 would be chosen as the higher performing network. In step sl7 the IPSec request from the UE would be dropped within the hub and the network identifier for LTE1 is provided to the UE.

Once the UE receives this network identifier, it will disassociate from the WLAN and connect to the eNodeB of LTE1 and connect to the voice service using VoLTE.

UE operations to provide alternative network information Returning to Figure 3, the early interaction between the hub and the UE will be described with reference to Figure 6.

Figure 6 schematically shows the functional components of a UE in accordance with the first embodiment.

When computer code instructions stored on a data store are executed by a UE processor, the UE 9 can be regarded as a number of distinct functions. At the user level, applications and services 61 provide voice and data functionality to the end user. A telephony dialler application 63 is shown as an example of a voice service. Other apps include web browsers, camera, GPS applications and VoIP services.

An Operating System 65 provides an environment for the applications 61 and is also responsible for abstracting the software from the specifics of any hardware of the UE9 such as screen, compass, keyboard/user input etc (not shown).

For data exchange with external resources, a connectivity manager 67, which in this embodiment is part of the OS 65, manages a number of data network interfaces for communication with external resources. The connectivity manager 67 is connected to a cellular network interface 69, in this case an LTE modem 69, and also a Wi-Fi WLAN interface71, in this case compliant with IEEE 802.11ac. The connectivity manager 67 is responsible for managing access to the connected interfaces so that an appropriate interface is used to transport data generated by and addressed to applications and services. In this way, the applications do not need to be aware of which data interface is used, they only need to know if a data connection is available. The LTE modem 69 communicates with an eNodeB 13 of the LTE network 3 to access resources such as the MMTel service.

The WiFi interface 71 communicates with the hub 17 via the WLAN 19 generated by the hub 17.

The LTE modem 69 and WiFi-interface 71 therefore provide a respective data link for carrying data packets generated by applications running on the UE 9. In the context of voice services, VoLTE is used when voice data travels via the LTE modem 69 and cellular radio access network of eNodeBs 13 and VoWiFi is used when voice data travels to the ePDG 25 via the Wi-Fi interface 71, WLAN 19, hub 17 and broadband network including the ISP 21 and Internet 23.

One of the advantages of wireless communications is UE mobility. The locations of eNodeBs 13 and hubs 17 are generally fixed but the UEs can move around a defined range and still maintain connectivity to the respective network access.

Furthermore, in LTE, when a UE is engaged in a voice call session and has also moved far away from the serving eNodeB 13, the serving eNodeB will perform a handover procedure to select another eNodeB 13 located in a better geographic location to serve the UE. As part of this process, the serving eNodeB will request a measurement report from the UE for intra-frequency, inter-frequency and inter- AT (Radio Access Technology) carriers. This information is generated by the UE and stored in a measurement report store 73 for transmission to the serving cell. Based on the information in the measurement report, the serving eNodeB will identify and select a new handover eNodeB to serve the UE at its new location.

In contrast, traditionally Wi-Fi generally relies on a client dictated handoff process. When a UE is connected to a WLAN of a wireless access point (AP) or a combined wireless access point device such as a hub, the UE monitors the signal strength of the wireless connection using a Received Signal Strength Indicator (RSSI) metric. When the connection drops below a threshold strength, the UE sends out probe packets to discover new surrounding APs. Any probe responses from surrounding APs are used to select a handoff AP, typically the one having a highest signal strength. Once selected, the UE associates and authenticates with the selected AP. To improve the handoff procedure, the IEEE 802.11k standard defines an AP assisted roaming method in which the AP can scan for neighbouring APs and send this Neighbour Report to connected UEs to aid in their handoff decision.

When a UE is connected to an AP WLAN, the AP monitors the connection signal strength to the UE. When the signal strength drops below a certain threshold, this is indicative that the UE is moving away from the UE, or a source of interference is present to disrupt the connection.

The AP will send a control message to the UE as a warning that a handoff may be required and in response, the UE may request the Neighbour Report and use the neighbour AP information as the basis of the handoff decision. In this embodiment, this neighbour report scan and availability is applied to the UE.

UE operation in response to Step s7 - request alternative network information from UE

The network status function 49 of the hub 17 is configured to communicate with a modified 802.11k client 75 running on the UE 9 using a message exchange process operating in accordance with a modified version of the IEEE 802.11k protocol. In addition to requesting information about neighbouring Wi-Fi networks per 802.11k, the hub also requests information on cellular networks such as Radio Access Technology, frequency band and signal strength observed by the UE.

The modified 802.11k client 75 provides several additional functions over a standard 802.11k UE client. In a standard 802.11k client, the client requests neighbour reports from an AP. The modified 802.11k client 75 generates neighbour reports to record the presence of surrounding APs and also allows the generated neighbour reports to flow in the opposite direction, namely from the client to the AP/hub.

Furthermore, the connectivity manager 67 is linked to the modified 802.11k client and the measurement report 73 on the cellular interface 69 to enable the neighbour report to also include cellular networks within range.

Figure 7 is a flowchart showing the processing of the UE in response to an action frame requesting information about all neighbour cellular and Wi-Fi networks currently visible to the UE 9.

In step s61, the WiFi interface 71 identifies the action frame relating to the 802.11k request. If such a frame is received, the modified 802.11k client 75 is notified and in step s63 the neighbour report for surrounding WLANs is generated in a similar manner to the processing in an 802.11k hub. In order to include information about the cellular networks, in step s65 the modified 802.11k client 75 notifies the connectivity manager 67 that a request has been received.

In step s67, the connectivity manager 69 communicates with the cellular interface 69 and retrieves the information in the measurement report 73 about any observed cellular networks including Radio Access Technology, frequency band and signal strength observed by the UE. In step s69, the connectivity manager 69 forwards the retrieved information to the modified 802.11k client.

In step s71, the modified 802.11k client 75 merges the cellular network measurement report 73 information with the generated neighbour report and in step s73 responds to the network status information requestor 47 and processing ends.

The processing of the UE provides the hub with alternative network information. This enables the hub to evaluate the relative qualities of the current connection and possible connections via other networks in order to determine whether to allow the UE's request for VoWiFi to be allowed or whether an alternative network would be more suitable for carrying voice services.

Second embodiment

In the first embodiment, a hub can intercept a request from a UE registering for VoWiFi and determine the quality of the current VoWiFi path between the UE and the ePDG. It also receives information of alternative networks available to the UE. If the quality of the current connection is more suitable for VoWiFi than any alternative network, then the VoWiFi request is forwarded to the ePDG. However, if the quality of the VoWiFi link is lower than an alternative network, then the hub will identify a recommended alternative network and notify the UE. Once notified, the UE is steered to the recommended access network for voice services.

The advantage of the embodiment is that, if needed, the UE is steered to a different access network before control data reaches the external networks. This reduces control information being passed to the ePDG via the external network and the associated resource hit this incurs.

The drawbacks of such a solution is that this functionality requires modifications to every hub to be capable of providing the capability and in use there is more processing load on the hub.

In the second embodiment, a more centralised approach is taken whereby the admission control for a UE to use VoWiFi is carried out by the ePDG of the cellular network. Figure 8 is an overview of the system according to the second embodiment.

The system shown in Figure 8 differs from the system of Figure 1 with the substitution of ePDG 101 and hub 103. Components which have the same functionality as in the first embodiment have the same reference numeral and will not be described again. Since the operation of the hub in the first embodiment was largely transparent to the UE, the UE 9 of the second embodiment is functionally the same.

In the second embodiment, in order to establish a VoWiFi connection via the ePDG 101, the UE 9 will first connect to a WLAN 19 of a hub 103. Once wirelessly connected, the UE will attempt to establish a secure connection using IPSec to the ePDG 101 via the broadband link from the hub 103 to the ISP 21 and Internet 23.

In this embodiment, the hub 103 has less modifications compared with the hub of the first embodiment, the hub 103 does not need to carry out any IP Flow analysis or packet inspection to identify IPSec requests nor perform any measurements of the WLAN and broadband link.

The hub of the second embodiment does however contain the UE information requestor function to communicate with the modified 802.11k function of the UE in order to obtain information about any neighbouring WLAN and cellular networks. These are forwarded to the ePDG 101 instead of being processed locally.

The ePDG 101 is the destination end point of the UE's IPSec tunnel request, the ePDG 101 is configured to perform the Admission Control decision by evaluating any received IPSec requests, and determining whether a UE's request for VoWiFi should be allowed or whether an alternative network would be more suitable for voice communication.

Although carried out by the ePDG 101 instead of the hub 103, as in the first embodiment, the quality of the current VoWiFi path is compared with the likely quality of VoLTE or VoWiFi paths available from other network links. The IPSec request is allowed if the quality of the VoWiFi link is deemed to be the same or higher quality than the alternative networks. Conversely, the IPSec request is rejected if the detected alternate networks are deemed to be capable of providing a better voice service.

Furthermore, in this embodiment, the ePDG 101 can also choose to reject a UE request for other reasons not related to link quality, namely a policy to drop a VoWiFi connection request if the UE is connected to a blacklisted hub. Figure 9 schematically shows the functional components of the ePDG 101 in the second embodiment.

The ePDG contains interfaces to various network components: The SWm interface 111 connects to UEs via non-trusted non-3GPP networks;

The AAA interface 113 connects to an Authentication, Authorisation and Accounting server located in the network core;

The DNS interface 115 connects to a DNS server within the network core;

The Management interface 117 connects to a management device for configuring the operation of the ePDG; and

• The S2b interface connects to a PGW of the network core.

To route packets between the various interfaces, the ePDG contains a routing function 121 to inspect the packets and forward them to the relevant interfaces for external processing. Where packets are directed to the ePDG itself, for example requests from UEs for establishing IPSec tunnels, the packets are forwarded to a processing function 123.

The processing function 123 has an IPSec processor 125 for analysing incoming requests from UEs. In accordance with the second embodiment, the IPSec processor 125 is responsible for allocating resources to incoming tunnel requests. The IPSec processor 125 is connected to a client list 127 and a VoWiFi admission control function 129. In combination, these components of the ePDG 101 in accordance with the second embodiment, determine whether a VoWiFi request should be accepted.

The client list 127 contains a list of existing IPSec sessions to UEs that have already established VoWiFi connections. The IPSec processor 125 uses this list to identify new VoWiFi requests from UEs.

The VoWiFi admission control function 129 is connected to a UE link analysis function 131, a UE information requestor 133 and a policy database 135 to determine whether the VoWiFi request should be allowed.

The operation of the processing function 123 in the ePDG 101 will be described with reference to Figure 10. Figure 10 is a flowchart showing the operation of the ePDG in the second embodiment.

The operation begins, in step slOl, with the ePDG receiving an IPSec tunnel establishment request from a UE located on a non-trusted 3GPP network.

In step sl03, the ePDG processes the source header of the IP data packet to identify the wireless access point router (hub) associated with the requesting UE. Since the IPSec request is encapsulated in an IP packet, the hub will have replaced the UE's WLAN address with its public IP address before routing the packet to the ePDG. To determine whether the request for VoWiFi should be allowed for the UE, in step sl05, the ePDG determines statistics for the data link to the UE. The requested information includes load, the number of current Wi-Fi endpoints, throughput and also statistics for the link to the AP. In this embodiment, the UE link analysis function pings the UE to determine latency, jitter and packet loss data for the data path link.

In step sl07, the ePDG then monitors its own load information to determine whether it can support a VoWiFi request. This includes the number of currently active IPSec tunnel connections.

In step sl09, the ePDG requests information relating to any alternative networks within range of the UE and in step sill the list of available networks is received from the UE. In these two steps, the ePDG actually sends control data requests to the hub 103 and the UE information requestor of the hub 103 interacts with the 802.11k client of the UE as described in the first embodiment. The returned data about available networks is then sent to the ePDG 101.

In step sll3, the ePDG 101 uses the collected information to determine quality scores for the VoWiFi and alternative network links in a similar manner to the equivalent VoWiFi admission control function of the hub in the first embodiment. Furthermore the calculated quality scores can be modified/normalised based on other informati on available to the ePDG. For example, if the UE 9 is within range of an eNodeB of the cellular network, the ePDG 101 will modify any calculated quality score based on a real-time view of the load conditions the observed eNodeB since the ePDG is part of the same cellular network. Furthermore, if the other WLANs are available to the UE, the calculated quality score for those alternative WLANs are lowered if the ePDG is overloaded, since its ability to service VoWiFi sessions would be reduced regardless of the WLAN used by the UE. In step sll5, a comparison of the quality of the VoWiFi connection and the highest performing alternative network connection (after normalisation/adjustment) is carried out and if it is determined that the current WLAN path has the highest quality, a VoWiFi connection is possible, and therefore the IPSec request is allowed and the VoWiFi connection can be established with the IMS.

Alternatively, if the quality of the cellular network/alternative network connection is higher, then in step sll9, the ePDG will reject the IPSec request and include an identity of the alternative network so that the UE will not be able to connect and therefore it will revert to the alternative network.

The second embodiment uses an ePDG which can determine both VoWiFi path and VoLTE path quality and can make decisions about how to steer devices requesting VoWiFi following the standard UE behaviour. Alternatives and modifications

In the first embodiment, the admission control function determines the status of the WLAN and broadband local links and also the alternative networks detected by the UE. Other network information can be used, in an alternative, the access point accesses information relating to the presence of adjacent networks. This information may be either pre-configured or dynamically updated on the Wi-Fi Access Point. This information allows the ISP to statically or dynamically configure the Wi-Fi Access Point to inform it that an alternative Wi-Fi network available in the area that is more suitable for Wi-Fi Calling.

In the above embodiments, quality scores are calculated for each of the available alternative networks and then only the network having the highest quality score is used in the comparison against the WLAN conditions. This reduces the processing time since only one comparison needs to be performed. In an alternative, every available network is compared and details of each available network which can provide better voice service than the WLAN are sent to the user.

In the embodiments, IPFlow packet inspection of the packet headers is used to detect possible IPSec requests between a UE connected to the hub WLAN and an ePDG.

There are different ways of determining whether an IPSec session has been requested. In an alternative, a Deep Packet Inspection (DPI) function in the hub may identify IPSec establishment requests that can be associated with a VoWiFi service (e.g. sent to a pre-configured domain name or with a VoWiFi indicator embedded in the request).

In the embodiments, a client loaded into the UE is configured to communicate with the hub to process requests to locate other radio access networks and respond to the requests from the hub. In other cases, the functionality is built into the operating system or any other processor (e.g. modem chipset) of the UE.

In the embodiments, the UE merges WiFi neighbour information with cellular network measurement reports and forwards the combined data set to the hub. Once received, the VoWiFi admission control function will calculate quality scores for the various networks.

In an alternative, the modified 802.11k client or a sub-function of the UE can also calculate quality scores of the observed networks which are included in the returned information sent to the hub. In a further alternative, the modified 802.11k client only sends quality scores in place of the measurement reports.

In the second embodiment, the ePDG determines the performance of the potential VoWiFi link by analysing the performance statistics of packets sent and received from the UE to reduce the number of modifications required to the hub. In an alternative, the ePDG is linked to the hub of the first embodiment and requests WLAN statistics from the hub in a similar manner to the first embodiment.

In the first embodiment, a system is described in which the hubs are responsible for controlling access to the VoWiFi service by UEs while in the second embodiment the ePDG is the only controller for VoWiFi access. In an alternative, the ePDG of the second embodiment and hubs from the first embodiment are combined so that the system contains a mix of entities for controlling access.

Insofar as embodiments of the invention 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 invention. 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 utilises 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 invention.

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

The scope of the present invention 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.