White Paper Excerpt
A Pragmatic Approach to Passpoint
In our previous post about Secure and Seamless Carrier Wi-Fi Services with Passpoint, we explained the differences between the Wi-Fi Alliance Passpoint® versions (R1-R3) and the challenge at this point in time with sufficient device support for the latest releases, Passpoint R2 and R3. In this post, we will discuss how it is possible to overcome these challenges by taking a pragmatic approach to Passpoint, using the least common denominator Passpoint R1 and the Captive Portal API.
Wi-Fi in the 5G era – White Paper
This is an excerpt from our white paper Wi-Fi in the 5G Era – Strategy Guide for Operators. The full white paper is available here if you like what you read. Don’t hesitate to contact us if you have any questions.
At Enea, we strongly believe that standards drive down costs and improve the user experience. But, it is not enough if we in the telecom industry are ready for Passpoint R2 and R3, if the devices aren’t. It takes two to tango.
The Captive Portal API
The Internet Engineering Task Force (IETF) Captive Portal API (RFC8908 and RFC8910), introduced in September 2020, is a game-changer.
The Captive Portal API does not only improve the user experience in connection with traditional Captive Portal implementations. We believe that the Captive Portal API – in combination with Passpoint R1 – has the potential to deliver much of the user experience that Passpoint R2 and R3 were designed to accomplish.
The adoption of Captive Portal API among handset manufacturers has also been fast. Google was first to support the Captive Portal API for Android 11, and Apple soon followed with support in iOS14 and macOS Big Sur. With a critical mass of supporting devices, adoption across all the major operating systems appears imminent.
The Captive Portal API gives service management platforms, such as the Aptilo Service Management Platform™ (SMP), greater control of the Captive Portal flows for traditional hotspots. As a result, users will experience a more reliable service than ever before.
The overall user experience will also benefit hugely from the Captive Portal API. We have traditionally designed Access Gateways to intercept the user web request and redirect it to a Captive Portal. With the Captive Portal API, the gateway does not need to intercept such requests. Instead, when users join the Wi-Fi network and receive an IP address via DHCP (or Router Advertisement in IPv6), the DHCP server also provides the URL to the Captive Portal API. This will trigger the device to query the API to determine whether it is in captive mode, which is the state of captivity when device does not have access to internet. If the device is in the captive mode, it will open the captive portal for the user to perform login or sign-up. Devices that support the Captive Network Assistant (CNA) browser will open the captive portal on the CNA browser. If the API says the device is not in captive mode, the device will proceed directly to the Internet.
It takes time for new standards to be natively implemented in every device, so there might be some details in the Captive Portal API that still needs to be implemented for some devices. However, the standardized interaction between the device and the captive portal, as defined in the Captive Portal API, is always there to help devices determine their state and auxiliary information, such as the remaining session time or data. This allows the device to take action before it reaches the time or data limits, allowing the user to extend the session in a controlled way. This provides a smoother interaction between the device and the Wi-Fi service management system. Previously, with the guesswork of device-only captive portal detection and system-only control, the device was unaware of what was happening after authentication. This could cause sessions that appear to freeze after the session time or data has run out.
Venue Info URL
Another benefit of the Captive Portal API is that it can also provide a Venue Info URL. This excellent feature allows service providers to empower their B2B customers to engage with users locally with information and offers. In current implementations, the user receives the link to the Venue Info URL via an on-screen system message appearing as a text alert available during the session. The message remains on their lock screen and in their message history. This makes it easy to go back to the Venue Info URL, as the message history is typically just a swipe away.
The Venue Info URL will appear when the user connects manually by selecting an open SSID or automatically through a secure Passpoint-enabled network. It will also offer otherwise anonymous Network Providers a way to show local information and customized advertising to users that connect through, for instance, OpenRoaming or Orion WiFi, described later in this paper.
To offer the user a portal experience like this on a secure SSID is something new to ensure venue owners can engage with users. This is crucial for making secure Wi-Fi the norm rather than the prevalent open SSID.
A Pragmatic Approach Building from Passpoint R1
We believe that the Captive Portal API, in combination with Passpoint R1, can deliver much of the user experience that Passpoint R2 and R3 were designed to accomplish.
It would make no sense to build special signup flows for the few devices that support an end-to-end Wi-Fi service based on Passpoint R2/R3. Why not use the R1 support as the least common denominator?
Devices that have not yet been provisioned for Passpoint R1 by other means, such as through a SIM profile (EAP-SIM/AKA) or App (EAP-TLS/TTLS), have to be provisioned ad-hoc through a sign-up portal over an open SSID or in advance via another connection.
The user will then download and install the Passpoint profile on their device. For Android phones, it is as easy as a click on a link and confirm installation, whereas users of other devices, such as iPhones, may need support from device-specific instructions at the portal before download. Once the Passpoint profile is installed, we will restart the Wi-Fi connection. When the device re-connects, it will be logged in to the secure SSID (802.1x) stated in the Passpoint profile. The Captive Portal API can then be used for approval of terms and conditions for new users or existing users if there is a need for an update. The Venue Info URL can also optionally be used to display venue-specific information and promotions.
Add Passpoint R2-R3 Later
Support for Passpoint R2/R3 can be added later when a critical mass of device support has been achieved.
Note that we have moved the approval of terms and conditions from the sign-up page to the first connection on the Passpoint-enabled network. This means that the process can also be used for already provisioned devices and devices with Passpoint R2 support, as well as the large volume of devices that only support R1. Users of Passpoint R1 who sign-up at the site will see this as almost one flow since the connection can be terminated right after a user has installed the profile. A user will then immediately return as pre-provisioned.
Online signup through the R2 online signup server (OSU) has many benefits to users once there is sufficient device support.
It remains to be seen if the benefits of Passpoint R3 terms and conditions and user engagement features will be significant or if it would be more beneficial to use the same processes as with Passpoint R1/R2 capable devices (dotted line in the figure).
