The 3GPP AAA server is located within the 3GPP Home Public Land Mobile Network (HPLMN). For 3GPP Wi-Fi access in 4G and 5G non-standalone (5G NSA) networks, the 3GPP AAA provides authentication, authorization, policy enforcement, and routing information to the packet gateways in both the Wi-Fi core and mobile core networks. It performs EAP-SIM/AKA/AKA′ authentication via the SIM card for automatic and secure authentication of Wi-Fi devices.

Below, we will explore the role of the standard 3GPP AAA for SIM authentication in various 4G and 5G NSA Wi-Fi access scenarios, including all 3GPP-specified options for 3GPP Wi-Fi access. To provide a comprehensive view, we include the Enea Aptilo SMP in the diagrams with an integrated 3GPP AAA and additional functions that may be essential for real-world deployments. We will cover the Enea Aptilo SMP in more depth in the upcoming Enea’s Wi-Fi Offloading Expertise chapter, download the full white paper to get access to it now.

The two first, local WLAN break-out and access through DPI, are not standardized by 3GPP but are extensively used and could also be used for 5G as long as SIM authentication can be carried out in the corresponding 5G architecture.

The 3GPP specifications define two types of

non-3GPP access: trusted and untrusted. Non-3GPP access includes technologies such as Wi-Fi, WiMAX, fixed-line, and CDMA networks.

In the next three posts, we will explore the differences between trusted and untrusted 3GPP Wi-Fi Access and the various 3GPP standard methods for integrating these access types with cellular networks across different cellular generations (3G/4G/5G). We will only focus on 4G and 5G as the methods for 3G are essentially the same as for 4G, only with different names on the 3GPP nodes.

The numerous acronyms introduced with each new 3GPP release can be overwhelming and confusing. We’ve provided a ‘translation table’ to assist those of you already familiar with the terminology for 3G, 4G, or 5G.

Please note that these are simply ‘functions’ that may be delivered as a combined solution with one or more nodes, deployed as containerized functions, or integrated into 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 typically refers to operator-managed Wi-Fi networks that use encryption (enabled by 802.1x) within the Wi-Fi radio access network (RAN) and secure authentication methods like EAP.

In the case of trusted access, the user device (UE) connects through a Wireless Access Gateway (WAG/TWAG/TNGF/TWIF) in the Wi-Fi core. The gateway, in turn, establishes a secure tunnel directly with the Packet Gateway (GGSN/P-GW/UPF), which is also used for cellular traffic in the Mobile Core. For 5G standalone (5G SA) architectures, a null-encrypted tunnel is utilized between the device and the TNGF/TWIF—more details on this can be found in the Wi-Fi and 5G convergence section.

SIM authentication (EAP-SIM/AKA/AKA′ or 5G-AKA), performed by a 3GPP AAA server, is crucial for trusted non-3GPP access. Beyond authenticating, the device for access to the Wi-Fi network, it also generates cryptographic keys used for the Wi-Fi encryption (WPA2/WPA3).

Untrusted 3GPP Wi-Fi Access

Untrusted non-3GPP (Wi-Fi) access was first introduced in the Wi-Fi specification of 3GPP Release 6 (2005). At that time, Wi-Fi access points with advanced security features were uncommon, so Wi-Fi was generally considered open and unsecured by default.

Untrusted access refers to any Wi-Fi network over which the operator has no control, including public hotspots, subscribers’ home Wi-Fi, and corporate Wi-Fi networks. This also encompasses Wi-Fi networks that lack adequate security mechanisms, such as EAP authentication and radio link encryption (802.1x enabling WPA2/WPA3-Enterprise encryption). Conversely, a Wi-Fi network using EAP and 802.1x outside the operator’s control, for instance, an Enterprise Wi-Fi network, is still considered untrusted.

The flexibility of untrusted non-3GPP access, which works over any Wi-Fi network, makes it the preferred method for services like Wi-Fi Calling (aka Voice over Wi-Fi).

The untrusted model requires no modifications to the Wi-Fi network itself but does impact the device side, as an IPsec client must be deployed natively on the device. The device connects through a secure IPsec tunnel directly to an IPsec Termination Gateway (TTG/ePDG/N3IWF) in the Mobile Core, which is then linked through an encrypted tunnel to the Packet Gateway (GGSN/P-GW/UPF), which handles both cellular and Wi-Fi traffic. This integration means that the device must interact with mobile core network components like the HLR/HSS/AUSF-UDM for SIM-based EAP authentication (EAP-SIM/AKA/AKA′ or 5G-AKA) to establish the IPsec tunnel, but not for granting Wi-Fi access. This ensures the same level of authentication security as in the cellular network.

Historically, not all standardized functions—like those defined in 3GPP—make it into real-world networks. Vendors and service providers only implement features when there are strong commercial incentives. The integration of Wi-Fi with 3G and 4G data planes is a prime example. Most mobile operators have implemented local break-out (LBO) for Wi-Fi traffic directly from their secure Wi-Fi networks (802.1x).

Without a compelling operational or commercial rationale for backhauling Wi-Fi traffic to the Mobile Core, operators have instead leveraged secure SIM-based authentication, often paired with policy control from the Mobile Core. This approach avoids adding unnecessary load to the Mobile Core, allowing operators to enforce policies locally through advanced service management systems like the Enea Aptilo SMP.

Mobile device vendors also play a critical role in determining what capabilities are implemented and what functionality that gets deployed into real-life services (Learn more about this in our recent post Wi-Fi Offloading and the Device). For instance, it took nearly a decade for device vendors to adopt the IPsec client required for untrusted Wi-Fi access. The motivation for this change materialized with the rise of Wi-Fi Calling, which served both the device manufacturers’ interests and the consumers. Backhauling Wi-Fi Traffic to the Mobile Core: Control vs. Efficiency In certain markets, some mobile operators choose to backhaul Wi-Fi traffic to the mobile core, mainly for perceived control and regulatory aspects. However, a vast majority (90%) prefer local traffic breakout due to cost and network optimization reasons.

The preference for local offloading is driven by the desire to minimize latency and reduce core network load. There are two primary reasons operators still consider backhauling traffic: Deep Packet Inspection (DPI): By routing traffic through the mobile core, operators can perform DPI to analyze and manage data flows. However, this can also be achieved outside the 3GPP standards using policy-based routing to a dedicated DPI function outside the mobile core. Policy Control, Quota Management, and Charging: Although these functions are managed in the mobile core, there is no strong justification for this approach. A well-integrated Wi-Fi service management system can handle policy enforcement, quota tracking, and charging locally within the Wi-Fi network while still maintaining alignment with the mobile core. Explore our solutions for local policy and charging integration. Learn More About Wi-Fi Offloading Architectures In the next upcoming white paper excerpts, we will cover the 3GPP specified architectures for Wi-Fi Offloading integrated with the Evolved Packet Core (EPC) and the 5G standalone mobile core (5G SA). If you don’t want to wait for these posts, go here for further insights on all the different Wi-Fi offloading architectures, and to learn why a standard 3GPP AAA function is not enough for effective Wi-Fi offloading.

The Apple device tries to connect to networks in this order:

1. The user’s “most preferred” network
   Known networks are scored based on the user’s actions. If the user manually switches to a network, its score increases. If the user manually disconnects from a network, its score decreases. The “most preferred” network is the one with the highest score.
2. A private network
   Private networks are those set up in homes and offices and can include the Personal Hotspot on the user’s iOS or iPadOS device. Devices with macOS, iOS, or iPadOS reconnect to known private networks in order of most recently joined.
3. A public network
   Public networks are designed for general access in public places like hotels, airports, and coffee shops. Other examples include Passpoint (Hotspot 2.0) and EAP-SIM/AKA/AKA′ in Wi-Fi connections provided by cellular carriers and network access providers.
   

Android and other devices use similar algorithms to ensure a great user experience. While it’s natural for mobile operators to initially feel concerned about not having control over Wi-Fi network selection, is “the device is king” necessarily a negative development?

From a Wi-Fi offloading and happy user standpoint, prioritizing the user’s preferred Wi-Fi network makes sense, followed by their home or workplace network, and last in priority, the public service provider networks. Furthermore, modern mobile devices use sophisticated algorithms to select the Wi-Fi network that offers the best user experience when multiple networks are available at the same location. For further details, refer to the Wi-Fi network selection section.

In other words, leave the Wi-Fi network selection decision to the device!

Mobile operators often seek greater control over the decision to remain on the cellular network or switch to Wi-Fi. Enea, positioned at the intersection of the 3GPP ecosystem and Wi-Fi technology, is uniquely suited to develop a solution for this challenge. In an upcoming post More Intelligent Network Selection, we will share our vision on this topic.

Wi-Fi Connection Profiles

Wi-Fi connection profiles are collections of settings that allow devices to identify and connect to specific wireless networks. They are supported across various platforms, including iOS/iPadOS, Android, Windows, and macOS. Each platform (OS) may have specific features or limitations regarding Wi-Fi profile management.

Wi-Fi connection profiles contain essential information needed to connect to a Wi-Fi network. The information varies depending on the connection type but can include:

• SSID (network name).
• Network Access Identifier (NAI) Realm, used for user authentication.
• Fully Qualified Domain Name (FQDN), which is used to specify the hostname of the authentication server.
• Security type (e.g. WPA2-Personal, WPA2/WPA3-Enterprise).
• Encryption method.
• Settings for SIM authentication, such as the International mobile subscriber identity (IMSI).
• Trust certificate for EAP-TTLS and EAP-TLS.
• Username/Password for EAP-TTLS.
• Digital device certificate and security key for EAP-TLS.
• Passpoint-specific settings such as Roaming Consortium Organization Identifiers (RCOIs). More about this is below.
• Authentication settings, including the EAP method.
• Connection preferences.

These profiles can allow devices to automatically connect to known networks without requiring users to manually enter credentials each time. A typical example is SIM authentication for automatic authentication of users.

To support Wi-Fi offloading, the Wi-Fi connection profile can be provisioned from the factory or added over the air through Apple’s carrier settings and similar mechanisms for Android phones.

For other types of devices and Wi-Fi-only devices, the Wi-Fi connection profile can be provisioned through an app. The recommended approach is to integrate a Software Development Kit (SDK) into existing applications, such as a service provider’s loyalty app, to implement this provisioning mechanism effectively.

Settings for Wi-Fi Offloading

Wi-Fi offloading using SIM authentication has always been secure, and the user’s automatic connection to the Wi-Fi network is seamless. To support this, there are some important settings in the Wi-Fi connection profile related to Wi-Fi offloading.

IMSI

The International Mobile Subscriber Identity (IMSI) is a numeric value composed of two parts <PLMN Id><MSIN>:

1. Public Land Mobile Network Identifier (PLMN ID): Uniquely identifies the individual mobile operator by their Mobile Network Code (MNC) and Mobile Country Code (MCC). The PLMN ID is of the format <MCC><MNC>; for instance, the PLMN ID for Swisscom with MNC 001 and MCC 228 is 228001.
2. Mobile Subscription Identification Number (MSIN): A unique identifier for the subscriber, such as 123123123.

The subscriber’s IMSI in the above example would then be 228001123123123. Mobile operators normally use wild cards in the Wi-Fi connection profile, such as 228001*, because it is enough to identify the PLMN ID in the Wi-Fi network selection process.

Realm

An NAI realm is the domain portion of a Network Access Identifier (NAI), which follows the standard syntax of “user@realm.” The realm specifies the domain or organization to which the user belongs, for instance, “enea.com.” The NAI realm is normally the same as FQDN and is used to find the authentication server.

The NAI realm field, when used for Wi-Fi offloading, has a specific format for 3GPP interworking. In this case, mobile operators use NAI realms that end with 3gppnetwork.org. For the interworking with Wi-Fi networks and the use of EAP-SIM/AKA/AKA’ and 5G-AKA authentication methods, the (NAI) realm field is of the format:

wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org

The individual mobile operator is uniquely identified by their Mobile Network Code (MNC) and Mobile Country Code (MCC). For instance, the NAI realm for Swisscom with MNC 001 and MCC 228 is:

wlan.mnc001.mcc228.3gppnetwork.org

For Wi-Fi offloading on their own Wi-Fi network, which does not require interworking with others, the operator may use another NAI realm format with a domain name they own.

SIM

This field is required for SIM based authentication (EAP-SIM/AKA/AKA′). The EAPType field must be set to the appropriate EAP type.

Settings for Passpoint

There might be some confusion about the terms Wi-Fi connection profile and Passpoint profile, but they are closely related. A Passpoint profile is the wire format of the device-specific Wi-Fi connection profile. When a Passpoint profile is received by a device, it is turned into a Wi-Fi connection profile specific to that device. Wi-Fi connection profiles can also be created through other means, for example manually configured or deployed using an app installed on the device. While Passpoint Release 1 defines the content of the profile, Passpoint Release 2 also standardizes the formatting of the profile with the intention to ensure interoperability across different devices and networks. Devices only supporting Release 1 have the same functionality, but uses a vendor-specific format.

Passpoint enables seamless and secure connectivity, just as SIM authentication does, and SIM authentication can also be used with Passpoint. Further more, Passpoint also enables seamless roaming as the device connects to a Wi-Fi service rather than a specific Wi-Fi SSID. Learn more in the upcoming post about Passpoint.

In a Passpoint profile, there are other parameters than SSID in play for the device to automatically identify and select the Passpoint-enabled Wi-Fi network. Once a device tries to connect, the NAI realm is used for finding the authentication server. As discussed, the NAI realm for Wi-Fi offloading is normally in the format wlan. mnc<MNC>.mcc<MCC>.3gppnetwork.org, especially for 3GPP interworking.

Network Selection for Wi-Fi Offloading in a Non-Roaming Scenario

• For SIM-based devices using EAP-SIM, EAP-AKA, or EAP-AKA′, the primary identifier is the IMSI. To streamline network identification, mobile operators often use a wildcard IMSI, such as 228001* for Swisscom, which denotes the operator’s unique identifier (PLMN ID) without including the full subscriber-specific IMSI. During network selection, the device compares the PLMN IDs provided by the Wi-Fi access point via the Access Network Query Protocol (ANQP) with its stored wildcard IMSI (PLMN ID) associated with its SIM/USIM credentials. If a match is identified, the device proceeds with SIM-based authentication to establish a secure connection.
• For non-SIM devices using EAP-TLS or EAP-TTLS, the Fully Qualified Domain Name (FQDN) serves as the primary identifier for specific networks or service providers. To determine whether to connect, the device compares the FQDN stored in its Passpoint profile with the domain name list provided by the Passpoint Wi-Fi access point through the Access Network Query Protocol (ANQP). Service providers may advertise multiple domain names; for instance, a single provider might use names such as wlan.mnc410. mcc310.3gppnetwork.org, att.com, and attwireless.com. In addition to FQDNs, the device can utilize other identifiers, such as the NAI Realm or Roaming Consortium Organization Identifier (RCOI), to ensure accurate network matching.

Network Selection for Wi-Fi Offloading in a Roaming Scenario

The Roaming Consortium Organization Identifiers (RCOIs) in the Passpoint profile are used for devices to recognize and automatically connect to compatible networks for roaming.

One of the key advantages of Passpoint is that it doesn’t require all connectivity parameters to be embedded directly in the Wi-Fi access point beacon. Instead, the Access Network Query Protocol (ANQP) operates in the background, enabling devices to silently communicate and negotiate network details. For example, the shorter 24-bit base RCOI can be included in the beacon frames, allowing devices to quickly assess potential network compatibility before proceeding with a more detailed ANQP query that includes the full 36-bit RCOI list. Additionally, information like the Venue Info URL introduced in Passpoint R3 is also exchanged via ANQP, enhancing the user experience without overwhelming the beacon frames.

Another important Passpoint-specific parameter, introduced in Passpoint R1, is the Operator Friendly Name. It provides a human-readable name for the service provider, which helps users identify the network they are connecting to.

Wi-Fi Offloading Settings for OpenRoaming

With the OpenRoaming Passpoint service, identity providers (IdP) can roam with any access network provider (ANP) in the OpenRoaming federation.

An “OpenRoaming profile” is just a Wi-Fi connection profile with Passpoint and OpenRoaming settings.

Since OpenRoaming is a Passpoint service, all that is needed from a profile point of view is to add the required Roaming Consortium Organization Identifiers (RCOIs) for OpenRoaming to an existing Wi-Fi connection profile which has been adapted for Passpoint.

In the case of Wi-Fi Offloading with OpenRoaming Access Network Providers (ANP), must make some more adaptations outside the scope of the Wi-Fi connection profile. Learn more about this in the upcoming post about Wi-Fi offloading and OpenRoaming.

Wi-Fi Network Selection

The device’s ability to select the right network is critical for optimizing Wi-Fi offloading. The good news is that modern devices, such as iPhones and Android phones, employ sophisticated algorithms to determine whether to connect to a Wi-Fi network or remain on the cellular network, balancing factors such as signal strength, network performance, and user preferences. It is no longer the case that devices blindly prefer Wi-Fi over cellular networks. If the cellular connection performs well, the device is less likely to switch to Wi-Fi unless the user has indicated that they prefer Wi-Fi, e.g., by selecting Wi-Fi manually.

It should be noted that while iOS has a consistent behavior, Android devices may have smaller differences in behavior across different OEM vendors.

Wi-Fi Network Discovery and Evaluation

When a device detects available Wi-Fi networks, it initiates a multi-stage process to evaluate and select the most suitable network:

1. Network Discovery: The device scans for available Wi-Fi networks within range.
2. Attribute Collection: For each detected network, the device collects key attributes such as signal strength (RSSI), supported Wi-Fi standards, frequency band, and security type.
3. Network Filtering: The device filters out networks that don’t meet minimum requirements, such as those with signal strength below a certain threshold.

Wi-Fi Network Selection Criteria

Devices consider multiple factors when selecting a Wi-Fi network:

• Signal Strength: Networks with stronger signals are enerally preferred.
• User Preferences: Networks manually selected by users receive a higher score in future selection processes. Manually disconnected networks get a lower score.
• Frequency Band: Due to their higher performance capabilities, 6 GHz and 5 GHz networks are typically prioritized over 2.4 GHz networks.
• Security: WPA Enterprise has the highest priority, and WPA Personal networks are favored over less secure options.
• Previous Connections: Networks that the device has successfully connected to in the past are given higher priority.

If multiple Passpoint Identity Providers (IdPs), responsible for authenticating the user for Wi-Fi access, are configured in the Wi-Fi connection profile, the Home Service Provider will be prioritized.

Seamless Access with SIM Based Authentication

A key component of Wi-Fi offloading is SIM-based authentication, which provides a seamless, secure Wi-Fi experience comparable to cellular networks. This section will examine the mechanics of SIM authentication from a standards perspective. The 3GPP AAA server plays a central role in SIM authentication for 3G, 4G, and 5G networks using the 5G non-standalone architecture (5G NSA), which relies on the existing Evolved Packet Core (EPC) from 4G. However, as we will discuss later, real-world implementations often require capabilities beyond the standard 3GPP AAA function.

The 5G standalone architecture (5G SA) introduced some changes to how SIM-based authentication works for Wi-Fi access (untrusted and trusted non-3GPP Access) compared to previous generations. In 5G SA, no 3GPP AAA server is specified. Instead, the authentication process for Wi-Fi access using SIM credentials is more tightly integrated with the 5G core network and distributed across multiple core network components. Looking ahead, the 3GPP AAA may evolve into a comprehensive bridging function, providing unified management for Wi-Fi access across all generations of cellular networks. SIM Authentication for Wi-Fi Access in 3G, 4G and 5G NSA

The 3GPP AAA server, exemplified here by the Enea Aptilo SMP, plays a crucial role in SIM authentication for 3G, 4G, and 5G NSA networks. It securely manages the authentication process by integrating with the mobile core to verify the device’s credentials. Free Wi-Fi at restaurant SIM Authentication for Untrusted Wi-Fi Access in 3G, 4G and 5G NSA Networks

Untrusted non-3GPP Access is used for Wi-Fi networks that the mobile operator does not trust. This is why this is the access method of choice for Wi-Fi Calling, which must be available wherever there is a Wi-Fi network. Note that the 5G non-standalone (5G NSA) networks use the same mobile core (EPC) as 4G.

The user device is already assumed to be onboarded to the Wi-Fi network, for instance in a home, office or public hotspots. So, SIM authentication has nothing to do with security or login to the Wi-Fi network. Instead, SIM authentication is used to authenticate and authorize the user device to access the mobile core through an IPsec tunnel. The keys for setting up the IPsec tunnel are derived from the SIM authentication process.

EAP SIM-AKA in 3G/4G/5G NSA untrusted 3GPP access (Wi-Fi)

Trusted secure Wi-Fi. SIM Authentication for Trusted Wi-Fi Access in 3G, 4G and 5G NSA Networks

In Wi-Fi networks, the 3GPP AAA serves a dual purpose for trusted non-3GPP access.

The user gets internet access through the local gateway, as shown in the picture below (the most common scenario). The traffic can also be backhauled to the mobile core using the 3GPP-specified trusted WAG/TWAG gateway functionality with an optional local traffic breakout.

EAP SIM-AKA in 3G/4G/5G NS trusted non-3GPPP access (Wi-Fi)

SIM Authentication for Wi-Fi Access in 5G SA

Today (November 2024), relatively few 5G networks (50-60 networks) are utilizing the 5G standalone (5G SA) architecture, but this architecture will grow in importance over time. The authentication process for non-3GPP access, such as Wi-Fi, is more unified with the cellular authentication process, which introduces new technical challenges. One of these is how to be able to use Non-Access Stratum (NAS) signaling over Wi-Fi. The EAP-5G protocol has been introduced to encapsulate NAS messages to go over Wi-Fi through an IKV2 connection. So, EAP-5G is not an authentication protocol, which can be a bit confusing at first look. SIM Authentication for untrusted Wi-Fi Access in 5G SA Networks

The principles are the same as for untrusted Wi-Fi access towards the Evolved Packet Core (4G/5G NSA). The user is assumed to be already onboarded to the Wi-Fi network, and security is enforced by having an IPsec tunnel between the device and the mobile core.

EAP-SIM in 5G standalone architecture for untrusted 3GPP access (Wi-Fi)

SIM Authentication for Trusted Wi-Fi Access in 5G SA Networks

The authentication process is very similar to the process for untrusted Wi-Fi access, with some important exceptions:

EAP-AKA in 5G-standalone architectures for trusted 3GPP access (Wi-Fi)

Bridging the 3GPP Standard with Real-World Solutions

While the outlined flows above reflect 3GPP standards for SIM authentication, practical network implementations often favor pragmatic, hybrid approaches due to existing network design, equipment and investments. In real-world deployments, the RADIUS protocol—widely used in Wi-Fi and various gateways—will likely continue to play a significant role alongside emerging 5G standards and protocols.

Historically, many 3GPP-specified interworking gateway functions for Wi-Fi (non-3GPP Access) have not seen widespread adoption for Wi-Fi offloading. For example, in 4G with the Evolved Packet Core (EPC), the tunnel-terminating ePDG gateway has primarily been used for Wi-Fi Calling rather than Wi-Fi offloading. Wi-Fi Offloading

Unified SIM-authentication for 3G, 4G,5G NSA and 5G SAFor Wi-Fi offloading in trusted Wi-Fi network environments, there has been limited demand for the WAG/TWAG to backhaul traffic to the EPC mobile core. In fact, the vast majority (around 90%) of Enea’s Wi-Fi offloading customer deployments opt to route traffic directly to the internet via a non-3GPP gateway, bypassing the mobile core. We foresee a similar trend in 5G SA, with a strong preference for local traffic breakout. Backhauling traffic through the mobile core only offloads the radio network (RAN), while local breakout delivers a more efficient solution by directly handling traffic at the edge.

In this context, the 3GPP AAA is expected to evolve and take the role of SIM-based authentication (control plane only) also in 5G SA, effectively offering a unified SIM authentication function across all generations of cellular networks. This evolution would give mobile operators a streamlined and pragmatic architecture, capable of handling SIM authentication seamlessly across both 4G and 5G core networks. Wi-Fi Calling

For Wi-Fi Calling utilizing untrusted Wi-Fi access in 5G SA, the N3IWF function will still be required. One potential scenario is the adaptation of the 3GPP AAA function as a “bridging function” within the authentication flow for Wi-Fi Calling. Mobile Network Operators (MNOs) often prefer leveraging established, proven technologies over quickly adopting new standards when practical alternatives exist. It’s important to note that the N3IWF is only a reference in the 3GPP standard and not a specific gateway product. An adaptive authentication server (3GPP AAA), like Enea’s Aptilo SMP, could potentially evolve to integrate with the 5G SA core for control plane authentication while the existing ePDG gateways manage the N3IWF roles within the traffic plane. The same scenario could also happen for trusted access, with the existing WAG/TWAG gateways taking over the TNGF/TWIF functions in the traffic plane. These scenarios would require cooperation between the 3GPP AAA and gateway vendors.

Wi-Fi Offloading, How? – Chapter 2.1

White Paper: Wi-Fi Offloading, How?

This is an excerpt from our white paper, Wi-Fi Offloading, How?,  a technical deep dive into deploying Wi-Fi offloading solutions. If you like what you read, download the full white paper. As a bonus, you’ll also gain access to Wi-Fi Offloading, Why?, outlining the business benefits for mobile operators.

DOWNLOAD    INSIGHTS    CONTACT US

When you switch on a brand-new cellular or wired IoT device, it can be bootstrapped to connect to a provisioning server immediately. The IoT connectivity is secure and seamless from the moment the device is switched on.

This is not the case with Wi-Fi-based IoT devices. We have all tried to onboard these devices to the Wi-Fi network using an app, QR code, or Bluetooth, which may be okay for consumer devices. But what about industrial and enterprise use cases with thousands of devices? The onboarding issue is currently the largest showstopper for a mass market of Wi-Fi-based IoT devices.

At Enea, we have tried to solve this with the Zero-touch Wi-Fi IoT onboarding invention utilizing the already installed device certificates. The idea is excellent, but it requires industrywide acceptance and deployment. This was before OpenRoaming.

We now see the potential in using OpenRoaming to make Wi-Fi IoT onboarding as secure and seamless as Cellular and Wired IoT. It is a complex task with many use cases, and it may require a separate base RCOI for IoT and a different set of CAG policies. But it can be done.

Update March 2024

The FIDO Alliance is leading the way in automatically onboarding IoT and headless devices. They have a well-thought-out process with their FIDO Device Onboard (FDO), an automatic onboarding protocol for edge nodes and IoT devices. FDO enables late binding of device credentials so that one manufactured device may be onboarded to many different cloud and edge management platforms. But to perform this late binding of credentials, the device needs connectivity to reach a so-called Rendezvous Service. This works well for wired and cellular devices that get connected when powered up but not for Wi-Fi-based IoT devices.

We are happy to announce that Enea and Intel have taken the initiative to form a working group within WBA called OpenRoaming & FIDO Device Onboarding with the mission to use OpenRoaming for a zero-touch connectivity for Wi-Fi-based IoT devices. The work is still in its initial stage,  the goal is to make FDO as seamless for Wi-Fi as it is for fixed and cellular.

In previous articles we have talked about the critical nature of AAA / Access Manager and why the functions remain at the core of telecom services. Enabling Voice over Wi-Fi for a telecom operator is a case in point; this is also called Wi-Fi Calling, but for the rest of this article the label VoWiFi is used. At a simple level it enables telephony services over available Wi-Fi access points. In effect, Wi-Fi Calling links telephony from a telecom operator to an internet environment, so you can make, answer, and maintain calls seamlessly when moving in and out of Wi-Fi and mobile networks.

VoWifi provides for low-cost coverage expansion of voice communications for Telcos to create and maintain reliable voice connectivity using pre-existing Wi-Fi access/IP connectivity. It is complementary to voice over LTE (VoLTE) but different, in that it uses Wi-Fi access points not LTE. The business case for this is driven by:

• Necessity – disabling older circuit switched technology
• maintaining quality of experience for voice calls
• creating new service offers such as sponsored roaming.

In a world of apps, it may seem old fashioned, but making a phone call (and expecting it connect reliably and with quality) is still what customers do. A USwitch^[1] survey in the UK rated phone calls as the third most popular activity (73%) (just behind messaging (78%) & email (74%)). Long call or short call it doesn’t matter – if the call quality is bad, users blame the network and there is plenty of choice if they want to switch networks. Voice quality and coverage is also a key factor on network assessment with leaders in testing like Umlaut^[2] in their ‘Walk tests’ in big cities, or RootMetrics Call Performance tests.^[3] Further, it can also be a misconception that coverage issues will be fixed by 5G – as 5G is a mix of radio technologies and pure 5G frequencies can be more affected in dense urban areas.

The voice use case matters for a third reason – a strategy to provide more capacity cost effectively is needed to meet the increasing data demands of the network. An integrated Wi-Fi solution is a building block of that strategy, in urban scenarios; data follows voice and integrating access for mobile and IP networks provides seamless, cost effective, capacity expansion.

The core case for VoWiFi is maintaining the quality of connection. In areas where circuit switched is being disconnected it is essential to link IPv4/IPv6 IMS to HSS authentication and this the role played by the AAA / Access Manager. Working in collaboration with a Telcos’ entitlement services, on device application and packet gateways the access management authenticates the IP telecom access for a voice call using the SWa | SWm diameter protocol to the request received from the evolved packet gateway (ePDG). The response from access manager contains the right authorization and additional attributes so that access is authorized. The additional attributes can be used to create different offers based on geo location and sponsored data/voice roaming for example – enabling new monetization options.

What Enea is doing is solving this use case and more across AAA / Access Manager deployments directly and with our partners. Enea provides AAA / Access Manager as virtualized software (VNF | CNF) increasing the cost benefit of capacity expansion for VoWiFi. The Access Manager has been deployed in more than 40 Operator networks including several large Tier 1 Telecom Operators. It has demonstrable interoperability across a wide range of interfaces and solution use cases.

For more information

https://www.enea.com/solutions/data-management-applications/access-management-aaa/

References:

[1] USwitch Survey 2023 – https://www.uswitch.com/mobiles/studies/mobile-statistics/

[2] Vodafone Umlaut tests https://www.vodafone.co.uk/cs/groups/configfiles/documents/document/umlaut-connect-benchmark-2022.pdf

[3] RootMetrics – UK test: https://rootmetrics.com/en-GB/rootscore/map/nation/england/2023/2H

Today, at World Wi-Fi Day, we remind ourselves how Wi-Fi has played a transformative role in bridging the digital divide worldwide. Wi-Fi can also help save our planet. With its localized transmission, lower signal strength requirements, and power-saving features, it is a greener alternative to cellular and beneficial for the environment we all care about.

We all know that it is the relatively small initiatives that sum up to deliver a significant positive environmental impact. One of those initiatives is our new purpose-built database, released in Enea Aptilo SMP 5.6, which we have optimized for our platform. As we celebrate World Wi-Fi Day, we have received reports from some of our customers showing the extreme efficiency gains when going from a general-purpose database to our new database, which we have purpose-built for the telecom use case.

Less than half the number of Enea Aptilo SMP servers needed to perform the same job

One of our customers has reduced the number of server nodes from 10 to 4 while still performing the same job. Furthermore, each node also has significantly less memory and CPU utilization. This correlates well with stress tests in our labs, where we have simulated 16 million accounts with heavy database activity. The CPU utilization was down by a factor of ten going from 300% to 30% (Three cores running at 100% to one running at 30%).

It is fantastic and surprising how a few skilled software engineers can fundamentally impact energy consumption. And this is just in the daily operation of the machines. Add to this the energy and overall environmental cost of manufacturing and distributing twice as many servers.

We challenge our industry and all other industries to make the same effort. Together, we can help save our environment bit by bit, day by day, leaving a better world for our children.

Is the green agenda another reason for the sudden surge in interest in Wi-Fi offload?

In our recent blog post – Wi-Fi Offload 2.0 – Why a Surge in Interest Right Now? – we attributed the reason for operators’ increasing interest in Wi-Fi to the paradigm shifts in Wi-Fi technology and the urgent need for additional capacity and indoor coverage. But maybe there is also a green agenda behind this interest. With offloading, operators are saving costs on equipment and energy consumption. This means they can better fulfill their commitments to their Environmental, social, and corporate governance (ESG) agendas.

We are committed to ensuring that Wi-Fi and Cellular coexist to bring the best user experience and save the environment any way we can.