WBA/IETF Connect-Info Implementation under way

[Joey Padden]

Hi Jouni, 

Thanks for the input. 

I misspoke earlier, the two files referenced are new files we are going to contribute. Their function is (and in part responsive to some of your concerns) to perform collection of the metrics at periodic intervals and perform aggregations (e.g. averaging, min/max functions or similar). As you pointed out, single values of many of these metrics are not terribly useful. However when periodically collected and aggregated they can provide useful information to Wi-Fi roaming partners. Taking that one step further, if the roaming partner collects metrics across many connected user sessions, the bulk of data provides very rich and useful information for the roaming partner. 

To step back a level, the primary goal of adding these parameters to Connect-Info is to allow a carrier (MNO or MVNO or WBA IDP) who supports Wi-Fi Roaming either via Open Roaming or direct peering, who doesn't have a priori knowledge of each deployment their customers may use, to gain insight into the quality of experience offered by a given Wi-Fi AP. The Carrier can then use this information to make informed decisions about if/when/how to offload a customer to this network using RADIUS. As the RADIUS connection is already there for Authentication and Accounting, and because RFC 2865 defines Connect-Info as "This attribute indicates the physical connection details or modulation used by the user’s session.” the WBA Access Network Metrics group has been working to define syntax and best practices for using Connect-Info to communicate “physical connection details” back to the roaming partner. 

In taking this approach (standardizing syntax, offering a patch to the wildly popular hostapd project) we aim to avoid proprietary quality KPI formats and interfaces (e.g. the Cisco flavor, and the Aruba flavor, and the Ruckus flavor etc.) and can align how these metrics are collected and communicated. This makes the metrics significantly more useful for carriers as they can implement ingest and processing flows once and then support metrics coming from a heterogeneous set of OEM equipment.

Hope that helps provide more context for the work we are doing.

When you referenced “the upstream project” which project are you referring to? 

Best Regards,
Joey 


> On Oct 6, 2025, at 3:13 PM, Jouni Malinen <j at w1.fi> wrote:
> 
> On Mon, Oct 06, 2025 at 10:28:29AM -0600, Joey Padden wrote:
>> We are implementing Wi-Fi Quality metrics in RADIUS AVP 77 Connect-Info following the WBA Access Network Metrics group and IETF draft linked here.
>> 
>> https://datatracker.ietf.org/doc/draft-grayson-connectinfo/  
> 
>> Initial investigation suggests we’ll be editing the following files primarily for metric collection and aggregation functions. We expect this work to produce a PR for hostapd project in approximately 1 month. 
>> 
>> src/wifi_stats/wifi_stats.c
>> src/wifi_stats/wifi_stats.h
> 
> Those files do not exist in hostap.git, so I'm not sure what this part
> is about..
> 
>> other small changes in other files to integrate it to hostapd config and radius functions.
> 
> That sounds more applicable to the upstream project..
> 
>> Wanted to share here to solicit any input / collaborators while we develop this. Also want to know if we are duplicating any effort as we start… not after a month of effort.
> 
> If this is really expected to be a month of effort, I'm not sure what
> exactly this would include since implementing a reasonable subset of
> what is defined in the referenced draft would sound more like something
> that would need an hour or two to implement in hostapd.. Maybe I'm
> missing something here about the scope of work especially with those
> references to wifi_stats.c.
> 
> I'd recommend working in smaller pieces and sending out contributions
> when each such piece is complete if this is indeed going to be a month
> of effort.. I'd start with the WIFIGEN extensions and use of
> WFA-GEN-NAME. That's something I can easily see justifiable for the
> Connect-Info attribute.
> 
> It is quite a bit more difficult understand why the Connect-Info
> attribute would be an appropriate location overall channel conditions
> like RSSI and noise and even some of the per-device specific items like
> TxBitRate/RxBitRate to report TX/RX rate of a single frame (and also
> noting that TX retries of a single frame might use different rates) do
> not feel like something I would add into this RADIUS attribute. If you
> are planning to contribute support for those, I'd suggest leaving those
> to the end of the set of patches since the likelihood of getting those
> accepted is quite a bit smaller than the items that I can understand
> making sense in this particular RADIUS attribute.
> 
> -- 
> Jouni Malinen                                            PGP id EFC895FA