5G SBP Use Case - WOX Gateway

5G SBP Use Case - WOX Gateway

Use this template to submit Use Cases for submission to the 5G Super Blueprint Use Case & Requirements Advisory Group. All input marked Mandatory is required for the blueprint use case proposal to be deemed ready for review by the Use Case & Requirements Advisory Group.



Use Case Name:

Wi-Fi Offload eXperience Gateway (a.k.a. WOX Gateway)

Use Case Name:

Wi-Fi Offload eXperience Gateway (a.k.a. WOX Gateway)

Use Case Description:

Cellular operators want increased visibility and control of Wi-Fi offload networks to allow a quality of experience aware convergence between operator owned cellular networks and 3rd party owned wi-fi offload networks. 

Today Wi-Fi offload is a black box scenario for cellular carriers. Wi-Fi networks offer no quality Key Performance Indicators (KPIs) or if they do it’s in a proprietary format and data set. This fragmentation reduces offload logic to the lowest common denominator in production systems (often yes/no decision), given the diversity of Wi-Fi OEMs a single carrier may use when offloading.

The WOX Gateway solves this problem by ingesting standards based quality information from both cellular and Wi-Fi infrastructure. The WOX Gateway is a RADIUS proxy server which sits between the operator AAA server and the offload network. Using the quality information for both networks, and its proxy position in the RADIUS session flow, the WOX Gateway can Accept or Reject Wi-Fi offload sessions using advanced quality of experience aware logic.


Simply, while the AAA server answers CAN a user connect to an offload network, the WOX Gateway answers SHOULD a user connect to that network.

-Epic

-Problem Statement

-Epic

Build a quality of experience aware gateway appliance to allow advanced logic to used when approving or rejecting Wi-Fi offload sessions. 

-Problem Statement

Today’s Wi-Fi offload networks are simplistic and do not protect operator customers from poor user experience. Carriers need a tool that is quality aware and able to compare different access network options and make the choice which will be better for the end user. 

Blueprint Owner

Helium (Mario Di Dio & Joey Padden)

Users Stories



End user (Accept): An end user for a cellular carrier walks into coverage of a Wi-Fi network with Passpoint enabled to support their cellular carrier. The cellular network is either congested in this location or has low signal quality and the Wi-Fi network has ample un-used capacity and the user has good Wi-Fi signal quality, the end user is automatically connected to the Wi-Fi offload network.This connecting flow is transparent and seamless to the end user. 

End User (Accept): An end user for a cellular carrier walks into coverage of a Wi-Fi network with Passpoint enabled to support their cellular carrier. The cellular network and the Wi-Fi network quality metrics both report medium quality metrics in this location, but the Wi-Fi network is determined to be more likely to provide a good user experience. The end user is automatically connected to the Wi-Fi offload network. This connecting flow is transparent and seamless to the end user.

End User (Reject): An end user for a cellular carrier walks into coverage of a Wi-Fi network with Passpoint enabled to support their cellular carrier. The cellular network has high quality in this location, the end user is automatically blocked from connecting to the Wi-Fi offload network. This blocking behavior is transparent and seamless to the end user.

End User (Reject): An end user for a cellular carrier walks into coverage of a Wi-Fi network with Passpoint enabled to support their cellular carrier. The cellular network and the Wi-Fi network quality metrics both report medium quality metrics in this location, but the cellular network is determined to be more likely to provide a good user experience. The end user is automatically blocked from connecting to the Wi-Fi offload network. This blocking is transparent and seamless to the end user.

Operator User: The operator user has an interface which allows the configuration of the WOX Gateway policies and logic to be used when evaluating offload decisions. 

Operator User: The operator user has an interface which allows them to review KPIs, counters, and metrics to evaluate the efficacy of current policies configured in the WOX Gateway.

Wi-Fi Deployer: The Wi-Fi deployer user has an interface which allow them to review KPIs, counters and metrics to evaluate the performance of their deployments. Using this data they are able to self improve their deployments without direct input from the operator.

Interaction with other open source projects and components

The WOX gateway project will sit between Magma as a 3GPP core and the OpenWi-Fi platform which supports carrier offload via the Passpoint standard.

Resources -people



Resources (people) to execute on the blueprint:

  • Helium team will provide:

    • Project Manager: Joey Padden

    • Senior Developer: <resource TBD within Helium>

    • Developers: <2-3 developers as needed, resources TBD within Helium>

    • Lab Engineer(s): <resources TBD within Helium>

 Steps to Realization

  1. Scope and plan 3GPP metrics collection based on some combination of KPIs, counters and metrics defined in 3GPP TS 32.450 – 32.459, TS 28.552 and 28.554, TS 32.425. 

  2. Implementation of metrics collection in Magma using Baicells eNB.

  3. Implementation of API to expose collected 3GPP metrics to WOX Gateway. 

  4. Implementation of Wi-Fi metrics generation in OpenWi-Fi AP and insertion into RADIUS messages (Access-Request, Accounting Request (start, interim, stop)) based on WBA Access Network Metrics Phase 2 whitepaper and IETF AVP-77 Connect-Info specification.

  5. Implementation of generic RADIUS proxy capable of packet modification

  6. Implementation of example business logic module within RADIUS proxy governing packet modification.

  7. Implementation of quality based business logic module with configuration interface. 

  8. Documentation of WOX Gateway implementation, configuration, deployment, and operation.

High-level architecture diagram



High level lab topology diagram



Same as above

Dependencies - list of any dependencies that rely of future releases of a specfic component.



Yes
  •  

    • Enter details:

or

No

High-level timeline



  • Month that build can begin: September 2025

  • Approximate duration of build: 6 months

  • Approximate completion of outputs: February 2026

Upstreaming Opportunities



Cellular side:

  1. There is the opportunity to upstream code for Magma (likely in the enodebd service) which performs the collection KPIs and metrics from eNBs about user connection quality. 

  2. There is the opportunity to upstream code for Magma (likely in prometheus implementation) which aggregates and exposes, either via push or pull API, the aggregated metrics to external services e.g. WOX Gateway.

Wi-Fi Side:

  1. There is the opportunity to upstream the code in hostapd and/or radsecproxy or a third service used to inject quality metrics into RADIUS messages via AVP-77 Connect-Info per IETF standard.

Blueprint Outputs 

(Suggested. Not all may apply)

check all that apply:

Code repository
Configuration files (e.g. Helm charts, etc.)
Upstreaming to relevant projects 
Continuous Integration
Test requirements and test results (if applicable)
Documentation:
Overview and Theory of Operation (i.e., what does it do?)
Deployment and setup
Videos
demo
lab setup/behind the scenes
other

Links to existing documentation (Build Guide, Slideware, etc), if available.



Links to existing demo/video, if available.



Links to existing code/repos, if available.