VoLTE and VoWiFi Deployment: A Practical Guide for Mobile Operators

VoLTE and VoWiFi: how they relate

VoLTE (Voice over LTE) carries calls as IP packets over the LTE radio network.

VoWiFi (Wi-Fi Calling) carries the same calls over any Wi-Fi network the subscriber is connected to, whether a home router, an office access point or a public hotspot.

To the subscriber, both services look the same. They call from the built-in Phone app, the other party sees the same mobile number, and SMS, voicemail and supplementary services work the same way. This is possible because both services terminate on the same IMS core. Only the access path differs. VoLTE traffic reaches the IMS via the eNodeB, SGW and PGW, while VoWiFi traffic goes through an untrusted Wi-Fi network, the ePDG gateway and the same PGW.

For the operator, this means VoWiFi is not a separate voice network but a second route to the voice platform already built for VoLTE. That is why most operators plan both services as a single project, even if they launch them at different times. This is exactly what the MVNO Miatel did. At the request of corporate customers, the operator first launched VoLTE and then VoWiFi, and the experience of the first launch made the second one noticeably easier.

Network components

Before looking at the role of IMS, let’s see which components make up the network.

A VoWiFi call passes through several elements in sequence. The device connects to Wi-Fi and opens an IPsec tunnel to the ePDG using IKEv2. While the tunnel is being set up, the subscriber is authenticated with EAP-AKA using SIM card data, so no password or separate login is needed. The ePDG relays the authentication exchange to the 3GPP AAA server over the SWm interface, and the AAA server obtains authentication vectors from the HSS over SWx.

Once the tunnel is established, the ePDG connects it to the PGW over the S2b interface, and the PGW assigns the device an IP address in the IMS APN. The device then registers in the IMS just as it would over LTE. When a call starts, the IMS requests voice resources from the PCRF over the Rx interface, and the network allocates a dedicated QCI=1 bearer for the voice stream. The guaranteed bit rate applies on the segment from the ePDG to the PGW. On the Wi-Fi segment, quality depends on the network the subscriber is connected to.

If the operator considers a Wi-Fi network trusted, for example its own, the ePDG is not needed. The access network exchanges authentication data with the AAA over STa and connects to the PGW over S2a.

Figure 1 — VoLTE and VoWiFi architecture: the call path over LTE and over untrusted Wi-Fi

The role of IMS

IMS (IP Multimedia Subsystem) is the voice platform for VoWiFi/VoLTE. It is the layer that turns an IP connection into a telephone service. It uses SIP for call signaling and consists of several functions:

• P-CSCF is the first point of contact for the device; all of its SIP traffic passes through it.
• I-CSCF and S-CSCF route requests, register subscribers and apply service logic.
• HSS stores subscriber profiles and authentication data.
• The Telephony Application Server (TAS) provides call forwarding, call waiting, conferencing and other features.

IMS processing does not depend on the access network. A SIP registration that arrives over LTE and one that arrives through an IPsec tunnel from a café’s Wi-Fi are handled the same way, as long as both go through the PGW in the IMS APN. That is why a single IMS core serves both VoLTE and VoWiFi, and numbering, subscriber profiles and services are configured only once.

When a subscriber moves between LTE and Wi-Fi, the PGW keeps the device’s existing IP address, and the device re-registers in the IMS over the new access. For the IMS, this is a change of access type, not a new subscriber. If the IP address changes during the transition, the active call has to be set up again.

Network requirements

Before starting the integration, it is worth checking whether the current network is ready for it. If VoLTE is already running, most of the conditions are met, because the network already has an IMS core, QoS policies and voice bearers. VoWiFi adds requirements on the ePDG side, which we go through one by one below.

EPC compatibility. The ePDG must work with the operator’s PGW over S2b. If the EPC comes from a different vendor, compatibility on this interface should be confirmed before integration, since both session setup and subscriber traffic go through it. The PCRF and PCEF must support dedicated voice bearers, and VoWiFi traffic must pass through the PCEF and be charged under the same rules as LTE sessions. VoWiFi charging needs to be agreed separately with the billing team.

IMS core. VoWiFi assumes an IMS core that already serves VoLTE or is launched together with it. The P-CSCF must be reachable from the IMS APN that devices receive through the ePDG.

SIM and AAA. Authentication requires a 3GPP AAA server that supports SWm towards the ePDG and SWx towards the HSS, as well as SIM cards that support EAP-AKA, i.e. USIMs. Subscribers who already use LTE have such cards, so usually only the IMS parameters and the ePDG domain need to be updated on them.

IPsec tunnel. A subscriber device with VoWiFi keeps an IPsec tunnel to the ePDG open. Home and public Wi-Fi networks are usually behind NAT, so the ePDG must support NAT traversal over UDP 4500. Capacity is sized by the number of simultaneous tunnels and total throughput.

Platform. Stingray ePDG from VAS Experts runs as software on standard x86 servers or virtual machines, so no specialized hardware is needed for deployment.

Deployment steps

Let’s go step by step through how to move from a data-only LTE network to full voice over IP.

1. Assess the network. Check whether the PGW supports the S2b interface and the IMS APN, whether the EPC can allocate voice bearers (QCI=1) at the IMS’s request, what capacity the IMS core and HSS have, and which SIM cards and devices subscribers use.
2. Launch VoLTE on IMS. Bring up the IMS core, configure the IMS APN, QoS policies and voice bearers, set up interconnection with other networks and test calls over LTE. This creates the voice platform that VoWiFi then uses.
3. Add the ePDG and integrate it with the EPC and AAA. Connect the ePDG to the PGW over S2b and to the AAA server over SWm, and make sure the AAA server works with the HSS over SWx.
4. Register the ePDG domain and set up certificates. Devices find the ePDG by a standard name of the form
   epdg.epc.mnc.mcc.pub.3gppnetwork.org, where MCC and MNC are the operator’s country and network codes. The operator needs to obtain delegation of its subdomain in the pub.3gppnetwork.org zone from the GSMA and install a certificate on the ePDG that devices will trust when connecting over IKEv2.
5. Prepare SIM cards. EAP-AKA requires a USIM. IMS parameters and the ePDG domain can be written to the SIM card. If the domain is not on the card, the device builds it from the MCC and MNC codes.
6. Work with phone manufacturers. Many smartphones enable VoLTE and VoWiFi only for operators included in their carrier configuration. The operator sends its parameters to the manufacturers and waits for them to appear in device software updates.
7. Run a pilot and launch the service commercially. Test the service on a limited group of subscribers, fix whatever the pilot reveals, and open it to the entire subscriber base. This last stage needs the most attention, so we cover it separately.

Figure 2 — VoLTE and VoWiFi deployment sequence in an operator’s network

Testing and pilot

Testing starts in the lab. The team checks each interface individually (S2b, SWm, SWx, Rx) and then the entire call flow, from the IKEv2 connection setup and EAP-AKA authentication to IMS registration, voice bearer allocation, and call setup and release. Protocol traces from this stage later become the reference for troubleshooting.

After testing, the service is tried out on a limited group of real subscribers, often employees who use their own phones on home, office and public Wi-Fi networks. This shows how the service behaves on networks the operator does not control. Special attention is paid to handover between VoLTE and VoWiFi in both directions during an active call, since that is where integration errors between the ePDG, PGW and IMS usually surface.

The basic pilot checklist includes:

• outgoing and incoming calls over Wi-Fi;
• sending and receiving SMS over Wi-Fi;
• switching between LTE and Wi-Fi during a call in both directions: the device’s IP address is preserved, the call does not drop, and the old session is properly closed after the transition and does not linger in network nodes;
• different phone models and operating system versions.

Common problems

Most of the difficulties in launching VoWiFi lie not in the network itself but around it. This is clear from the experience of the MVNO Miatel, the first operator to launch Wi-Fi Calling on the VAS Experts ePDG. Integration with the operator’s AAA and PGW worked almost immediately, while organizational tasks and dealing with external parties took the most time.

The full version of the case study describes how the team hunted for the cause in the phone’s firmware and modem, why the first test smartphone had to be brought from India in a suitcase, and what unexpected effect VoLTE and VoWiFi had for subscribers in Moscow. Read the case study “Implementation of ePDG from VAS Experts in MVNO Miatel”.

Wi-Fi quality. This issue affects every operator. The operator does not control the subscriber’s Wi-Fi network. Overloaded access points, a weak link to the provider, or networks that block IPsec all affect call quality, and the operator cannot fix this directly. That is why the pilot should include home, office and public networks.

Choosing an approach

There are several ways to provide Wi-Fi Calling, and they differ in what the operator controls and what the subscriber needs. We covered each of them in more detail in When the mobile network is unavailable: why start calls over the Internet.

Networks without 2G and 3G. For an operator that has only LTE, the choice of approach is effectively predetermined. It has no circuit-switched network to hand voice off to, so voice runs over IMS, that is, over VoLTE, from day one. And since the IMS is already built, untrusted access via ePDG becomes the most logical way to add VoWiFi.

Such an operator gains several benefits from VoWiFi at once:

• Connectivity when frequencies are jammed. If some mobile frequencies are being suppressed.
• Savings for MVNOs. Wi-Fi calls do not consume the host operator’s radio resources, which lowers traffic costs.
• Indoor coverage. Calls work where the LTE signal is weak but Wi-Fi is available: in buildings, shopping malls and basements.

This is how the network of an African MVNO that launched VoWiFi on the VAS Experts ePDG is built. The operator has no 2G or 3G, and the LTE signal is weak in rural areas and inside city buildings. So VoLTE became the main voice service, and VoWiFi covers the places where LTE falls short. After lab tests and a pilot, the commercial launch of Wi-Fi Calling for all subscribers is scheduled for Q4 2026.

How VAS Experts can help

VAS Experts offers a solution for deploying VoLTE and VoWiFi based on its in-house developed products: an ePDG for Wi-Fi access, as well as a PGW and PCEF for the packet core and policies. The solution runs on standard x86 servers or virtual machines and integrates with the operator’s EPC, AAA and IMS.

To discuss a launch in your network, submit a request below.

FAQ

What is the difference between VoLTE and VoWiFi?

Both services use the same IMS core and the same number. VoLTE carries calls over the LTE radio network, while VoWiFi carries them over Wi-Fi and the ePDG gateway.

Is VoLTE needed before launching VoWiFi?

Strictly speaking, VoWiFi needs an IMS core, not VoLTE itself. In practice, Wi-Fi Calling is fastest to launch where VoLTE is already running, because it uses the same IMS, EPC, QoS policies and subscriber settings.

Which network elements are needed for VoWiFi?

An ePDG integrated with the PGW over S2b and with the AAA server over SWm, an AAA server connected to the HSS over SWx, a PCRF for voice bearers, an IMS core and SIM cards that support EAP-AKA. In addition, the operator must be included in phone manufacturers’ carrier configurations.

Does the subscriber need an app or a special SIM card?

No app is needed. Authentication uses the SIM card via EAP-AKA, and the same USIM used for LTE works for this. The feature must be supported by the phone for that operator and enabled in its settings.

How is the connection protected on public Wi-Fi?

The device and the ePDG set up an IPsec tunnel over IKEv2 with SIM-based authentication. All voice and signaling traffic between the phone and the operator’s network goes through this encrypted tunnel.

What problems will the operator face at launch?

The biggest delays come from GSMA domain delegation, certificates, device-side configuration, and the time phone manufacturers need to add the operator. These issues are described in more detail in the Miatel case study.