Wi-Fi Calling - lost in translation

In a time when mobile operators have very few opportunities to innovate with mobile services an application like Wi-Fi calling (WFC) shows good potential. Slowly and mostly due to the noise Apple made when they launched the service with T-Mobile USA in 2013 mobile operators around the world started to recognize its potential. Still … it is only available in very few networks.

 There are two ways to implement WFC - via the SBC approach or the ePDG approach. While both implementations are standard (despite the folklore), there are pros and cons for each approach. Mobile operators and in particular the mobile phone OEMs are leaning in one direction and I believe this is not in the best interest of the user and the overall service experience suffers. I am trying to summarize here the options and let you judge what approach serves best the user and the operator offering the service.

 With the SBC approach the mobile phone connects via TLS to the Session Border Controller and therefore the IMS session is anchored at SBC. The SBC acts as a back-to-back SIP/IMS user agent. The mobile phone has a public IP address. With ePDG the mobile phone creates an IPsec tunnel into the mobile network and the IMS stack in the mobile phone gets a local IP address from the mobile operator. Because of this paradigm the ePDG approach allows voice handover between WFC and VoLTE while the SBC approach does not. Besides the difference in the access method the telephony services are running pretty much the same in both cases – the WFC application utilizing the IMS stack performs the registration for telephony services and then calling and supplementary services are mostly performed via the TAS (Telephony Application Server) and the IMS network elements.

 For a mobile operator though the SBC approach is much simpler and much more cost effective. Besides the IMS network (for the MMTel service implementation) which is needed for both solutions, the only new element is the SBC and maybe the GBA or some sort of Identity Management in order to allow a service like MMS to also run while on Wi-Fi.  The good part is that you can deploy WFC in a 2G or 3G in the network.

The ePDG approach requires the ePDG, the PCRF (which is part of the LTE core), the XDMS and the GBA in order to enable the Ut interface which is needed for Supplementary Services management. In the same time GBA is required in order for the Ut interface to function. With all these complications the USSD service is still forcing a CS fallback (as required by IR.92). On top of all these in order to enable hand overs to/from VoLTE many other network elements require enhancements or updates. The IPSec also proves to be costly due to tunneling licensing (you need a tunnel per each phone attached).

 Now let’s look at WFC from the mobile device perspective. The ePDG approach keeps both the cellular radio and the Wi-Fi radio ON (and mostly because of the handover capability) therefore, when you turn Wi-Fi on, the phone is consuming more battery power; the solution is inefficient from this point of view (Wi-Fi calling requires Wi-Fi to stay on even when phone goes in sleep mode).

Today most users are trying to use Wi-Fi whenever available in order to save their data buckets but unfortunately when they do so the phone keeps the cellular radio ON in order to make/receive calls, send/receive SMS. On the SBC approach after the phone successfully registers to IMS the cellular radio is turned OFF because the telephony services are also moved over Wi-Fi. USSD is also running over Wi-Fi. There is a significant battery impact difference between the two solutions for WFC. In my opinion the battery savings and the service simplicity (which leads to good WFC reliability) are much more valuable than the voice call handover to/from VoLTE.  

The handover has its own challenges. Because Wi-Fi signal drops very fast, handover is not always successful. While there is no VoLTE roaming today obviously handovers do not work when in roaming. And when VoLTE roaming will be an option it will not come for free and therefore a handover from the free WFC to VoLTE won’t be desired.

From the mobile handset perspective, the implementation of an SBC type approach is also much simpler and could be done at several layers in the phone (OS, OEM/RIL or modem). For the ePDG approach the implementation has to be under the OS because otherwise the OS (i.e. Android) would have to be able to deal with a split tunneling paradigm. Since today the smart phone is pretty much a modem glued to a Linux computer when the modem makes an IPSec (VPN) tunnel to the ePDG the operating system (Android, iOS, Windows) is not aware of the tunnel. Then you have to solve the dilemma of what traffic to send in the tunnel – the mobile operator does not want your Internet traffic and you don’t want that either because this is why you turned on Wi-Fi to start with.   

Sadly, with all the above considerations the industry is moving towards the ePDG implementation and this is mostly due to the mobile phone manufacturers. Apple made the move towards the ePDG and this put a lot of $$ pressure on the mobile operators. This is the reason you don’t see Wi-Fi Calling in too many countries – you can only use your iPhone’s Wi-Fi Calling capability in a handful of networks today (you need one hand to count it). Unfortunately, the Android OEMs did not help either. Since they “had to” match the iPhone’s handover capability if a mobile operator is asking for Wi-Fi Calling they are pushing for ePDG – much more cost effective for them, one solution for all even though each implementation needs customizations. What about the operators around the globe that did not deploy LTE or have no plans for VoLTE? Why pushing for an implementation so complex and so costly? At the end of the day the user suffers – phones (starting with the flagship iPhone 6 and Galaxy S6) have poor battery performance and the WFC service is only available in few networks.

What bits me is why the operators end up spending a lot of money and deploy a simple service in a very complicated way leading to a poor user experience. There are much simpler solutions … and OEMs still need to sell their phones.