CN106576230A - WI‑FI Calls Using SIP‑IMS Handsets and Evolved Packet Data Gateways - Google Patents

Abstract

Wi-Fi calls using a mobile device and an evolved packet data gateway (ePDG) are described herein. For example, the mobile device may determine whether any LTE coverage is available, whether data roaming is available, whether a Visited Public Land Mobile Network (VPLMN) is available, and whether a DNS query to a visited ePDG (VePDG) is successful. The mobile device may connect to the VePDG in response to determining that LTE coverage is available, data roaming is available, a VPLMN is available, and determining that the DNS query to the VePDG is successful. Otherwise, the mobile device may connect to a home ePDG (heddg).

Description

WI-FI Calls Using SIP-IMS Mobile Phones and Evolved Packet Data Gateways

Cross references to related patent applications

This application claims the benefit of priority to U.S. Provisional Patent Application No. 62/004,861, filed May 29, 2014, and U.S. Nonprovisional Patent Application No. 14/726,279, filed May 29, 2015, which are incorporated by reference in their entirety Incorporated into this article. The Internet Protocol (IP) Multimedia Subsystem (IMS) is an architectural framework for delivering IP multimedia services.

Background technique

Historically, mobile phones have provided voice call services over circuit-switched networks rather than strictly over IP packet-switched networks. Alternative methods of delivering voice or other multimedia services over IP have become available on smartphones in recent years, but they have not been standardized across the industry. IMS is the architectural framework that provides this standardization. In addition, IMS is designed to facilitate the access of multimedia and voice applications from wireless and wired terminals. Wherever possible, Internet Engineering Task Force (IETF) protocols such as Session Initiation Protocol (SIP), for example, are used to de-integrate IMS with the Internet.

Description of drawings

The Detailed Description is described with reference to the drawings in which the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.

1 is a schematic diagram of an exemplary IMS architecture with a single IMS stack supporting multiple IMS services and evolved packet data gateway (ePDG) functionality according to the present disclosure.

2 is a schematic diagram of an exemplary high-level end-to-end architecture using SIM IMS for Wi-Fi calling according to the present disclosure.

FIG. 3 is a flowchart of an exemplary process for a user equipment to make an emergency call according to the present disclosure.

Fig. 4 is a flow chart of an exemplary decision process for a user equipment to determine whether to access a visited ePDG or a home ePDG according to the present disclosure.

FIG. 5 is a schematic diagram of an exemplary scenario of a tunneling mechanism according to the present disclosure.

FIG. 6 is a schematic diagram of an exemplary scenario of a tunneling mechanism according to the present disclosure.

FIG. 7 is a schematic diagram of an exemplary scenario of a tunneling mechanism according to the present disclosure.

FIG. 8 is a schematic diagram of an exemplary scenario of a tunneling mechanism according to the present disclosure.

FIG. 9 is a schematic diagram of an exemplary scenario of a tunneling mechanism according to the present disclosure.

FIG. 10 is a schematic diagram of another exemplary scenario of a tunneling mechanism according to the present disclosure.

Fig. 11 is a schematic diagram of yet another exemplary scenario of a tunneling mechanism according to the present disclosure.

Fig. 12 is a schematic diagram of still another exemplary scenario of the tunneling mechanism according to the present disclosure.

FIG. 13 is a block diagram of an example device configured to implement embodiments of the present disclosure.

14 is a flowchart of an exemplary process according to the present disclosure.

detailed description

In the following description, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific exemplary embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the concepts disclosed herein, and it is to be understood that the disclosed embodiments may be modified and other embodiments utilized without departing from the present disclosure. range. Therefore, the following detailed description should not be construed as limiting.

The articles "a" and "an" are used herein to denote one or more than one (ie at least one) of the grammatical object of the article. As an example, "user" refers to one user or more than one user. Reference throughout this specification to "one embodiment," "an embodiment," "an example," or "an example" means that a particular feature, structure, or characteristic described in connection with the embodiment or example is included in at least one implementation of the present disclosure. example. Thus, appearances of the phrases "in one embodiment," "in an embodiment," "an example," or "example" in various places throughout this specification are not necessarily all referring to the same embodiment or example. Furthermore, the particular features, structures, databases or characteristics may be combined in any suitable combination and/or subcombination in one or more embodiments or examples. In addition, it should be understood that the drawings provided herein are for the purpose of explanation to those of ordinary skill in the art and that the drawings are not necessarily drawn to scale.

Embodiments according to the present disclosure may be embodied as apparatuses, methods or computer program products. Accordingly, the present disclosure can take the form of an entirely hardware-inclusive embodiment, an entirely software-inclusive embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which generally may be referred to herein as all Known as a "circuit", "module" or "system". Furthermore, embodiments of the present disclosure may take the form of a computer program product having computer usable program code embodied in any tangible medium expression.

Any combination of one or more computer usable or non-transitory computer readable medium(s) may be utilized. For example, a non-transitory computer readable medium may include one or more of the following: portable computer diskettes, hard disks, random access memory (RAM) devices, read only memory (ROM) devices, erasable programmable read-only Memory (EPROM or Flash) devices, portable compact disc read only memory (CDROM), optical storage devices and magnetic storage devices. Computer program code for carrying out operations of the present disclosure may be written in any combination of one or more programming languages. Such code may be compiled from source code into computer readable assembly language or machine code suitable for a device or computer on which the code will be executed.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing specific logical functions. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or actions, or by special purpose hardware and Combination of computer instructions to achieve. These computer program instructions can also be stored in a computer-readable medium, which can instruct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable medium produce an article of manufacture including the instruction method, in fact The function/action specified in the flow diagram and/or one or more block diagram blocks.

As used herein, the terms "handset", "mobile device", "user terminal" and "user equipment" are interchangeable and refer to a mobile communication device, such as a smartphone, used by a user for wireless communication. The term "ePDG" is used here to denote the Evolved Packet Data Gateway for Internet Protocol Security (IPSec), which tunnels from user equipment through untrusted non-3GPP access networks, e.g., Wi-Fi networks or any network using unlicensed spectrum. Connect to the network. The term "Wi-Fi calling" as used herein denotes a voice service to be carried over an IPSec tunnel. The term "video call" as used herein denotes IMS-based full-duplex voice and simplex/full-duplex video media with tight synchronization between the constituent streams. The term "RCS" as used herein means Rich Communication Suite Services enabled over ePDG connectivity as defined by the GSMA.

WI-FI calling using SIP-IMS mobile phone

This disclosure describes techniques that may be implemented in Wi-Fi calling systems and methods using SIP-IMS user equipment and ePDG. Furthermore, embodiments of the techniques described herein can be implemented in protocols so that Wi-Fi calling using user equipment and ePDGs can be done.

FIG. 1 illustrates an exemplary IMS architecture 100 with a single IMS stack and ePDG functionality supporting multiple IMS services according to the present disclosure. The example IMS architecture 100 may include an example device 190 and an example network 195 , portions of which form an IMS platform 180 . Exemplary networks 195 may include IMS core network 170 , packet data network (PDN) gateway (P-GW) 150 , ePDG 152 , cellular network 140 , and Internet 142 , which may include application server 144 . Cellular network 140 may be communicatively connected to IMS core network 170 via P-GW 150 . Internet 142 may be communicatively connected to ePDG 152 , which may be communicatively connected to IMS core network 170 via P-GW 150 . Exemplary network 195 may also include servers and backend nodes 180 that provide a number of communication services to exemplary devices 190 over IMS core network 170 .

Exemplary device 190 may include chipset 105 , cellular communication module 130 and Wi-Fi communication module 132 . Chipset 105 may include IMS stack 120 and ePDG module 122 . The IMS stack 120 may include an IMS transport and terminal layer, which may be equivalent to the transport layer (layer 4) of the Open Systems Interconnection (OSI) model, a session control layer, which may be equivalent to the session layer (layer 5) of the OSI model , and the application server layer, which may be equivalent to the presentation and application layers (layers 6 and 7) of the OSI model. The ePDG module 122 can have ePDG functionality and connection management according to the present disclosure. The cellular communication module 130 may be configured to establish communication with the cellular network 140 , eg, to receive and/or place calls over the cellular network 140 . The Wi-Fi communication module 132 may be configured to establish communication with the Wi-Fi network 142 , for example to receive and/or place calls over the Wi-Fi network 142 . Exemplary device 190 may also include an application/operating system (OS) layer 102 executed by chipset 105 to provide a number of IMS services 140 in application/OS layer 102 to a user of exemplary device 190 . One or more over-the-top (OTT) applications 110 may also execute in the application/OS layer 102 . The number of IMS services 104 supported by the exemplary device 190 may include, for example, Voice over Long Term Evolution (VoLTE) 112 , Voice over Wi-Fi Calling (WFC) 114 , Video Calling 116 , and Rich Communication Services (RCS) 118 .

Various embodiments of the present disclosure are directed to Wi-Fi calling services using SIP IMS and may be implemented with exemplary device 190 . For example, a Wi-Fi call can be implemented using a SIP-IMS mobile phone. In particular, the Wi-Fi layer can be used as a radio access technology (RAT) for Wi-Fi calls using SIP IMS to access the IMS network. For illustration, a number of typical use cases for various aspects of the present disclosure are provided below. FIG. 2 illustrates an exemplary high-level end-to-end architecture 200 for Wi-Fi calling using SIM IMS according to the present disclosure.

Referring to FIG. 2 , an exemplary architecture 200 may include an IMS network 204 , a High Speed Packet Access (HSPA) network 202 , which may include a third generation (3G) mobile telecommunications network, and the Internet 206 . IMS network 204 may include one or more Telecom Application Servers (TAS) 240, one or more Interface Communications Processor (IMP) servers 242, one or more Interrogation/Serving Call Session Control Function (I/S-CSCF) servers 244 , one or more Home Subscriber Servers (HSS) 246 , one or more Presence Servers 248 and Proxy CSCF (P-CSCF) Server 230 . HSPA network 202 may include Gateway General Packet Radio Service (GPRS) Support Node (GGSN) 220 . Internet 206 may include Wi-Fi access point 212 and session border controller (SBC) 250, which may be configured to function as an ePDG. The exemplary architecture 200 may also include, for example, user equipment 210 (eg, a smartphone or cell phone) and a personal computer (PC) terminal 214 . User equipment 210 may be an implementation of exemplary device 190 of FIG. 1 and may be Wi-Fi calling and ePDG capable. User equipment 210 may be communicatively connected to one or both of HSPA network 202 and Internet 206 . PC terminal 214 may be communicatively connected to Internet 206 . In the example shown in FIG. 2, user equipment 210 may connect to HSPA network 202 via a cellular RAT. Alternatively or additionally, user device 210 may connect to Internet 206 via Wi-Fi access point 212 through Wi-Fi RAT.

An illustrative use case related to Wi-Fi calling using SIP IMS is described below. In some embodiments, a user of mobile device 210 can place and receive voice calls over a SIP IMS network (eg, IMS network 204 ) while connected to Wi-Fi, eg, via Wi-Fi access point 212 . Voice calls over Wi-Fi using SIP IMS may drop if the user moves outside of the Wi-Fi coverage area. In some embodiments, user equipment 210, such as a smart phone or a SIP-IMS handset, can quickly register on a cellular network (eg, HSPA network 202) and can be ready to place and receive calls. In some embodiments, when a user moves into a Wi-Fi coverage area while making an active voice call over the 2G/3G network, the call may continue on the 2G/3G network until the call is dropped or terminated by the user. Then, the user equipment 210 can complete the SIP IMS registration through Wi-Fi. In some embodiments, a user is able to dial one or more short codes, such as 411, 611, and 911, over the SIPIMS network while connected to Wi-Fi.

An illustrative use case related to messaging over Wi-Fi using SIP IMS is described below. Messaging may be provided by, for example, Short Message Service (SMS) and/or Multimedia Messaging Service (MMS). In some embodiments, a user may use user device 210 to send and receive text messages, e.g., via SMS, over a SIP IMS network (e.g., IMS network 204), when connected to Wi-Fi, e.g., via Wi-Fi Access point 212. Additionally or alternatively, the user may use the user equipment 210 to send and receive multimedia messages, eg via MMS when connected to Wi-Fi, over a SIP IMS network.

An illustrative use case related to supplementary services for Wi-Fi using SIP IMS is described below. In some embodiments, a user may enable or disable one or more features of user equipment 210 through a SIP IMS network (eg, IMS network 204) while connected to Wi-Fi, e.g., via Wi-Fi access point 212, For example, call forwarding and call waiting options. For example, a user may disable one or more features in a settings menu of user device 210 or through a dialer of user device 210 .

In order to implement various embodiments of the present disclosure, a number of requirements need to be satisfied. The following description relates to requirements for user equipment 210 to enable user equipment 210 to make Wi-Fi calls over a SIP IMS network (eg, IMS network 204 ).

In some embodiments, Wi-Fi calling enabled user equipment, eg, user equipment 210, may comply with IMS-related protocols and standards. In some embodiments, user equipment 210 may support multiple Wi-Fi calling and communication modes, which determine what bearer each service will use. For example, supported modes may include a "Wi-Fi Preferred" mode, a "Wi-Fi Only" mode, a "Cellular Preferred" mode, and a "Cellular Network Only" mode. The "cellular only" mode may not be a user-facing feature. This mode only needs to turn off the Wi-Fi calling feature to be active.

In some embodiments, the "Wi-Fi preferred" mode may be set as the default mode on user equipment 210 for Wi-Fi calling. When user equipment 210 is in "Wi-Fi preferred mode" for Wi-Fi calling, one or more conditions may apply, as described below. In some embodiments, user device 210 may initiate and complete a SIP IMS registration over Wi-Fi when Wi-Fi is available regardless of cellular network availability. In some embodiments, user device 210 may route some or all voice and messaging communications, such as SMS and/or MMS, through the SIP IMS network. In some embodiments, user device 210 may route some or all non-IMS data communications over the local Wi-Fi connection. In some embodiments, if no qualified Wi-Fi network is available, user device 210 may use the available cellular network for all services while still monitoring Wi-Fi. In some embodiments, for a user equipment, for example, user equipment 210, which has an ePDG function and is actively calling a VoLTE call, whenever one or more hand-in conditions are met, the user equipment 210 may try to handover ( hand-over) is the Wi-Fi mode. In some embodiments, for a user equipment, for example, user equipment 210, which has ePDG functionality and is in an active VoLTE call, whenever one or more hand-out (hand-out) conditions are met, user equipment 210 may attempt a handover to LTE.

When user equipment 210 is in "Wi-Fi only mode" for Wi-Fi calling, one or more conditions may apply, as described below. In some embodiments, user equipment 210 may turn off its cellular radio. In some embodiments, user device 210 may initiate and complete SIPIMS registration over Wi-Fi when Wi-Fi is available regardless of cellular network availability. In some embodiments, user device 210 may route some or all voice and messaging communications, such as SMS and/or MMS, through the SIP IMS network. In some embodiments, user device 210 may route some or all non-IMS data communications through the SIP IMS network. In some embodiments, user device 210 may not attempt to scan for, enable or connect to a cellular network if no qualified Wi-Fi network is available. In some embodiments, for an ePDG-capable user equipment 210, ie, in an active VoLTE call, whenever one or more hand-in conditions are met, the user equipment 210 may attempt to switch to Wi-Fi mode. In some embodiments, for an ePDG enabled user equipment, eg, user equipment 210 , ie in an active VoLTE call, user equipment 210 may remain in Wi-Fi mode and may not attempt any handover. In some embodiments, the "Wi-Fi only mode" may remain active as long as the user device 210 enables Wi-Fi calling. Also, if Wi-Fi calling is disabled, the logic of "Wi-Fi-only mode" no longer applies.

When user equipment 210 is in "cellular preferred mode," one or more conditions may apply, as described below. In some embodiments, user device 210 may use a cellular network for select voice, messaging, and/or data communications, and may use Wi-Fi, if available, for other data communications. In some embodiments, user equipment 210 may not attempt to initiate a SIP IMS registration over Wi-Fi after successfully connecting to Wi-Fi if a cellular network is available. In some embodiments, without cellular coverage, user device 210 may initiate and complete SIPIMS registration over Wi-Fi when it is available. Registration can remain valid until user device 210 loses Wi-Fi registration, regardless of changes in the state of the cellular network. In some embodiments, for an ePDG enabled user equipment (ie in an active VoLTE call), eg user equipment 210, the user equipment 210 may remain in LTE mode regardless of Wi-Fi coverage. In some embodiments, for an ePDG enabled user equipment (ie, in an active Wi-Fi call), eg, user equipment 210, whenever one or more hand-out conditions are met, user equipment 210 may attempt to handover to LTE.

When user equipment 210 is in "cellular network only mode," user equipment 210 may behave as if no Wi-Fi calling is supported. One or more conditions can be applied, as described below. In some embodiments, user device 210 may use a cellular network for select voice, messaging, and/or data communications, and use Wi-Fi, if available, for other data communications. In some embodiments, user device 210 may not attempt to initiate a SIP IMS registration over Wi-Fi after successfully connecting to Wi-Fi. In some embodiments, user equipment 210 may not attempt to initiate a SIP IMS registration over Wi-Fi in the absence of cellular coverage.

According to the present disclosure, when registering using Wi-Fi, there is a SIP IMS registration requirement for a user equipment, eg, user equipment 210, as described below. In some embodiments, the user device 210 may attempt to register with the IMS network once the user device 210 has obtained a valid IP and DNS address via DHCP or is using static IP settings. For example, user equipment 210 may attempt to register if the correct SIM card is used and user equipment 210 is not in airplane mode. In some embodiments, when a registration failure occurs, user device 210 may display one or more associated error codes. The error code may continue to be displayed as long as the error condition persists. In some embodiments, when registering on the SIP IMS network, the user equipment 210 may log out from the SIP IMS network when one or more of the following conditions are met: (1) the user equipment 210 is powered off; (2) the user equipment 210 the user chooses to disconnect from the current active Wi-Fi; and (3) the user disables Wi-Fi calling. In some embodiments, if the user equipment 210 loses IMS registration while maintaining a good Wi-Fi connection, when the current profile is set to "Cellular Preferred" mode or "Wi-Fi Preferred" mode, the user equipment Can fall back to cellular coverage (if available). Optionally, the user device 210 may retry the IMS registration if the connection preference is set to "Wi-Fi preferred" mode or "Wi-Fi only" mode. In some embodiments, user device 210 may register with a SIP IMS network when using a valid SIM card. If other SIM cards are used, the user device 210 may not initiate an IMS registration and may display one or more appropriate error messages.

According to the present disclosure, there is a mobility requirement for user equipment, as described below. In some embodiments, a user equipment, eg, user equipment 210, may roam in when a threshold Wi-Fi Received Signal Strength Indicator (RSSI) level (eg, -75dBm) is met. This threshold may be a rove-in threshold used to determine whether user equipment 210 should attempt IMS registration when connected to a Wi-Fi network. The roam-in threshold may be applied when the user device 210 is in idle mode and may be independent of device connection preferences. In some embodiments, user equipment 210 may monitor Wi-Fi RSSI levels when registered on SIP IMS and idle. If the Wi-Fi signal level drops below a preset threshold, eg, -85dBm, the user equipment 210 may start a roam-out procedure. In some embodiments, with SIM lock enabled, user equipment 210 may be able to remain on the cellular network after roaming out without prompting the user to enter a PIN code. In some embodiments, if the user equipment 210 does not support handover capability (e.g., no ePDG logic) and is on an active Wi-Fi call, and if the Wi-Fi RSSI approaches a roam-out threshold (e.g., -85dBm), the user Device 210 may generate an audible notification (eg, a two-tone beep) alerting the user that user device 210 is leaving Wi-Fi coverage and that the call may be dropped. Audible notifications can be accompanied by on-screen messages. The wording of the on-screen message may be provided by the service provider. In some embodiments, when the user equipment 210 is in an active VoLTE call and enters the coverage of the Wi-Fi network, its information (for example, SSID and password) is saved in the user equipment 210, if the user equipment 210 is in the "Wi-Fi Preferred" mode or "Wi-Fi only" mode, user equipment 210 can switch to Wi-Fi. If user equipment 210 is in "cellular preferred" mode, user equipment 210 may not attempt to hand-in to Wi-Fi. Alternatively, user equipment 210 may hand-in to Wi-Fi if user equipment 210 is observing a Wi-Fi RSSI that satisfies a hand-in threshold (eg, -75dBm). In some embodiments, when the user equipment 210 is in an active Wi-Fi call, the user equipment 210 may evaluate the Wi-Fi link and cellular conditions via preset algorithms to determine whether and when to switch the call to VoLTE. This may occur when the user equipment 210 is in "Wi-Fi preferred" mode or "Cellular preferred" mode. If user equipment 210 is in "Wi-Fi only" mode, it may not attempt any handover to cellular. In some embodiments, the handset manufacturer of user equipment 210 may implement a handover algorithm to decide whether to hand off from Wi-Fi to cellular. The handover algorithm may consider multiple factors when deciding whether to initiate a handover from Wi-Fi to cellular, including: retransmission and loss of Wi-Fi packets on the downlink and uplink, Wi-Fi RSSI values As well as cellular network availability and signal strength.

According to the present disclosure, there are calling features and SMS/MMS requirements for user equipment, as described below. In some embodiments, when an emergency call is invoked and user equipment, eg, user equipment 210, is registered with GERAN/UTRAN, user equipment 210 may apply normal 911 call procedures. When an emergency call is invoked and the user device 210 is registered on the SIP IMS network over Wi-Fi, a number of requirements may apply to the user device 210, as described below.

FIG. 3 illustrates an exemplary process 300 for a user equipment to make an emergency call according to the present disclosure. The user equipment in the example shown in FIG. 3 may be exemplary device 190 and/or user equipment 210 as described above. It is worth noting that more than one operation/task of the example process 300 may occur in parallel, since the operations/tasks of the example process 300 do not have to occur serially. Referring to FIG. 3 , example process 300 may occur at some or all of dialer portion 340 , IP call portion 350 , and cellular call portion 360 of a user device (eg, example device 190 or user device 210 ). At 302, a user of a user device dials "911" for an emergency call. At 304, the user equipment determines whether Wi-Fi calling or cellular calling (indicated as circuit switching or "CS") is available on the IMS network. If Wi-Fi calling on the IMS network is available, the decision process 300 flows to the left, otherwise the decision process 300 flows to the right. Where Wi-Fi calling is available, at 306 the user device dials 911 to initiate an emergency call. At 308, the user equipment determines whether to redirect the call to the CS, or whether an error occurred. If the user equipment determines that the call needs to be redirected to CS or if an error occurs, the user equipment dials 911 at 314 to initiate an emergency call over the cellular network at 332 . Otherwise, at 310 the user equipment dials 911 to initiate an emergency call over the Wi-Fi network. If the user equipment decides to make an emergency call over the cellular network (eg, due to unavailability of Wi-Fi), at 316 the user equipment waits for a cellular connection. At 318, the user equipment determines whether the wait times out while searching for cellular coverage. If waiting for the cellular connection times out, then example process 300 proceeds to 312 where the user device dials 911 via Wi-Fi calling. Additionally, if the user device decides to make an emergency call over the cellular network, at 322 the user device dials 911 and at 324 the user device turns on its cellular radio. At 326, the cellular radio of the user equipment is turned on and searches for cellular coverage. Depending on how soon cellular coverage is found, the search at 318 may or may not time out. After cellular coverage is found, at 328 the user equipment initiates a 911 call to initiate an emergency call at 330 over the cellular network.

In some embodiments, the user equipment may follow a predetermined set of emergency operating steps in identifying an emergency call. In some embodiments, when registering on IMS for Wi-Fi calling, the user device may route emergency calls on cellular or IMS, depending on the preference set by the network during registration. This applies regardless of the connection preference selected. In some embodiments, a user device may register a preference to receive emergency calls from the network in an "emergency call preference" mode. In some embodiments, the user device may check cellular coverage when the emergency call preference is set to cellular. If any cellular coverage is found, the user equipment can log off from the IMS domain and go back to cellular and make a 911 call. User equipment can remain on the cell for a duration specified by a guard timer to allow for potential PSAP callbacks.

Once the guard timer expires, the user equipment may re-register with the IMS if one or more Wi-Fi conditions are met, as described below. In some embodiments, if no cellular network is available to place the emergency call, the user equipment may complete the call on the IMS network. In some embodiments, the emergency call setup time may not exceed a predetermined duration, such as 10 seconds, regardless of whether the emergency call is made over cellular or Wi-Fi. In some embodiments, when the emergency call preference is set to Wi-Fi, the user equipment can directly complete the call on the IMS network. In some embodiments, when the emergency call is made directly through the IMS, the call setup time may not exceed a predetermined duration, such as 10 seconds. In some embodiments, the user device may complete the call on the cellular network when the network has not set an emergency call preference, and this may be the default behavior.

In some embodiments, a user device may attempt to find its location whenever it registers to IMS over Wi-Fi for voice services. The user equipment may include the last seen P-LANI and the timestamp when it was last observed and the registration timestamp when the user equipment attempted to register on Wi-Fi. In some embodiments, the user device may save the acquired location for the duration of the entire session. In some embodiments, if the Wi-Fi access changes, eg a new access point with the same SSID, the user equipment may attempt to acquire a new location. In some embodiments, user equipment may support N11 calling lists such as 611 calling, 411 calling and 911 calling as supported on 2G/3G devices. In some embodiments, the user equipment may support a Message Waiting Indicator (MWI). In some embodiments, a user device may support SMS while on a Wi-Fi call.

According to the present disclosure, various error codes occur during different connection phases, as described below.

Table 1 below shows the call drop error codes supported in various embodiments of the present disclosure.

Table 1

Table 2 below shows error codes that may be displayed by the user equipment when the user equipment encounters an error corresponding to the errors shown in Table 1.

Table 2

Referring to Figures 1-3 and the description above, there are various user experience requirements, as described below. In some embodiments, when Wi-Fi is enabled for the first time, the user device may provide the user with a pop-up window informing the user of the user device's Wi-Fi calling capabilities. The displayed message text may be provided by the service provider. If Wi-Fi is enabled by default, a popup may appear on first Wi-Fi connection. In some embodiments, the first popup may include buttons, but not limited to, a "Skip" button to allow the user to return to the previous screen, and a "Learn More" button to take the user to the end of the tutorial. front page. In some embodiments, when the user equipment successfully completes the SIP/IMS registration, a Wi-Fi calling icon may be displayed on the left side of the status bar. The cellular signal meter can go to zero, can have a sign over the top, or can disappear completely. For ePDG enabled user equipment, a Wi-Fi calling icon may be shown upon successful registration, while the cellular radio may not be disabled. In some embodiments, the Wi-Fi calling icon may remain in the status bar as long as the registration is active. If the registration is lost, the Wi-Fi Calling icon may be removed. In some embodiments, the blue version of the Wi-Fi calling icon or its white version may not be displayed if any step fails during the registration process. In the event of any error message other than a REG99 error, a red icon may appear on the status bar to indicate the error status of the Wi-Fi call. In some embodiments, when the user equipment is in a Wi-Fi call, the Wi-Fi call icon may change to a call state. In some embodiments, the status of the Wi-Fi call may be part of the notification window. When the user equipment is successfully registered on the IMS network (eg SIP IMS network), the notification window may have a Wi-Fi call ready indicator. In some embodiments, when a registration error is encountered, the notification window may display a corresponding error code. The error may be removed once registration is successful or when Wi-Fi is disabled. The text of the error message can be provided by the service provider.

In some embodiments, a user device may include a Wi-Fi calling menu to allow the user to control Wi-Fi calling settings. In some embodiments, disabling the Wi-Fi calling functionality may change the connection settings of the user device to cellular-only mode. The default settings can be set to enable Wi-Fi calling on first boot. Provides Wi-Fi calling status to reflect the current IMS registration status of the user device. In some embodiments, a user device can occupy multiple states, including but not limited to: (1) disabled (when Wi-Fi calling is off); (2) enabled (when the user device is registering with the service provider's network for During a Wi-Fi call; (3) error code (when a registration error is encountered); (4) poor Wi-Fi signal (when Wi-Fi RSSI does not meet the roaming threshold); (5) your The connection preference is cellular preferred (when the cellular preferred connection preference is selected and the cellular network is available); (6) call ready (when the user device is successfully registered to the service provider's network); (7) not connected to Wi-Fi (when Wi-Fi calling is on and Wi-Fi is on but not connected to a Wi-Fi network); (8) Wi-Fi off (when Wi-Fi calling is on but Wi-Fi is off); and (9) Airplane mode is on (Wi-Fi is enabled when the user device is in airplane mode.) In some embodiments, the following options may be provided for Wi-Fi calling. The first option is Connection Preferences, which provides options to change the connection mode over Wi-Fi. There may be several modes available such as Wi-Fi preferred, Wi-Fi only and Cellular preferred. Each mode may have a short user friendly description and the text to be displayed may be provided by the service provider. The second option Yes help. This can include Wi-Fi calling tutorials.

According to the present disclosure, a user device can clearly mark a call made on Wi-Fi or mark a call made on Wi-Fi through a series of pop-up windows, prompt boxes and drop-down messages. In some embodiments, when Wi-Fi calling is active and registered, the call button in the user device's dialer may change from a standard call button to a Wi-Fi calling icon. In some embodiments, when Wi-Fi calling is active and registered and the user enters the dialer, an overarching message may appear at the top of the screen for a period of time, such as 5 seconds, to indicate, for example, "The call will be made via Wi-Fi Fi carried out". In some embodiments, the user device may display a popup message if the user enters the dialer and attempts to place a call when Wi-Fi calling is inactive and there is no cellular coverage. When the user presses the send button, the user can receive a popup that says, for example, "No cellular network available; connect to available Wi-Fi to make the call." In some embodiments, when Wi-Fi calling is inactive and there is no cellular coverage, the user device may display a pop-up message if the user enters the messaging application and attempts to send a message via SMS or MMS. When the user presses the send button, the user can receive a popup that says, for example, "No cellular network available; connect to available Wi-Fi to send the message." In some embodiments, the user device may display a drop-down message if the user enters the dialer and attempts to place a call when Wi-Fi calling is inactive and there is no cellular coverage. A drop-down message may display, for example, "Connect to Wi-Fi to make a call." In some embodiments, when the Wi-Fi calling is inactive and there is no cellular coverage, if the user enters the messaging application and attempts to send a message, the user device may display a drop-down message. A drop-down message may display, for example, "Connect to Wi-Fi to send messages."

In some embodiments, the user equipment may maintain a minimum Mean Opinion Score (MOS) score, eg, 3.2, in an outdoor environment without Bluetooth. In some embodiments, the user equipment may maintain a minimum MOS score, eg, 3.2, in an outdoor environment when paired and connected to a Bluetooth headset. In some embodiments, the Engineering screen may allow the option to manually enter the IP address and/or Fully Qualified Domain Name (FQDN) for the Session Border Controller (SB)/ePDG and, if desired, allow the DNS lookup mechanism to be disabled. In some embodiments, the engineering screen may provide the ability to enable/disable Transport Layer Security (TLS) encryption or enable/disable null encryption for enabling ePDG devices. In some embodiments, the engineering screen may provide the ability to enable SIP messages for log capture and troubleshooting. In some embodiments, the engineering screen may allow configuration of summary accounts for authentication, such as usernames and passwords.

Wi-Fi statistics may be provided or utilized to better understand the basic performance and usage of the currently unavailable services outlined above. Wi-Fi calling metrics can be collected for analysis and can include metrics such as successful registration, deregistration, unsuccessful registration and reason codes (error codes), call setup (may include information about call direction), call termination (may include information about information on whether the termination was normal or abnormal, and if abnormal the reason code for the termination), and message sending/receiving (which may include information about the type of message, such as SMS or MMS, and the direction of the message). In some embodiments, the user equipment may broadcast an intent for the parameters described in Table 3 below. Metrics can be broadcast on creation.

table 3

WI-FI calling using Evolved Packet Data Gateway

Fig. 4 shows an exemplary decision process 400 for a user equipment to determine whether to access a visited ePDG or a home ePDG according to the present disclosure. At 410, the user equipment determines whether any LTE coverage is available. At 420, the user equipment determines whether data roaming is available. At 430, the user equipment determines whether the VPLMN is available. At 440, the user equipment determines whether the DNS query to the VePDG was successful. At 450, the user equipment connects to the VePDG after determining that LTE coverage is available, data roaming is available, VPLMN is available and the DNS query to the VePDG is successful. At 460, the user equipment connects to the HePDG after it determines that no LTE coverage is available, no data roaming is available, no VPLMN is available, or DNS queries to the VePDG were unsuccessful.

In some embodiments, the user equipment may support a static IP address and a static FQDN for the home ePDG. In some embodiments, the user equipment may support FQDN construction for ePDG selection according to 3GPP TS 23.003.

Regarding tunnel establishment and user authentication, the user equipment ePDG function may use IKEv2, as specified in RFC5996, to establish IPSec security associations. In some embodiments, the user equipment ePDG function may follow tunnel full authentication and authorization as defined in 3GPP TS 33.402. In some embodiments, the user device may store the root certificate for a given service provider in the device repository for authentication. In some embodiments, the user equipment may be configured to establish an IPSec tunnel for the IMS APN. For example, all IMS-associated traffic can be carried over the IMS PDN IPSec tunnel. In some embodiments, the user equipment may support new IKEv2 attributes that allow IPv4 and/or IPv6 address interchange for Proxy-Call Session Control Function (P-CSCF) functions. In some embodiments, user equipment may support multiple encryption and integrity algorithms for IKEv2 headers and payloads. For example, a user device may support Advanced Encryption Standard (AES), Data Encryption Standard (DES), Triple DES, Cipher Block Chaining (CBC) and derivatives thereof for IKE encryption, IKE integrity, ESP encryption, and ESP integrity. In some embodiments, the user equipment may support multiple PLMNs in the security certificate. For example, the user equipment may be configured to decode and translate multiple PLMNs from the network and construct the correct FQDN and authenticate the user equipment with corresponding security credentials.

Regarding Dead Peer Detection (DPD), in some embodiments the user equipment may be configured to respond to the DPD IKE_in_Req with an IKE_info_Resp. In some embodiments, user equipment may be configured to author keep-alive messages to maintain the validity of the IPSec tunnel.

With regard to rekeying IKE-SA and IPSec-SA, in some embodiments user equipment may support IKE-SA rekeying procedures, eg, to initiate and respond. In some embodiments, the user equipment may support IPSec-SA key update procedures, eg, to initiate and respond.

With regard to disconnection, in some embodiments the user equipment may support multiple disconnection procedures regardless of where the request originates from, for example from the user equipment, ePDG and/or PDN gateway.

Regarding session continuity and handover, in some embodiments user equipment may be configured to enable session continuity from LTE to Wi-Fi and from Wi-Fi to LTE. In some embodiments, once the hand-in to Wi-Fi procedure is triggered, the user equipment may ignore any single radio voice call continuity (SRVCC) event from the eNodeB. For example, when a user equipment has established a VoLTE call over LTE, the UE may receive a request for SRVCC for the VoLTE call when it switches the call to Wi-Fi. In this case, when the UE has triggered the hand-in procedure (for example, from LTE to Wi-Fi), the UE may ignore the message requesting SR-VCC on the LTE side. In some embodiments, the handover request can be used for IPv4 support when the user equipment has one IPv4 bearer or flow. For example, when the user equipment is in LTE mode and has an IPv4 bearer, the request to switch to Wi-Fi can be used for IPv4 support. When the user equipment is in Wi-Fi mode and has an IPv4 flow, the request to hand off LTE can be used for IPv4 support. In some embodiments, the handover request can be used for IPv6 support when the user equipment has one IPv6 bearer or flow. For example, when the user equipment is in LTE mode and has an IPv6 bearer, the request to switch to Wi-Fi can be used for IPv6 support. When the user equipment is in Wi-Fi mode and has an IPv6 flow, the request to hand off LTE can be used for IPv6 support. If there are two IP bearers, such as IPv4 and IPv6, the user equipment can perform two PDN connection handover requests for the two IP types. If there is dual-stack bearer activity, the user equipment may perform a PDN connection handover request with IPv4 and IPv6 support.

Regarding the IMS service over ePDG, in some embodiments, the user equipment may be configured to discover the P-CSCF address through the IKEv2 header according to the IETF standard.

With regard to voice calls, in some embodiments user equipment may be configured to make or receive voice calls only over an IMS network with Wi-Fi access. For example, a user equipment may be configured to register with an IMS network and set up and receive voice calls in the same manner regardless of the presence of any 3GPP RAT. In some embodiments, the user equipment may support seamless transition of voice calls from LTE to Wi-Fi and from Wi-Fi to LTE over IMS. In some embodiments, user equipment may conform to a predetermined set of user interface and configuration option requirements. In some embodiments, user equipment may conform to a predetermined set of emergency call handling requirements.

With regard to Rich Communication Services (RCS), in some embodiments user equipment may be configured to route some or all RCS signaling and media traffic through the IMS PDN IPSec tunnel. In some embodiments, the user equipment may be configured to establish a PDN IPSec tunnel and route all traffic through the PDN IPSec tunnel. In some embodiments, in the home network, the user equipment may use IPv6 for the PDN connection, and in the visited network, the user equipment may use IPv4 for the PDN connection.

Regarding IR.94 video calls, in some embodiments, user equipment may route IR.94 video call signals and media traffic through the IMS PDN IPSec tunnel. In some embodiments, user equipment may be configured to transmit IR.94 video calls between LTE and Wi-Fi with session continuity. As with voice call continuity, the UE ePDG client is capable of handling IR.94 video calls between LTE and Wi-Fi with session continuity.

Regarding handover criteria, such as RSSI boundaries for ePDG functionality, "Wi-Fi preferred" or "Wi-Fi only" settings in the UE and Wi-Fi+LTE coverage available, as long as the RSSI is above a predetermined threshold (e.g., -75dBm), the user equipment can establish and maintain an IMS PDN connection over Wi-Fi. If Wi-Fi or LTE coverage is available to the user equipment, the user equipment may establish and maintain an IMS PDN connection on the available RAT as long as RAT access is maintained, regardless of the coverage signal level. In some embodiments, the predetermined threshold for RSSI levels for Wi-Fi roam-in and hand-in is -75dBm.

Regarding the handover decision algorithm, in some embodiments the user equipment may consider multiple metrics in its handover decision process to maximize the handover success rate between LTE and Wi-Fi. Metrics considered may include, but are not limited to, RSSI, downlink and uplink packet error rate (PER) (eg, RTP PER), RTCP information, and LTE RSRP and RSRQ information.

Regarding prolonged silence of an ongoing voice session, in case no RTP packet is received for a given duration (e.g. 5 seconds), the UE may send a signal (ping) to the P-CSCF to determine the access link is still up and running. In some embodiments, the user device may terminate the call and record it as a dropped call if no reply is received from the server after signaling the server a predetermined number of times (eg, 5). In some embodiments, if the user equipment receives part of the signaling response, the user equipment may trigger a handover procedure and attempt to transfer the call to another RAT.

This disclosure also describes the need for traffic management in the user equipment through the connection to the ePDG to ensure interoperability with the service provider's network and to define new services and tunneling mechanisms, an exemplary embodiment of which is shown in Figure 5 below - described in Figure 12.

FIG. 5 shows an exemplary scenario 500 of a tunneling mechanism for VoLTE user equipment according to the present disclosure. Exemplary scenario 500 includes IMS network 502, P-GW 510, Serving Gateway (S-GW) 520, ePDG 530, Evolved Universal Terrestrial Radio Access Network (EUTRAN) 504, Internet Service Provider (ISP) network 508, Wi-Fi Access point 570 and user equipment 580. User device 580 may be an implementation of exemplary device 190 or user device 210 . Referring to FIG. 5, in an exemplary scenario 500, there is LTE coverage but no Wi-Fi coverage. The first traffic 550 includes MMS, XML Configuration Access Protocol (XCAP), visual voicemail, over-the-air (OTA) and OTT traffic between the user equipment 580 and the P-GW 510 can pass through the EUTRAN 504 and the S-GW 520 routing. SIP-IMS traffic 540 between user equipment 580 and P-GW 510 may also be routed through EUTRAN 504 and S-GW 520 .

FIG. 6 shows an exemplary scenario 600 of a tunneling mechanism for VoLTE user equipment according to the present disclosure. Exemplary scenario 600 includes IMS network 602, P-GW 610, S-GW 620, ePDG 630, network 604 (which may include EUTRAN, Universal Terrestrial Radio Access Network (UTRAN), and/or GSM EDGE Radio Access Network (GERAN) )), ISP network 608, Wi-Fi access point 670 and user equipment 680. User device 680 may be an implementation of exemplary device 190 or user device 210 . Referring to FIG. 6, in an exemplary scenario 600, there is Wi-Fi coverage, but no LTE coverage. First traffic 650 including MMS, XCAP, visual voicemail, and OTA between user equipment 680 and P-GW 610 may be routed from Wi-Fi access point 670 to P-GW 610 via ePDG 630 . Similarly, SIP-IMS traffic 640 between user equipment 680 and P-GW 610 may also be routed from Wi-Fi access point 670 to P-GW 610 via ePDG 630 . OTT traffic 660 may be routed to ISP network 608 via Wi-Fi access point 670 .

FIG. 7 shows an exemplary scenario 700 of a tunneling mechanism for VoLTE user equipment according to the present disclosure. Exemplary scenario 700 includes IMS network 702 , P-GW 710 , S-GW 720 , ePDG 730 , EUTRAN 704 , ISP network 708 , Wi-Fi access point 770 and user equipment 780 . User device 780 may be an implementation of exemplary device 190 or user device 210 . Referring to FIG. 7, in an exemplary scenario 700, both LTE coverage and Wi-Fi coverage are available and user equipment 780 is in "cellular preferred" mode. The first traffic 750 includes MMS, XCAP, visual voicemail and OTA between user equipment 780 and P-GW 710 , which can be routed through EUTRAN 704 and S-GW 720 . Similarly, SIP-IMS traffic 740 between user equipment 780 and P-GW 710 may also be routed through EUTRAN 704 and S-GW 720 . OTT traffic 760 may be routed to ISP network 708 via Wi-Fi access point 770 .

FIG. 8 shows an exemplary scenario 800 of a tunneling mechanism for VoLTE user equipment according to the present disclosure. Exemplary scenario 800 includes IMS network 802 , P-GW 810 , S-GW 820 , ePDG 830 , EUTRAN 804 , ISP network 808 , Wi-Fi access point 870 , and user equipment 880 . User equipment 880 may be an implementation of exemplary equipment 190 or user equipment 210 . Referring to FIG. 8, in an exemplary scenario 800, both LTE coverage and Wi-Fi coverage are available, and user equipment 880 is in "Wi-Fi preferred" mode. The first traffic 850 includes MMS, XCAP, visual voicemail and OTA between user equipment 880 and P-GW 810 , which can be routed from Wi-Fi access point 870 to P-GW 810 via ePDG 830 . Similarly, SIP-IMS traffic 840 between user equipment 880 and P-GW 810 may also be routed from Wi-Fi access point 870 to P-GW 810 via ePDG 830 . OTT traffic 860 may be routed to ISP network 808 via Wi-Fi access point 870 . Additionally, keep-alive traffic 865 between user equipment 880 and P-GW 810 may be routed through EUTRAN 804 and S-GW 820 .

FIG. 9 shows an exemplary scenario 900 of a tunneling mechanism for VoLTE user equipment according to the present disclosure. Exemplary scenario 900 includes IMS network 902 , P-GW 910 , S-GW 920 , ePDG 930 , UTRAN 904 , ISP network 908 , Wi-Fi access point 970 and user equipment 980 . User equipment 980 may be an implementation of exemplary equipment 190 or user equipment 210 . Referring to FIG. 9, in an exemplary scenario 900, both UTRAN coverage and Wi-Fi coverage are available. The first traffic 950 includes MMS, XCAP, visual voicemail, and OTA between user equipment 980 and P-GW 910 , which can be routed from Wi-Fi access point 970 to P-GW 910 via ePDG 930 . Similarly, SIP-IMS traffic 940 between user equipment 980 and P-GW 910 may also be routed from Wi-Fi access point 970 to P-GW 910 via ePDG 930 . OTT traffic 960 may be routed to ISP network 908 via Wi-Fi access point 970 . Wireless communication between user equipment 980 and UTRAN 904 may be established as long as UTRAN coverage exists, but idle and additional.

FIG. 10 shows an exemplary scenario 1000 of a tunneling mechanism for VoLTE user equipment according to the present disclosure. Exemplary scenario 1000 includes IMS network 1002 , P-GW 1010 , S-GW 1020 , ePDG 1030 , UTRAN 1004 , ISP network 1008 , Wi-Fi access point 1070 and user equipment 1080 . User device 1080 may be an implementation of exemplary device 190 or user device 210 . Referring to Figure 10, in an exemplary scenario 1000, UTRAN coverage is available, but Wi-Fi coverage is not available (or Wi-Fi is not turned on at user equipment 1080). The first traffic 1050 includes MMS, XCAP, visual voicemail, OTA and OTT between user equipment 1080 and P-GW 1010 , which can be routed through UTRAN 1004 and S-GW 1020 . Similarly, SIP-IMS traffic 1040 between user equipment 1080 and P-GW 1010 may also be routed through UTRAN 1004 and S-GW 1020 . Voice calls can be made over UTRAN 1004.

FIG. 11 shows an exemplary scenario 1100 of a tunneling mechanism for a VoLTE user equipment according to the present disclosure. Exemplary scenario 1100 includes IMS network 1102 , P-GW 1110 , S-GW 1120 , ePDG 1130 , GERAN 1104 , ISP network 1108 , Wi-Fi access point 1170 , and user equipment 980 . User device 1180 may be an implementation of exemplary device 190 or user device 210 . Referring to FIG. 11, in an exemplary scenario 1100, both GERAN coverage and Wi-Fi coverage are available. First traffic 1150 includes MMS, XCAP, visual voicemail, and OTA between user equipment 1180 and P-GW 1110 , which may be routed from Wi-Fi access point 1170 to P-GW 1110 via ePDG 1130 . Similarly, SIP-IMS traffic 1140 between user equipment 1180 and P-GW 1110 may also be routed from Wi-Fi access point 1170 to P-GW 1110 via ePDG 1130 . OTT traffic 1160 may be routed to ISP network 1108 via Wi-Fi access point 1170 . Wireless communication between user equipment 1180 and GERAN 904 may be established as long as GERAN coverage exists, but idle and additional.

FIG. 12 shows an exemplary scenario 1200 of a tunneling mechanism for a VoLTE user equipment according to the present disclosure. Exemplary scenario 1200 includes IMS network 1202 , P-GW 1210 , S-GW 1220 , ePDG 1230 , GERAN 1204 , ISP network 1208 , Wi-Fi access point 1270 and user equipment 1280 . User equipment 1280 may be an implementation of exemplary equipment 190 or user equipment 210 . Referring to FIG. 12, in an exemplary scenario 1200, GERAN coverage is available, but Wi-Fi coverage is not available (or Wi-Fi is not turned on at user device 1280). First traffic 1250 includes MMS, XCAP, visual voicemail, OTA and OTT between user equipment 1280 and P-GW 1210 , which can be routed through GERAN 1204 and S-GW 1220 . Voice calls and messaging can be made over GERAN 1204.

Deploying the ePDG is to provide a 3GPP standardized gateway for untrusted non-3GPP access (eg Wi-Fi) to access the service provider's Evolved Packet Core (EPC). This disclosure focuses on session management for voice, messaging and video traffic for IP services. For purposes of illustration and without limiting the scope of the present disclosure, a list of exemplary use cases for user equipment is described below. Exemplary use cases may be implemented by applications built on top of the ePDG Tunneling and Connection Engine. "User equipment" in the following description may indicate exemplary equipment 190, user equipment 210, user equipment 580, user equipment 680, user equipment 780, user equipment 880, user equipment 980, user equipment 1080, user equipment 1180, and/or or User Equipment 1280, as described above. In addition, the "user equipment" in the following description may be configured to implement the embodiments related to FIGS. 1-12 .

In one exemplary use case, the Wi-Fi radio of the user device is turned off and Wi-Fi calling is enabled or disabled, but not in "Wi-Fi only" mode. Additionally, video calling is disabled and the user equipment is connected to the radio access network (RAN). A user of a user equipment may use the user equipment to make Mobile Originated (MO) and/or Mobile Terminated (MT) voice calls and messaging, such as SMS and/or MMS, over the RAN. A user may also use the user equipment to perform data browsing and/or data streaming activities over the RAN.

In one exemplary use case, the Wi-Fi radio of the user device is turned off and Wi-Fi calling is enabled or disabled, but not in "Wi-Fi only" mode. Additionally, video calling is enabled and user equipment is connected to the RAN. A user of a user equipment may use the user equipment to make MO/MT voice calls and messaging, such as SMS and/or MMS, over the RAN. A user may also use the user equipment to perform data browsing and/or data streaming activities over the RAN. The user can further use the user equipment to make an MO/MT video call through the RAN.

In one exemplary use case, the user device's Wi-Fi radio is on but not connected, and Wi-Fi calling is enabled or disabled, but not in "Wi-Fi only" mode. Additionally, video calling is disabled and the user equipment is connected to the RAN. A user of a user equipment may use the user equipment to make MO/MT voice calls and messaging, such as SMS and/or MMS, over the RAN. A user may also use the user equipment to perform data browsing and/or data streaming activities over the RAN.

In one exemplary use case, the user device's Wi-Fi radio is on but not connected, and Wi-Fi calling is enabled or disabled, but not in "Wi-Fi only" mode. Additionally, video calling is enabled and user equipment is connected to the RAN. A user of a user equipment may use the user equipment to make MO/MT voice calls and messaging, such as SMS and/or MMS, over the RAN. A user may also use the user equipment to perform data browsing and/or data streaming activities over the RAN. The user can further use the user equipment to make an MO/MT video call through the RAN.

In one exemplary use case, the user device's Wi-Fi radio is turned on and connected, and Wi-Fi calling is disabled. Additionally, video calling is disabled and the user equipment is connected to the RAN. A user of a user equipment may use the user equipment to make MO/MT voice calls and messaging, such as SMS and/or MMS, over the RAN. The user may also use the user device to perform data browsing and/or data streaming activities over Wi-Fi.

In one exemplary use case, the user device's Wi-Fi radio is turned on and connected, and Wi-Fi calling is disabled. Additionally, video calling is enabled and the user equipment is connected to a non-LTE RAN. A user of a user equipment may use the user equipment to make MO/MT voice calls and messaging, such as SMS and/or MMS, over the RAN. A user may also use the user equipment to perform data browsing and/or data streaming activities over the RAN. The user can further use the user equipment to make MO/MT video calls through Wi-Fi.

In one exemplary use case, the user device's Wi-Fi radio is turned on and connected, and Wi-Fi calling is enabled (either in "Wi-Fi Preferred" mode or "Wi-Fi Only" mode) and connected. Additionally, video calling is disabled and the user equipment is disconnected from the RAN, the baseband radio may be turned off since Wi-Fi calling is active. A user of the user equipment may use the user equipment to make MO/MT voice calls and messaging, such as SMS and/or MMS, using Wi-Fi calling through the ePDG. The user may also use the user device to perform data browsing and/or data streaming activities over Wi-Fi.

In one exemplary use case, the user device's Wi-Fi radio is turned on and connected, and Wi-Fi calling is enabled (either in "Wi-Fi Preferred" mode or "Wi-Fi Only" mode) and connected. Additionally, video calling is enabled and the user equipment is disconnected from the RAN, the baseband radio may be turned off since the Wi-Fi calling is active. A user of the user equipment may use the user equipment to make MO/MT voice calls and messaging, such as SMS and/or MMS, using Wi-Fi calling through the ePDG. The user may also use the user device to perform data browsing and/or data streaming activities over Wi-Fi. The user can further use the user equipment to make MO/MT video calls through Wi-Fi.

In an exemplary ePDG handover use case for handover to a 3GPP radio access technology (RAT), the user equipment may initiate a handover request if a number of conditions are met. Wi-Fi calling preference needs to be set to "Wi-Fi Preferred" or "Cellular Preferred". Any handover condition from serving RAT or source RAT to new RAT or target RAT needs to be fulfilled. The condition may be based on RAT signal strength (eg, RSSI/RSRP0, signal quality (eg, downlink PER/RSRQ)) and RTCP information for uplink PER information. Furthermore, the RAN network is a home public land mobile network (PLMN).

In some embodiments, if the Wi-Fi calling preference is set to "Wi-Fi only" mode, the user device may not initiate the handoff.

In some embodiments, when the user equipment is in a Wi-Fi call and detects that the uplink data packet loss exceeds a predetermined threshold, the network may initiate a handover.

In some embodiments, if the target RAN for handover is not the roaming network of a specific service provider, the user equipment may not initiate a handover request.

In some embodiments, the service provider's network may not initiate any handover requests and may reject any handover requests from user equipment with target RAN as roaming Mobile Country Code (MCC) and Mobile Network Code (MNC).

In one exemplary use case, the user device's Wi-Fi radio is turned on and connected, and Wi-Fi calling is enabled (in "Wi-Fi preferred" mode) and connected. Additionally, video calling is disabled and the user equipment is disconnected from the RAN, the baseband radio may be turned off since Wi-Fi calling is active. The user of the UE can use the UE to make a voice call over the ePDG, then move out of Wi-Fi coverage and continue the call seamlessly over the RAN. After leaving Wi-Fi coverage, the user can resume all other browsing activities over the RAN, and the transition may not be seamless.

In one exemplary use case, the user device's Wi-Fi radio is turned on and connected, and Wi-Fi calling is enabled (in "Wi-Fi preferred" mode) and connected. Additionally, video calling is enabled and connected, and the user equipment is disconnected from the RAN, the baseband radio may be turned off since the Wi-Fi calling is active. The user of the UE can use the UE to make a voice call over the ePDG, then move out of Wi-Fi coverage and continue the call seamlessly over the RAN. A user can make a video call over Wi-Fi using a user device, then move out of Wi-Fi coverage and seamlessly continue the call over the RAN. After leaving Wi-Fi coverage, the user can resume all other browsing activities over the RAN, and the transition may not be seamless.

In one exemplary use case, the user device's Wi-Fi radio is turned on and connected, and Wi-Fi calling is enabled (in "Wi-Fi only" mode) and connected. Additionally, video calling is enabled and connected, and the user device is disconnected from the RAN, the baseband radio may be turned off because Wi-Fi calling is active, and may remain turned off because "Wi-Fi only" mode is selected. A user of a UE can use the UE to make a voice call over the ePDG and then move out of Wi-Fi coverage, causing the call to drop. A user could make a video call over Wi-Fi using a user device and then move out of Wi-Fi coverage, causing the call to drop. After leaving Wi-Fi coverage, users may not be able to perform any browsing activities.

In one exemplary use case, the user device's Wi-Fi radio is turned on and connected, and Wi-Fi calling is enabled (in "Wi-Fi only" mode) and connected. Additionally, video calling is disabled and the user device is disconnected from the RAN, the baseband radio may be turned off since Wi-Fi calling is active, and may remain off because the "Wi-Fi only" mode is selected. A user of a UE can use the UE to make a voice call over the ePDG and then move out of Wi-Fi coverage, causing the call to drop. After leaving Wi-Fi coverage, users may not be able to perform any browsing activities.

In one exemplary use case, the user device's Wi-Fi radio is on and connected, and Wi-Fi calling is enabled (in "cellular preferred" mode) and not connected. Also, video calling is enabled and user equipment is connected to the RAN, Wi-Fi remains off as cellular coverage is available. The user of the UE can use the UE to make a voice call over the RAN and then move out of Wi-Fi coverage with no impact on the call. A user can make a video call over Wi-Fi using a user device and move out of Wi-Fi coverage, seamlessly continuing the call over the RAN. After leaving Wi-Fi coverage, the user is able to resume all other browsing activities over the RAN, and the transition may not be seamless.

In an exemplary ePDG handover use case for handover to Wi-Fi, the user equipment may initiate a handover request if a number of conditions are met. The Wi-Fi calling preference needs to be set to "Wi-Fi Preferred" and the Wi-Fi RSSI is above a predetermined threshold (eg -75dBm). If the Wi-Fi calling preference is set to "cellular preferred" mode, the user equipment may not initiate a handover. If the current RAN is roaming, the user equipment may not initiate a handover request (which is user configurable), and the call may continue on the roaming network until the call is dropped.

In one exemplary use case, the user device's Wi-Fi radio is on and not connected, and Wi-Fi calling is enabled (in "Wi-Fi preferred" mode) and not connected. Additionally, video calling is disabled and the user equipment is connected to the RAN. The user of the UE can use the UE to make a voice call over the RAN, then move into the saved Wi-Fi coverage and continue the call seamlessly over Wi-Fi Calling via the ePDG. After entering saved Wi-Fi coverage, the user is able to resume all other browsing activities over Wi-Fi, and the transition may not be seamless.

In one exemplary use case, the user device's Wi-Fi radio is on and not connected, and Wi-Fi calling is enabled (in "Wi-Fi preferred" mode) and not connected. Additionally, video calling is enabled and connected, and the user equipment is connected to the RAN. The user of the UE can use the UE to make a voice call over the RAN, then move into the saved Wi-Fi coverage and continue the call seamlessly over Wi-Fi Calling via the ePDG. A user can use a user device to place a video call over the RAN and move to saved Wi-Fi coverage, seamlessly continuing the call over Wi-Fi. After entering saved Wi-Fi coverage, the user can resume all other browsing activities over Wi-Fi, and the transition can be seamless.

In one exemplary use case, the user device's Wi-Fi radio is on and not connected, and Wi-Fi calling is enabled (in "Wi-Fi only" mode) and not connected. Additionally, video calling is enabled and not connected, and the user device is disconnected from the RAN, the baseband radio may be off since Wi-Fi calling is active, and may remain off because the "Wi-Fi only" mode is selected. The user of the UE can connect to the Wi-Fi call through the ePDG by using the UE to make a voice call after entering saved Wi-Fi coverage or manually connecting to a Wi-Fi network. Once in saved Wi-Fi coverage or manually connected to a Wi-Fi network, users can make video calls. Once in saved Wi-Fi coverage or manually connected to a Wi-Fi network, the user can perform all other browsing activities.

In one exemplary use case, the user device's Wi-Fi radio is on and not connected, and Wi-Fi calling is enabled (in "Wi-Fi only" mode) and not connected. Additionally, video calling is disabled and the user device is disconnected from the RAN, the baseband radio may be turned off since Wi-Fi calling is active, and may remain off because the "Wi-Fi only" mode is selected. The user of the UE can connect to the Wi-Fi call through the ePDG by using the UE to make a voice call after entering saved Wi-Fi coverage or manually connecting to a Wi-Fi network. Once in saved Wi-Fi coverage or manually connected to a Wi-Fi network, the user can perform all other browsing activities.

In one exemplary use case, the user device's Wi-Fi radio is on and not connected, and Wi-Fi calling is enabled (in "cellular preferred" mode) and not connected. Also, video calling is enabled and user equipment is connected to the RAN, Wi-Fi calling can remain off as cellular coverage is available. The user of the user device can use the user device to make a voice call over the RAN, and then can enter saved Wi-Fi coverage or manually connect to the Wi-Fi network, and the call can continue through the RAN because the Wi-Fi call is not registered. Users can place a video call over the RAN and then can tap into saved Wi-Fi coverage or manually connect to a Wi-Fi network to seamlessly continue the call over Wi-Fi. After entering saved Wi-Fi coverage or manually connecting to a Wi-Fi network, the user can resume all other browsing activities over Wi-Fi using the user device, and the transition may not be seamless.

A description of several exemplary parental control use cases for baseline RAN based parental control is provided below.

In one exemplary use case, the Wi-Fi radio of the user device is turned off and Wi-Fi calling is enabled or disabled. Additionally, video calling is disabled and the user equipment is connected to the RAN. A user of a user equipment may use the user equipment to make MO/MT voice calls and SMS/MMS messaging over the RAN and may not be based on the destination number, time of day, or time of day detailed in the user profile associated with the user equipment. ) and parental control standards to perform certain MO/MT calling and SMS/MMS activities. The User may perform data browsing and/or data streaming activities over the RAN using the User Equipment and may not have access to certain activities based on time of day, keywords and parental control criteria detailed in the User Profile.

In one exemplary use case, the Wi-Fi radio of the user device is turned off and Wi-Fi calling is enabled or disabled. Additionally, video calling is disabled and the user equipment is connected to the RAN. A user of a user device may use the user device to make MO/MT voice calls, SMS/MMS messaging over the RAN and may not be based on destination number, time of day and parental control criteria detailed in the user profile associated with the user device to perform certain MO/MT calls and SMS/MMS activities. The User may perform data browsing and/or data streaming activities over the RAN using the User Equipment and may not have access to certain activities based on time of day, keywords and parental control criteria detailed in the User Profile.

In one exemplary use case, the user device's Wi-Fi radio is turned off, and Wi-Fi calling is enabled or disabled, but not in "Wi-Fi only" mode. Additionally, video calling is enabled and user equipment is connected to the RAN. A user of a user device may use the user device to make MO/MT voice calls, SMS/MMS messaging over the RAN and may not be based on destination number, time of day and parental control criteria detailed in the user profile associated with the user device to perform certain MO/MT calls and SMS/MMS activities. A user may perform data browsing and/or data streaming activities over the RAN using a user device, and certain activities may not be accessible based on time of day, keywords, and parental control criteria detailed in the user profile. The user may also use the user equipment to make MO/MT video calls over the RAN and may not be able to perform certain MO/MT calling activities based on the destination number, time of day and parental control criteria detailed in the user profile.

In one exemplary use case, the user device's Wi-Fi radio is on and not connected, and Wi-Fi calling is enabled or disabled, but not in "Wi-Fi only" mode. Additionally, video calling is disabled and the user equipment is connected to the RAN. A user of a user device may use the user device to make MO/MT voice calls, SMS/MMS messaging over the RAN and may not be based on destination number, time of day and parental control criteria detailed in the user profile associated with the user device to perform certain MO/MT calls and SMS/MMS activities. A user may perform data browsing and/or data streaming activities over the RAN using a user device, and certain activities may not be accessible based on time of day, keywords, and parental control criteria detailed in the user profile.

A description of several exemplary parental control use cases for ePDG-based parental controls is provided below.

In one exemplary use case, the user device's Wi-Fi radio is turned on and connected, and Wi-Fi calling is disabled. Additionally, video calling is enabled and user equipment is connected to the RAN. A user of a user device may use the user device to make MO/MT voice calls, SMS/MMS messaging over the RAN and may not be based on destination number, time of day and parental control criteria detailed in the user profile associated with the user device to perform certain MO/MT calls and SMS/MMS activities. Users may perform data browsing and/or data streaming activities over Wi-Fi using User Devices and may not have access to certain activities based on time of day, keywords, and parental control criteria detailed in the User Profile. Users may also make MO/MT video calls over Wi-Fi using the User Device and may not be able to perform certain MO/MT calling activities based on the destination number, time of day, and parental control criteria detailed in the User Profile.

In one exemplary use case, the user device's Wi-Fi radio is turned on and connected, and Wi-Fi calling is enabled (either in "Wi-Fi Preferred" mode or "Wi-Fi Only" mode) and connected. Additionally, video calling is enabled and the user equipment is connected to the RAN, the baseband radio may be turned off since Wi-Fi calling is active. A user of a UE may use the UE to make MO/MT voice calls, SMS/MMS messaging using Wi-Fi calling via ePDG and may not be able to make calls based on the destination number detailed in the User Profile associated with the UE, Time and parental control criteria to perform certain MO/MT calls and SMS/MMS activities. Users may perform data browsing and/or data streaming activities over Wi-Fi using User Devices and may not have access to certain activities based on time of day, keywords, and parental control criteria detailed in the User Profile. The user may also make MO/MT video calls over Wi-Fi using the user device and may not be able to perform certain MO/MT calling activities based on the destination number, time of day, and parental control criteria detailed in the user profile.

Regardless of the use case, there are a number of requirements that need to be met in accordance with this disclosure, and are described below.

In terms of connectivity, the UE can maintain an attached state on LTE and have its 3GPP radio in sleep mode while the UE is wirelessly connected to the ePDG via Wi-Fi. In cases where only Wi-Fi coverage exists when the UE is turned on (e.g. no 3GPP RAT coverage exists), the UE can establish a data connection via Wi-Fi access and register to the IMS network via the ePDGIPSec tunnel via the IMS APN. Voice over Wi-Fi connection (VoWi-Fi). The user equipment may set the 3GPP radio to sleep mode and periodically search for the 3GPP RAT and PLMN.

Regarding 3GPP radio fallback to 3G or 2G RAT, when establishing an IMS PDN connection over Wi-Fi, the 3GPP radio of the user equipment can attach to the LTE network (but not UMTS or GSM). In cases where an IMS PDN connection is established over Wi-Fi and the 3GPP radio falls back from LTE to UMTS or GSM, the 3GPP radio of the user equipment can be decoupled from the UMTS and GSM RATs. It can stay in sleep mode and scan for LTE coverage. However, if an IMS PDN connection is established over LTE (in "Cellular Preferred" mode), the fallback mechanism on 3GPP radio for the user equipment can remain unchanged, as if ePDG functionality does not exist.

Regarding establishing an IP connection with the ePDG, the user equipment ePDG client may establish a secure IPSec tunnel using Internet Key Exchange (IKE) v2 with ePDG compliant with 3GPP TS 24.302. In some embodiments, user equipment may be configured to establish and maintain three or more packet data network (PDN) connections simultaneously. In some embodiments, the user equipment may be configured to form an IPSec connection to the ePDG over IPv4 and/or IPv6. In some embodiments, the user equipment may select the first PLMNid stored in the SIM card as the home PLMN reference.

Exemplary implementation

FIG. 13 illustrates an example device 1300 configured to implement embodiments of the present disclosure. Exemplary device 1300 may be the user equipment described above, a user terminal or a handset, which may be a mobile device such as a smart phone. The example device 1300 may perform various functions related to the techniques, methods, and systems described herein, including the example process 1400 described below. Exemplary device 1300 may be implemented as exemplary device 190, such as the user equipment described herein and in FIG. 1 and in FIGS. 2-12. In some embodiments, exemplary device 1300 may include at least those components shown in FIG. 13 , such as memory 1310 , one or more processors 1320 , and communication unit 1330 . Although memory 1310, one or more processors 1320, and communication unit 1330 are shown as discrete components separate from each other, in various embodiments of exemplary device 1300, some or all of memory 1310, one or more processors 1320 and communication unit 1330 may be integral parts of a single integrated circuit (IC), chip or chipset. In some embodiments, the communication unit 1330 may be an integral part of the one or more processors 1320, but they are shown in FIG. 13 as discrete components separated from each other. For simplicity, the description of one or more processors 1320 is provided below as if there was a single processor 1320 .

Memory 1310 may be configured to store data and one or more sets of processor-executable instructions. In the example shown in FIG. 13 , a memory 1310 may store therein an IMS stack 1340 and an ePDG module 1360 having an ePDG function employing connection management. IMS stack 1340 may be similar to IMS stack 120 of example device 190 , and ePDG module 1360 may be similar to ePDG module 122 of example device 190 . For example, ePDG module 1360 may include one or more processor-executable instructions that, once executed by processor 1320, allow processor 1320 to perform the operations of FIGS. 1-12 and 14 in accordance with the present disclosure. The communication unit 1330 may be configured to receive and transmit wireless signals conforming to various standards and protocols listed in this disclosure to make a Wi-Fi call using SIM IMS and ePDG. Processor 1320 may be coupled to memory 1310 and configured to access memory 1310 to execute one or more sets of processor-executable instructions, such as ePDG module 1360, to perform the operations described below.

In some embodiments, the processor 1320 may determine whether to connect to a first ePDG (e.g., Visited ePDG (VePDG)) or a second ePDG (e.g., Home ePDG (HePDG)) by performing the following operations: determine any LTE Whether coverage is available; determining whether data roaming is available; determining whether a Visited Public Land Mobile Network (VPLMN) is available; determining whether a DNS query to said first ePDG was successful; in response to determining that LTE coverage is available, determining that data roaming is available, determining A VPLMN is available and determining that the DNS query to the first ePDG successfully connects to the first ePDG; and in response to determining that no LTE coverage is available, determining that no data roaming is available, determining that no VPLMN is available, or determining that the DNS query to the first ePDG was unsuccessful Connect to the second ePDG.

In some embodiments, in response to determining that no LTE coverage is available, processor 1320 may connect to a Wi-Fi access point. In some embodiments, processor 1320 may register with an IMS network. In some embodiments, the processor 1320 can establish a data connection through a Wi-Fi access point. In some embodiments, the processor 1320 may establish Voice over Wi-Fi (VoWi-Fi) through a Wi-Fi access point.

In some embodiments, processor 1320 may be configured to further perform one or more operations, including: placing the 3rd Generation Partnership Project (3GPP) radio of the mobile device into sleep mode; periodically searching for 3GPP RAT and PLMN; enable voice calls through said Wi-Fi access point through said IMS network; enable IMS PDN IPSec tunnel; route RCS signaling and media traffic through IMS PDN IPSec tunnel; route video call signaling and media traffic through IMS PDN IPSec tunnel ; and initiating handover between LTE and Wi-Fi by considering one or more metrics. The metrics may include, for example, RSSI levels, downlink and uplink packet error rates, real-time transport protocol (RTP) control protocol (RTCP) information, and LTE Reference Signal Received Power (RSRP) and Reference Signal Received Quality ( RSRQ) information.

In some embodiments, where the IMS PDN connection is established over Wi-Fi and the mobile device's 3GPP radio falls back from LTE to a Universal Mobile Telecommunications System (UMTS) or Global System for Mobile Communications (GSM) radio RAT, the processor 1320 can detach the 3GPP radio from UMTS or GSM RAT, put the 3GPP radio in sleep mode, and scan for LTE coverage.

In some embodiments, when voice calls are enabled over the IMS network, the processor 1320 may be configured to provide seamless transition of voice calls from LTE to Wi-Fi and from Wi-Fi to LTE over the IMS network. In some embodiments, when the IMS PDN IPSec tunnel is enabled, the processor 1320 may be configured to maintain the IMS PDN IPSec tunnel over Wi-Fi when the RSSI level of the Wi-Fi signal is above a threshold (eg, -75dBm). In some embodiments, when routing video call signals through the IMS PDN IPSec tunnel, the processor 1320 may be configured to provide seamless transition of video calls from LTE to Wi-Fi and from Wi-Fi to LTE through the IMS PDN IPSec tunnel.

In some embodiments, when establishing an IPSec tunnel, the processor 1320 may be configured to perform one or more of the following operations, including: simultaneously establishing and maintaining three or more PDN connections; establishing an IPSec tunnel based on IPv4 and IPv6 IPSec tunneling; selecting a first PLMN of a plurality of PLMNs as a home PLMN, the identities of the plurality of PLMNs being stored in the mobile device; and supporting one or more static IPs for the second ePDG in response to connecting to said second ePDG address and one or more FQDNs.

FIG. 14 is a flowchart of an exemplary process 1400 according to the present disclosure. Exemplary process 1400 may represent one aspect implementing features of the various embodiments described above. Exemplary process 1400 may include one or more operations, actions, or functions as illustrated in one or more of blocks 1410 , 1420 , 1430 , 1440 , 1450 , and 1460 . Although shown as discrete blocks, various blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Example process 1400 may be implemented by example device 1300 (eg, one or more processors 1320 and its communication unit 1330). For purposes of illustration, the operations described below are performed by the exemplary device 1300 as a mobile device. The example process 1400 may begin at block 1410 .

Block 1410 (Determine Availability of LTE Coverage) may include the example device 1300 determining whether any Long Term Evolution (LTE) coverage is available. Block 1410 may be followed by block 1420 .

Block 1420 (Determine Availability of Data Roaming) may include the example device 1300 determining whether data roaming is available. Block 1420 may be followed by block 1430 .

Block 1430 (Determine Availability of VPLMN) may include the example device 1300 determining whether a VPLMN is available. Block 1430 may be followed by block 1440 .

Block 1440 (Determine Success of DNS Query to First ePDG) may include example device 1300 determining whether DNS query to first ePDG was successful. The first ePDG may be, for example, a Visited ePDG (VePDG). Block 1440 may be followed by block 1450 .

Block 1450 (Connect to First EPDG When LTE Coverage, Data Roaming, and VPLMN Available and DNS Query to First EPDG Successful) may include responding to determining that LTE coverage is available, determining that data roaming is available, determining that VPLMN is available, and determining access to the first EPDG. An ePDG's DNS query is successful, and exemplary device 1300 connects to the first ePDG. Block 1450 may be followed by block 1460 .

Block 1460 (Connect to second EPDG when LTE coverage, data roaming, or VPLMN is not available or DNS query to first EPDG is unsuccessful) may include responding to determining that no LTE coverage is available, determining that no data roaming is available, determining that there is no VPLMN Available or determined that the DNS query to the first ePDG was unsuccessful, the example device 1300 connects to the second ePDG. The second ePDG may be, for example, a Home ePDG (HePDG).

In some embodiments, example process 1400 may also include example device 1300 performing operations including: in response to determining that no LTE coverage is available, connecting to a Wi-Fi access point; registering with an IMS network; -Fi access point to establish data connection; and Wi-Fi access point to establish VoWi-Fi connection.

In some embodiments, registering with the IMS network may include the example device 1300 registering with the IMS network via the IMS APN through the ePDG IPSec tunnel.

In some embodiments, the example process 1400 may further include the example device 1300 performing operations including: placing the mobile device's 3GPP radio in sleep mode; and periodically searching for 3GPP RATs and PLMNs.

In some embodiments, the example process 1400 may further include the example device 1300 enabling a voice call over the Wi-Fi access point over the IMS network.

In some embodiments, the example process 1400 may include the example device 1300 providing seamless transition of voice calls from LTE to Wi-Fi and from Wi-Fi to LTE over the IMS network when voice calls are enabled over the IMS network.

In some embodiments, the example process 1400 may further include the example device 1300 performing operations including: enabling an IMS PDN IPSec tunnel; and routing RCS signaling and media traffic through the IMS PDN IPSec tunnel.

In some embodiments, when the IMS PDN IPSec tunnel is enabled, the example process 1400 can include the example device 1300 maintaining the IMS PDN IPSec tunnel over Wi-Fi when the RSSI level of the Wi-Fi signal is above a threshold.

In some embodiments, the threshold may be -75dBm.

In some embodiments, the example process 1400 may further include the example device 1300 performing operations including: enabling an IMS PDN IPSec tunnel; and routing video call signals and media traffic through the IMS PDN IPSec tunnel.

In some embodiments, when routing video call signals over an IMS PDN IPSec tunnel, the example process 1400 may include the example device 1300 providing LTE to Wi-Fi and Wi-Fi to LTE video calls over an IMS PDN IPSec tunnel seamless transition.

In some embodiments, when the IMS PDN IPSec tunnel is enabled, the example process 1400 can include the example device 1300 maintaining the IMS PDN IPSec tunnel over Wi-Fi when the RSSI level of the Wi-Fi signal is above a threshold.

In some embodiments, the threshold may be -75dBm.

In some embodiments, the example process 1400 may further include the example device 1300 initiating handover between LTE and Wi-Fi by considering one or more metrics including the following: RSSI level, downlink and uplink Link packet error rate, RTCP information, and LTE RSRP and RSRQ information.

In some embodiments, the example process 1400 may further include the example device 1300 performing operations including: when the IMS PDN connection is established over Wi-Fi and the mobile device's 3GPP radio falls back from LTE to UMTS or GSM radio RAT In the case of a 3GPP radio, detach the UMTS or GSM RAT; put the 3GPP radio in sleep mode; and search for LTE coverage.

In some embodiments, the example process 1400 can further include the example device 1300 establishing an IPSec tunnel through the ePDG application on the mobile device.

In some embodiments, when establishing an IPSec tunnel, the example process 1400 may include the example device 1300 performing one or more of the following operations, including establishing and maintaining three or more PDN connections simultaneously ; establish an IPSec tunnel based on IPv4 and IPv6; select a first PLMN among multiple PLMNs as a home PLMN, and the identifiers of multiple PLMNs are stored in the mobile device; and in response to connecting to the second ePDG, support for the second ePDG One or more static IP addresses and one or more FQDNs.

in conclusion

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.

Claims (10)

1. A method for Wi-Fi calling, comprising: determining by the mobile device whether any Long Term Evolution (LTE) coverage is available; determining, by the mobile device, whether data roaming is available; determining, by the mobile device, whether a visited public land mobile network (VPLMN) is available; determining, by the mobile device, whether a domain name server (DNS) query to a first evolved packet data gateway (ePDG) was successful; connecting to the first ePDG in response to determining that LTE coverage is available, determining that data roaming is available, determining that a VPLMN is available, and determining that a DNS query to the first ePDG was successful; and Connecting to the second ePDG in response to determining that no LTE coverage is available, determining that no data roaming is available, determining that no VPLMN is available, or determining that a DNS query to the first PDG was unsuccessful. 2. The method of claim 1, further comprising: Responsive to determining that no LTE coverage is available, connecting to a Wi-Fi access point; Register with the Internet Protocol (IP) Multimedia Subsystem (IMS) network; establishing a data connection through the Wi-Fi access point; and A Voice over Wi-Fi (VoWiFi) connection is established through the Wi-Fi access point. 3. The method of claim 2, further comprising: placing a 3rd Generation Partnership Project (3GPP) radio of the mobile device in sleep mode; and Periodically search for 3GPP Radio Access Technologies (RATs) and Public Land Mobile Networks (PLMNs). 4. The method of claim 2, further comprising: A voice call is enabled over the IMS network via the Wi-Fi access point. 5. The method of claim 2, further comprising: Enable IMS Packet Data Network (PDN) Internet Protocol Security (IPSec) tunneling; and Rich Communication Services (RCS) signaling and media traffic is routed through the IMS PDN IPSec tunnel. 6. The method of claim 2, further comprising: Enable IMS Packet Data Network (PDN) Internet Protocol Security (IPSec) tunneling; and Routing video call signaling and media traffic through the IMS PDN IPSec tunnel. 7. The method of claim 1, further comprising: Handover between LTE and Wi-Fi is initiated by considering one or more metrics, including: Received Signal Strength Indication (RSSI) levels; downlink and uplink packet error rates; Real-time Transport Protocol (RTP) Control Protocol (RTCP) messages; and LTE Reference Signal Received Power (RSRP) and Reference Signal Received Quality (RSRQ) information. 8. The method of claim 1, further comprising: When the IMS Packet Data Network (PDN) connection is established over Wi-Fi and the 3rd Generation Partnership Project (3GPP) wireless of the mobile device falls back from LTE to Universal Mobile Telecommunications System (UMTS) or Global System for Mobile Communications (GSM ) in the case of a radio access technology (RAT), separating said 3GPP radio from UMTS or GSM RAT; putting the 3GPP radio into sleep mode; and Scan for LTE coverage. 9. The method of claim 1, further comprising: An Internet Protocol Security (IPSec) tunnel is established by the ePDG application on the mobile device. 10. The method of claim 9, wherein establishment of the IPSec tunnel includes performing one or more of operations, the operations comprising: Establish and maintain three or more packet data network (PDN) connections simultaneously; Establishing the IPSec tunnel based on Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6); selecting a first public land mobile network (PLMN) of a plurality of PLMNs, identities of which are stored in the mobile device, as a home PLMN; and In response to connecting to a second ePDG, one or more static IP addresses and one or more fully qualified domain names (FQDNs) for the second ePDG are supported.