Band steering feature status

Hi,

There are quite many band steering, fast roaming, 802.1k/r/v related topics already with their own specifics but I'd like to ask please in more general:

  • there is usteer project which seems to be "official", what is the status please? there will be official band steering capability built into next major(?), minor(?) openwrt release? any ETA please? anyone has any insight please if and what and when it will provide?
  • there are user space projects like DAWN or rrm-nr-distributor and there is a commit saying:

hostapd: ubus: add notification for BSS transition response

To allow steering daemons to be aware of the STA-decided transition
target, publish WNM transition responses to ubus. This way, steerings
daemons can learn about STA-chosen targets and send a better selection
of transition candidates.

what are those steering daemons?

It is due to my ignorance but I cannot find any official steering related documentation. Is it just me, or is it a documentation gap and there is a built-in, dev supported official stuff, or commit is referring to the upcoming(?) official usteer, or referring to custom daemons like the mentioned ones above and that will stay as is (i.e. user space apps can utilize system tools (hostapd/ubus) features if they wish)?

what additional user space solutions are available and people are using, please? what are cons and pros?

1 Like

PR16873

1 Like

I am not aware of any plans at this point in time to make band steering part of the official baseline feature set. The usteer daemon is a paid development effort to implement band steering capabilities on OpenWrt, but afair it was not implemented with the goal to make it part of the next release.

But given that it exists now there likely will be some effort to either make it default or to at least make it a well integrated installable option. But no definite timeline or decisions for that.

3 Likes

Steering means that you guide the client to a new AP (or even force). In normal WiFi mode clients decide themself typically based on RSSI, which AP they use. Furthermore, there are different thresholds for doing searches and so on. A good source of information is Client Marshal Paper from Cisco. Typically, Cisco APs exploit the CSA feature to do steering (and that is a very fast steering) with a third radio for doing hearing map scans.

thanks @PolynomialDivision but I know what steering means :slight_smile: i was asking what are the available steering daemons or implementations the commit is referring to.

thanks @jow for reply.

@anomeome - so usteer is going to be a publicly available package? nice.

now, it would be great to understand what each solution can or cannot do on a wiki page.

802.11k/v

The environment steering is used might be the most important factor. And other important question is what do you expect from the service. Some explanation is found below.

The simplest example is when you have only one AP. In this case you may set both your BSS (the 2,4 GHz and 5 GHz one) to announce each other for the STA. From this information (neighbor report) the STA may only scan the announced freqs, hence it can decide faster if to roam. From the nr report the sta doesn't have to wait until a beacon on the channel since the nr includes the bssid, the first captured packet could be used for rssi estimation. In this example the neighbor report feature was introduced.

A bit more complex situation is having two APs. In this case reporting every bssid is a nice tactic. In this case (can be in the earlier also) you may want to decide when to roam the device. For eg. one AP has more load. To do this you can do active roaming, so the BSS can send roam request to the STA. The announcement of the APs can be done via multicast or broadcast. No scan is needed (or even not possible, if the APs are far enough from each other).

An even more complex situation is the one I am using my APs in. Currently ~300 students are in the five floor dorm, the peek is 400 devices (only in-house, other interference and networks are coming the street). We have 23 OpenWRT APs for now, the other ones are unmanaged SOHO ones. This situation is tricky, since broadcasting every APs bssid and channel information could fail. @PolynomialDivision mentioned an Apple issue where the devices only take care of the first nine element of the received nr list. (https://github.com/berlin-open-wireless-lab/DAWN/commit/97e5de157fdf99651e20b0b095ce551b6fc42bc8) To resolve this problem (if there will be no other/better solutions up until then) I may develop a scenner app, so every AP scan the spectrum for adjacent BSS-es in the early hours, and use the result as a base of the NR report. DAWN can can active roam requests.

As you see the required solutions for the not so uncommon but completely different solutions, multiple steering platforms (or multiple level of feature sets?) must be available in the future to fulfill every scenario.

Answering the opening question rrm-nr-distributor works almost fine. Its only capability is to distribute every SSID with bssid and channel information through multicast. The same SSID networks will announce their neighbors as they are found via the mdns queries. Nothing else is done! My observation is that having more than 15 APs in the network the mdns query via umdns slows done for some reason to tens of seconds. If you have a lots of APs, the whole nr list will be send to the STA which could handle it or not. For small networks it is a good choice in my opinion. It also announces the APs own but other BSS's information, so helping the passive steering process.

I've tried DAWN in the Spring. The one thing I can remember is the many warning messages in syslog for NULL MAC addresses. After that many commits were contributed to the project wit many fixes and features (for eg. support for multiple SSID).

I have not tried usteer (yet).

One possible solution for steering was not mentioned. It is the one that requires a centralized controller as the OEM APs does. It could solve some problems in middle sized infrastructures. Maybe a small dockerized python script would work or some contribution with openwisp. (Haven't tried openwisp yet, but is it planned in the near future)

About 802.11r:

It works for me. Here is my config: https://github.com/simonyiszk/openwrt-rrm-nr-distributor/blob/main/example_wireless_config (also has the lines for rrm-nr-distributor). The logs indicate that fast transition is used by most of the clients in my network. I think the others do not support 802.11r.
A thing that I cannot find in the topic is the detailed description and configuration for ft-over-ds. I want to use this feature, but cannot find anything about it. As I have a mgmt network for device-device communication like this, I may send the packet on that vlan, but is not the same vlan the STAs are in. Could it be a problem, I don't know. I also don't know which port or protocol it uses. In the Summer I've found something, but cannot remember right now.

The idea of an openwrt wiki page about this topic is gap filling. I am pleased to help where I can.

3 Likes

Yes, that was more like debugging for me with 802.11k. However, this should be fixed since we check now for client capabilities: https://github.com/berlin-open-wireless-lab/DAWN/commit/3ba0fa494718a4b59dbf0fe4bdb290e36bb22008
Currently, DAWN has issues with multiple APs. I will have a look again how to debug this.

It is a complicated topic, since you have to deal with different client drivers and with multiple APs... :wink:

But I can say one thing: "While working on those standards, I see how more and more client devices are capable of it and that those standards are continuously improved in OpenWrt!" :slight_smile: In the beginning I had not even a single device supporting fast bss transision. Now every Android device supports it.

So, using 21.02.0 instead of master... any chance to get a 1 AP setup to push clients from 2.4 to 5GHz?
Dawn, usteer, whatever: can it be done without extra pain?
I'm the only user, for the moment I kick myself from the low band using Luci when I see that video calls suffer because of interference / bandwidth and this works well.

give a try to DAWN for example:
opkg update && opkg install luci-app-dawn

sometimes it requires a reboot in my experience, then enable kicking option (if it is not already on). default settings works quite well and prefer 5GHz band. there is a dedicated DAWN thread.

1 Like

I did find many threads on DAWN, which one is best?
(in my case it seemed to work before the reboot and now it is spewing lua errors)

not sure which one is the best, but @PolynomialDivision (who is the dev) started the one in my first post recently.

1 Like