3GPP Wi-Fi Access

Below we will explain the practical principles behind trusted and untrusted 3GPP Wi-Fi access.

It can be overwhelming and confusing with all these acronyms that come with new 3GPP releases. So for the benefit of those of you familiar with the acronyms for 3G and 4G, please refer to this ‘translation table.

Note that these are just ‘functions’ and may be delivered as one combined solution, deployed as containerized functions, or the same virtual or physical gateway node.

Trusted 3GPP Wi-Fi Access

Trusted non-3GPP (Wi-Fi) access was first introduced with the LTE standard in 3GPP Release 8 (2008). Trusted access is often assumed to be operator-built Wi-Fi access with encryption (enabled by 802.1x) in the Wi-Fi radio access network (RAN) and a secure authentication method (EAP). However, it is always up to the home operator to decide what is to be considered trusted.

In the case of trusted access, the device (UE) is connected through a Wireless Access Gateway in the Wi-Fi core. In turn, this Wireless Access Gateway (WAG) is connected through a secure tunnel directly with the Packet Gateway, also used for cellular traffic in the Mobile Core. In the case of 5G, a null-encryped tunnel is used between the device and the WAG, more about this in the  Wi-Fi and 5G convergence section.

SIM Authentication (EAP-SIM/AKA/AKA’ or 5G-AKA) is also essential for trusted non-3GPP access. In addition to authentication of the device, it produces cryptographic keys used for encryption in the secure Wi-Fi network (802.1x).

In practice, the Wi-Fi access network must support the following features to be considered trusted:

• 802.1x-based authentication, which in turn also requires encryption of the RAN
• 3GPP-based network access using the EAP method for authentication
• IPv4 and/or IPv6

Untrusted 3GPP Wi-Fi Access

Untrusted non-3GPP (Wi-Fi) access was first introduced in the Wi-Fi specification in 3GPP Release 6 (2005). At that time, Wi-Fi access points featuring advanced security features were rare. Hence Wi-Fi was considered open and unsecured by default. Untrusted access includes any Wi-Fi access the operator has no control over, such as public hotspots, subscribers’ home Wi-Fi, and corporate Wi-Fi. It also consists of Wi-Fi that does not provide sufficient security mechanisms such as authentication and radio link encryption.

The fact that untrusted non-3GPP access works over any Wi-Fi network is why it is the method of choice for Wi-Fi Calling.

The untrusted model requires no changes to the Wi-Fi network but impacts the device side because it needs an IPsec client to reside on it. The device is connected through a secure IPsec tunnel directly to an IPsec Terminating Gateway in the Mobile Core, which is connected through an encrypted tunnel to the Packet Gateway. The Packet Gateway is used for both cellular and Wi-Fi traffic.

This integration on the core network side also means that Wi-Fi service management platforms, such as the Aptilo Service Management Platform™ (SMP), must interface with mobile core network HLR/HSS/AMF for SIM Authentication (EAP-SIM/AKA/AKA’ or 5G-AKA). This provides the same level of authentication security as in the cellular network. It may also be required to interface with mobile core network policy functions. In addition to authentication of the device, the SIM authentication process produces cryptographic keys used for IPsec tunnel establishment.

Wi-Fi and 3G/4G Convergence

The 3GPP AAA server is located within the 3GPP HPLMN. For 3GPP Wi-Fi access, it provides authentication, authorization, policy enforcement, and routing information to the packet gateways in the Wi-Fi core and mobile core. It can perform EAP-SIM/AKA authentication, via the SIM-card, for automatic and secure authentication of Wi-Fi-enabled devices.

The operator may want to monetize their Wi-Fi network by opening it for public use. The Enea Aptilo SMP (software) and SMP-S (service on AWS) are ideal for this use case as it encompasses a 3GPP AAA server together with additional features for Wi-Fi monetization. We call these additional features Aptilo SMP 3GPP AAA+, which include captive portals, Wi-Fi AAA, Wi-Fi Policy & Charging,  Wi-Fi subscriber management, and our ServiceGlue concept with configurable logic.

Adding the optional Aptilo SMP Venue Wi-Fi Manager allows the mobile operator to build their mobile data offloading footprint as a profitable service rather than a heavy investment. They do this by offering managed B2B Guest Wi-Fi services and adding an additional secure SSID for Wi-Fi offload at each location.

If you are looking for a standard 3GPP AAA, then consider the Enea Access Manager.

Below we will discuss the role of the Aptilo SMP 3GPP AAA+ in different 3G/4G Wi-Fi access scenarios, including all the 3GPP specified options for 3GPP Wi-Fi access.

1. Access with 3G Core and Local WLAN Break-Out

This option is currently the most deployed solution by operators doing EAP-SIM/AKA authentication. The option provides local traffic breakout for all clients at the Wi-Fi access gateway and is based on standard RADIUS and EAP methods for authentication with HLR. The Wi-Fi access point requires support for 802.1x authentication with EAP-SIM/AKA. No additional 3GPP interfaces are needed.

2. Access with 3G Core (DPI)

All traffic from smartphones/tablets with EAP-SIM/AKA support is terminated at the Deep Packet Inspection (DPI) node in the 3G core network. In contrast, traffic from non-SIM devices is directed to the Internet locally. This option uses standard RADIUS and EAP methods for authentication with HLR. The Wi-Fi access point requires support for 802.1x authentication with EAP-SIM/AKA. In this case, the DPI is typically used by the operator to inspect and enforce policies for 3G data services. No additional 3GPP interfaces are required.

3. Access with 3G Core and WAG (GTP)

This option is partly aligned with 3GPP TS23.234 specifications with the introduction of the Wireless Access Gateway (WAG) node in the Wi-Fi core for access to the 3G core. The WAG establishes GTP tunnels for client traffic for EAP-capable clients terminated in the GGSN. The 3GPP Wm interface is used for EAP client authentication with HLR and tunnel establishment. The Wi-Fi access point requires support for 802.1x authentication with EAP-SIM/AKA. A DPI can potentially also be used after the GGSN.

4. Access with 3G Core (I-WLAN)

This option is aligned with 3GPP TS23.234 specs for “untrusted” access with the 3G core. This option requires an EAP client in the device with IPSec support. No impact on the Wi-Fi core or Wi-Fi RAN; legacy Wi-Fi hotspot networks will work. IPSec tunnels will be terminated in the Tunnel Terminating Gateway (TTG) node – a new mobile core node introduced for this purpose. The TTG maps the IPSec tunnels into GTP tunnels terminated in the GGSN (GGSN can typically not terminate IPSec).

The 3GPP Wa interface is used for EAP client authentication with HLR, and the Wm interface is used for tunnel mapping in the TTG.

This option will most likely be replaced by the “untrusted EPC” option in most practical implementations.

5. Trusted Wi-Fi Access in EPC

This option is based on 3GPP specification TS23.402 with the introduction of the Trusted Wireless Access Gateway (TWAG) node. The TWAG establishes GTPv2, PMIP, or MIP tunnel (the S2a interface) to the P-GW in the EPC core for all trusted traffic.

“Trusted” traffic will likely mean an operator-controlled Wi-Fi environment based on a Hotspot 2.0 compatible Wi-Fi Core with 802.1x and EAP authentication support to the HSS/HLR. The Wi-Fi access point requires support for 802.1x authentication and EAP-SIM/AKA methods. This option also requires support for EAP-SIM/AKA in the device.

The STa interface is mainly used for EAP client authentication with HSS and S2a option selection (which tunnel type to use). The S6b interface between 3GPP AAA and P-GW is used for tunnel authentication, static quality of service and mobility (if applicable), etc. The 3GPP specification also allows for a full or partial local breakout of Wi-Fi traffic at the TWAG in the Wi-Fi core.

6. Untrusted Wi-Fi Access in EPC

This option is based on 3GPP spec TS23.402 with the introduction of the evolved Packet Data Gateway (ePDG) node. This option requires an EAP client in the device with IPSec support. No impact on the Wi-Fi core or Wi-Fi RAN; legacy Wi-Fi hotspot networks will work. IPSec tunnels will be terminated in the ePDG – a new mobile core node introduced for this purpose. The ePDG maps the IPSec tunnels into GTP or PMIP tunnels terminated in the Packet Gateway P-GW.

“Untrusted” will likely mean a non-operator-controlled network, partner network, or a legacy Wi-Fi hotspot network not supporting 802.1x.

The 3GPP SWa interface is mainly used for EAP client authentication with HSS. The SWm interface is used for additional authentication parameters, including subscription profiles and S2b option selection (which tunnel type to use). The S6b interface is used between Wi-Fi AAA and P-GW for tunnel authentication, static quality of service and mobility (if applicable), etc.

Wi-Fi and 5G Convergence

5G introduces new network architectural concepts for Wi-Fi integration with the mobile core (non-3GPP access).

Standardization and network technology history tell us that not all functions in a standard will be deployed in real networks. They will not be implemented by vendors and service providers unless there are sound commercial reasons.

The 3G and 4G versions of Wi-Fi data plane integration are excellent examples. Most mobile operators have focused on local break-out of Wi-Fi traffic from their secure Wi-Fi networks (802.1x).

With no operational rationale or commercial reasons to backhaul Wi-Fi traffic to the Mobile Core, operators have opted to use secure SIM-based authentication, sometimes combined with policy control from the Mobile Core. There is no reason to exert extra load on the Mobile Core when operators can apply all required policies for Wi-Fi locally.

Device manufacturers also control much of what is possible and implemented. It took almost ten years for device manufacturers to decide to implement the IPsec client needed for untrusted Wi-Fi access. In their view, it simply took that long for a good commercial reason to materialize. This reason came with Wi-Fi Calling, which was in their own and their customers’ best interest.

So, are operators more likely to implement the 5G 3GPP standards for Wi-Fi access? We believe so, and there are a few reasons for that. But such implementations will take time. First – as discussed in our white paper Wi-Fi in the 5G era  – operators more than ever need to embrace. Secondly, a new breed of carrier-grade Wi-Fi (Wi-Fi 6) is here. And with Wi-Fi 6E, Wi-Fi 6 on 6 GHz band, the available spectrum for Wi-Fi will be tripled. Thirdly, the new Access Traffic Steering, Switching & Splitting (ATSSS) 3GPPP standard will finally give operators a good reason to backhaul traffic to the Mobile Core. We dive deeper into ATSSS below.

Trusted and Untrusted 3GPP Wi-Fi Access for 5G

The simplified diagram shows Wi-Fi service integration with the new service-based 5G Core (5GC) introduced in 3GPP release 15 (untrusted) and 16 (trusted).

The first thing to observe is that this architecture is Radio network (RAN) agnostic since both the Cellular and Wi-Fi access use the same interfaces (N1-N3).

N1 Control Plane Interface

The N1 is a control plane interface between the device (UE) and the Access and Mobility Function (AMF). It is primarily used to transfer information about the connection, mobility, and session from the UE to the AMF.

This interface is used both for Cellular and Wi-Fi (for 5G Capable Devices), and it is physically transported the same way to the AMF as shown by the N2 interface.

N2 Control Plane Interface

The N2 is the control plane interface between the access network and the 5G Core. It is primarily used for connection management, UE context and Protocol Data Unit (PDU) session management, and UE mobility management.

N3 Data Plane Interface

The N3 is the data plane interface between the access network and the User Plane Function (UPF) in the 5G Core. The UPF is the packet gateway transporting data to the internet.

How It Is All Connected

For Cellular networks, the N2 and N3 interfaces connect the base station (gNB) with the AMF and UPF. For Wi-Fi, they use the non-3GPP interworking and gateway functions (N3IWF, TNGF, TWIF) to connect with the AMF and UPF.

5G introduces a new principle for non-3GPP access: Simultaneous connections via cellular and Wi-Fi are now possible by using multiple non-access stratum (NAS) connections over the N1 interface. This is a prerequisite for the new ATSSS standard and the same authentication procedures, EAP-AKA’ and 5G-AKA, are used for both Cellular and Wi-Fi.

New EAP Protocol and Unusual Use of IPsec

A new protocol, EAP-5G, has been introduced to support NAS messages over Wi-Fi networks. The IKEv2 and EAP-5G protocols are used to establish an IPsec tunnel for signaling during the registration procedure between the device and the interworking and gateway functions. The EAP-5G protocol is then used to encapsulate NAS messages over the IKEv2 protocol.

Another interesting new principle is the use of IPsec also for trusted Wi-Fi networks. Why would you want to use an IPsec connection – albeit with null encryption to avoid double encryption – in a secure Wi-Fi network? It turns out that implementations in devices and gateways with dual support for both trusted and untrusted access will probably be easier to implement in this case. Add to this the benefits of a fixed anchor point in the Mobile Core to facilitate mobility and ATSSS.

Let’s now examine the new functions for non-3GPP access. Again, please note that these functions are not the same as physical gateways. In practice, these functions could all reside in the same gateway. One vendor could also provide the control plane (N1-N2), while another supplies the data plane (N3).

Non-3GPP Interworking Function (N3IWF)

The Non-3GPP Interworking Function (N3IWF) is the IPsec tunnel terminating node for 5G, similar to the ePDG for integration with the 4G Core. It is located in the Mobile Core and communicates with the Access and Mobility Function (AMF) control plane over the N1 and N2 interface. For the data plane, it communicates with the User Plane Function (UPF) over the N3 interface.

Trusted Non-3GPP Gateway Function (TNGF)

The trusted non-3GPP Gateway Function (TNGF) is for 5G the equivalent to the Wireless Access Gateway (WAG) used for trusted access to the 4G Core. The TNGF is located in a trusted environment, often the Wi-Fi network, and communicates with the Access and Mobility Function (AMF) control plane over the N1 and N2 interface. For the data plane, it communicates with the User Plane Function (UPF) over the N3 interface. As discussed, the device and the TGNF are connected using an IPsec tunnel with null encryption.

Trusted WLAN Interworking Function (TWIF)

The trusted WLAN Interworking Function (TWIF) is a new 5G function for interoperability with legacy devices. This is to resolve the contingency that some devices may support 5G SIM authentication but do not support 5G NAS signaling over trusted Wi-Fi access. These devices lack the support for the EAP-5G and IKEv2 protocols. 3GPP refers to such devices as non-5G-Capable over WLAN (N5CW). The TWIF contains the NAS protocol stack and exchanges NAS messages with the AMF on behalf of these types of devices.

The TWIF is located in a trusted environment, often the Wi-Fi Network, and communicates with the Access and Mobility Function (AMF) control plane over the N1 and N2 interface. For the data plane, it communicates with the User Plane Function (UPF) over the N3 interface. Just as in the case of TNGF, the device connects with the TWIF using an IPsec tunnel with NULL encryption.

ATSSS the Future of Wi-Fi and Cellular Convergence

The new Access Traffic Steering, Switching, and Splitting (ATSSS) function is the ‘Holy Grail’ of mobile data offloading, but its complexity and reliance on device support means it will likely take years to come to market.

ATSSS Will Provide Smarter Connectivity

Will new and better technology and standards for automatic network selection and intelligent convergence between mobile and Wi-Fi services be developed for the mass market of the future? The short answer is probably yes. We will address one of them here, namely the newly released Access Traffic Steering, Switching & Splitting (ATSSS) introduced in 3GPP release 16.

But the answer is also that such technologies – including Passpoint with SIM authentication – already exist for the most part. These may not be ideal but are still extensively field-proven and work well enough to have already been implemented by dozens of major carriers.

Operators actively choosing Wi-Fi offload as a strategy and who want more granular control often include so-called connectivity manager clients (apps or hidden clients) on the device. Such solutions can be pretty sophisticated depending on to what extent the app, and hence the operator, can access and control the communication layer in the device’s operating system.

The capability of such apps or hidden clients must at least include solutions to the following current imperfections in switching between Wi-Fi and mobile network access:

• Avoiding unintentional ‘walk-by’ switchover to public Wi-Fi, which could produce a poor user experience or even intermittent loss of connectivity.
• Policies and thresholds should automatically reject or accept handoff to Wi-Fi and back to cell sites if either is congested.

The Three “S” in ATSSS

Wouldn’t it be a significant step up in performance and quality of experience if a phone natively could aggregate the data streams from Wi-Fi and cellular into one stream and perhaps even intelligently steer and switch traffic between the two?

We think yes – and fortunately, the 3GPP seems to think so as well since they have introduced ATSSS as part of the 3GPP Release 16 standard for 5G.

Steering

Choose best network based on speed, cost, and latency.

Switching

Move seamlessly between 5G and Wi-Fi.

Splitting
Policy-based split of the traffic over 5G and Wi-Fi.

ATSSS uses the so-called Multipath TCP (MPTCP) technology, described in our white paper, to allow IP data traffic to flow simultaneously over Wi-Fi and 5G networks. The results are higher data rates, improved overall quality, and even gapless handovers between Wi-Fi and 5G.

Since very few applications and web servers support MPTCP, the ATSSS specifies an MTCP Proxy implemented in the 5G core User Plane Function (UPF). It also defines an ATSSS low layer functionality (ATSSS-LL) to support other protocols such as UDP.

The introduction of ATSSS is excellent news for advanced Wi-Fi service management platforms such as the Enea Aptilo Wi-Fi SMP, as it makes policy management so much more complex.

ATSSS Steering Modes

These functions, the three “S”, translate to four ATSSS standard steering modes that need to be supported in the device and in the Mobile Core (UPF).

Splitting
One access network – cellular or Wi-Fi – is the active (default) access network. The traffic is routed over this access network until it becomes unavailable, in which case traffic switches over to the other access network. When the active access network is available again, the traffic is switched back.

Smallest Delay
Traffic is sent over the access network with the smallest delay. The Performance Measurement Function (PMF) determines the latency of each network connection. The underlying multipath protocol can also provide measurements.

Load Balancing
This specifies a fixed percentage for the fraction of the traffic that should connect over the 3GPP network with the rest of the traffic sent on the non-3GPP network. This mode only applies to the quality of service (QoS) flows with a non-guaranteed bit rate (non-GBR).

Priority-based
Traffic is transmitted over a specified high-priority access network (Wi-Fi or cellular). If this access network becomes congested, the traffic overflows onto the other access network. If the high-priority access network becomes unavailable, traffic switches to the other access network (as in Active Standby). The determination of congestion is implementation-specific.

Many Stakeholders for Policy Decisions

Another factor that adds to the complexity of policy management is the large number of stakeholders. Real-world deployment of ATSSS will need to cater to:

• Service provider policies
• Policies set by the user
• Device vendor policies
• App provider policies
• Enterprise IT policies

We think that ATSSS is a very promising standard. It is, to some extent, the ‘Holy Grail’ of mobile data offload, and with ATSSS, operators may finally find a good reason for backhauling Wi-Fi traffic to the mobile core. However, no 3GPP standard for Wi-Fi integration will ever be implemented in practice unless the device vendors want it.

No Reason to Wait for ATSSS

For ATSSS to reach the mass market, device support is crucial. An example of a related standard that never achieved any market penetration at all is 3GPP ANDSF, which was a useful concept but, in the end, was never implemented natively in any device.

It may take quite a few years more for ATSSS to come to market – or alternatively, proprietary forms of essentially the same function incorporated by Apple or others may, in the end, supersede the 3GPP’s attempts. The ATSSS concept has already been tested successfully by Korea Telecom using a proprietary solution.

In either case, there is a good likelihood that Wi-Fi and 5G data streams will find new ways of complementing each other – including using aggregation & gapless handovers – on the transport layer.

Meanwhile, all the benefits of known and field-proven systems for cellular and Wi-Fi convergent services remain available to any operator who wishes to apply vastly improved Wi-Fi technology as a part of their network strategy today. Passpoint and EAP-SIM-based solutions are readily available and can possibly be complemented with an app for more granular control. In other words: Even though a more systematic 3GPP-based approach to convergence may emerge in the coming years, there is no reason to wait. Excellent convergence solutions exist today.