VoWifi Overview

“Wi-Fi” is a trademark of the Wi-Fi Alliance and the brand name for products using WFA programs based on the IEEE 802.11 family of standards.

When I worked in R&D we used to say that patents are like hostages. The advantage is that we can create them ourselves.  In April 2009, 14 technology companies agreed to pay CSIRO (Commonwealth Scientific and Industrial Research Organization in Australia) $250 million for infringements on CSIRO Wi-Fi patents. Hence Australians labeled Wi-Fi as an Australian invention, though this has not been accepted by everyone without objections (especially in US). CSIRO won another $220 million settlement for Wi-Fi patent-infringements in 2012 with global companies in the US required to pay the CSIRO licensing rights estimated to be worth an additional $1 billion in royalties. Guglielmo Marconi or Joseph Fourier would be bambillionaires these days.

In our post the Wi-Fi refers to a WLAN access to ePC, both trusted over S2a interface or untrusted over S2b interface (3GPP TS 23.402). The VoWifi is then a voice and video over Wi-Fi IMS profile, defined in GSMA IR.51. If you are familiar with VoLTE (IR.92 and IR.94), the VoWiFi defines the same set of services, just over a different access network. The service network – the IMS – remains the same. Sure we need to be more sensitive when it comes to muli-device scenarios or access transfer.

VoWifi

This article is focused on the technical aspect of the VoWifi definition. Would you like to know a bit more about why to deploy the VoWifi, check out this post written by Alberto Diez.

 

 

To the Wi-Fi we refer as to Non 3GPP Access. In the same category we have also CDMA2000 and WiMAX, IEEE 802.11. We have two types of Non 3GPP Access Networks:

• Trusted

Access Network was introduced along with the LTE standard in 3GPP Release 8 (2008). The AN is connected directly to the Packet Gateway (PGW). The access network is controlled directly by the operator and the devices (actual Wi-Fi hotspots) can be trusted from the security point of view. A lot of useful information can be found on the Broadband Forum’s pages.

• Untrusted

Access Network is even older – described in the Release 6 (2006). In this case the WLAN is not under control of the operator or it is not considered to be secure enough. Such a network is connected via Evolved Packet Data Gateway (ePDG) which provides an additional security.

At the end it is up to the operator to classify what ANs are trusted. There are operators who treat all the Wi-Fi communication as Unstrusted, even when it is coming from their own hotspots.

During the initial attach or handover attach a UE needs to discover the trust relationship. Based on it the UE selects an appropriate access procedure. The trust relationship is made known to the UE either during the 3GPP-based access authentication or this information is pre-configured in the UE.

For securing the untrusted access, the ePDG creates an IPSec tunnel. The ePDG is also responsible for

• Routing
• Tunneling over GTP/PMIP towards PGW
• Mobility Anchoring
• Enforcement of QoS policies
• Lawful Interception

The ePDG IP address to which the UE needs to form IPsec tunnel is discovered via DNS query. After the UE is authenticated, UE is also authorized for access to the APN. The relevant specification is IR.61, which says:

• If the UE is not roaming or cannot determine if it is roaming, the UE shall create a FQDN with the HPLMN ID.
• If it is known the UE is roaming and VPLMN ID is known, the UE shall create a FQDN with the VPMLN ID. DNS queries for ePDG selection are sent to the DNS server provided on the Wi-Fi Internet connection.

From the high-level point of view there are two key areas we need to focus on. There are Security and Access Transfer.

Security

In order to secure the communication between UE and the operator’s network we use Internet Protocol Security (IPsec) protocol suite. The IPsec supports two modes – transport and tunnel modes. In our case we use the tunnel mode which allows to send a whole IP message (including the IP header) unchanged and protected to the network.

In this post I’ll stay brief, would you need more details, check out the post ePDG and IPSec, or An Illustrated Guide to IPSec written by Steve Friedl. If you don’t need to understand the mystery of IPSec, just remember, that the IPSec tunnel mode enables us to send authenticated and encrypted IP messages.

IPSec vs. TLS

IPSec is a protocol suite. It does use following protocols in order to provide authentication, encryption and data integrity:

• Authentication Headers (AH) provides data origin authentication for IP datagrams and provides protection against replay attacks. The authentication is performed by computing hash code over nearly all the fields of the IP packet (excluding those which might be modified in transit).
• Encapsulating Security Payloads (ESP) provides encryption of the original IP datagram. In addition to encryption, ESP can also optionally provide authentication, with the same hashes as found in AH. Unlike AH, the ESP authentication is only for the ESP header and the original IP message. However this does not weaken the security of the authentication much.

IPSec – ESP

• Security Associations (SA) provide algorithms and data which produce parameters needed by AH and/or ESP. The Internet Security Association and Key Management Protocol (ISAKMP) is a framework for authentication and key exchange. The actual key material can be then provided e.g.  by Internet Key Exchange (IKE and IKEv2) or IPSECKEY DNS records.

The role of ePDG is to create an IPSec tunnel between the UE and the ePC network (SWu reference point). The key material is stored in the ISIM/USIM module in case of UE. The ePDG needs to retrieve the keys from AAA server which communicates with HSS.

ePDG – tunnels

In order to establish an IPSec tunnel the ePDG (the AAA in fact) can use Extensible Authentication Protocol for Internet Key Exachange (EAP-AKA2). But it is possible to use other EAP flavors too (e.g. EAP-TLS for UE which doesn’t have SIM card).

Once the IPSec tunnel is established the data goes directly to the PGW.

ePDG – Control Plane

ePDG – User Plane

Note as the ePDG is an entry point for the traffic coming from the public Internet, the implementation should be robust enough to deal with common threats as DOS, DDOS, malformed packets etc.

Handovers

As Wi-Fi technology offers only short-range coverage, we should be prepared to do a handover. The transfer can be between two Wi-Fi hotspots, or between the Trusted and Untrusted network, or between Wi-Fi and 3GPP network.

We also distinguish if the handover is with or without Optimizations. The whole topic is very complex, the details can be found in the GSMA IR.61 and 3GPP 23.402.

Very generally we can say that the handover between Wi-Fi and 3GPP network is divided into two parts:

• Wifi->LTE
  1. Create Radio and Access Bearer between UE and SGW
  2. Create GTP Tunnel between SGW and PGW

Handover Wifi to LTE

• LTE->Wifi
  1. Create IPSec tunnel between UE and ePDG
  2. Create GTP tunnel between ePDG and PWG

The session itself is anchored in the PGW. The PGW identity of all the allocated PDN Gateway(s), as well as information that identifies the PLMN in which the PGW is located, are returned by the 3GPP AAA Server during the authorization.

Of course in case that we use a different client for 3GPP and non-3GPP access, the re-registration is needed as there will be a new sip.instance and possibly also different capabilities.

MOBIKE

When it comes to the transfer between two Wi-Fi hotspots it means that also the UE’s IP address has been changed.

Although the issue can be solved by creating new IKE and IPsec SAs,  it may be not necessarily the best approach. In some cases, creating a new IKE_SA requires  user interaction for authentication. Creating new SAs also requieres expensive calculations and a couple of signalization round-trips. Therefore we need a mechanism for updating the IP addresses of existing IKE and IPsec SAs. The mechanism is implemented within the MOBIKE protocol described in the IETF RFC 4555.

The MOBIKE works only in case that it is supported by both UE and ePDG and they both maintain the IPSec connection state. In case the connection is lost for whatever reason during the handover the MOBIKE can’t resume the IPSec session.

This mechanism can be used also when the UE has more interfaces (with different IP addresses).

More information about the ePDG and IPSec can be found in the following post.