Does anyone know when is MikroTik going to implement BandSteering?
Meaning, equipment with dual band operation (both 2.4 Ghz and 5 GHz) detects clients capable of 5 GHz operation and steers them to that frequency which leaves the more crowded 2.4 GHz band available for legacy clients.
Client decides where to connect. Set a preferred band to your clients.
Ubiquiti has implemented this a long time ago.
At most the AP can kick the client from (say) 2,4GHz - and hope it connects again with 5Ghz. But that’s about it: it can only hope. In the end, the client decides which frequency it will use.
There is more that the ap can do than hope.
What happens if it simply only responds to beacons on 5g and not 2.4g for example. How could client connect to 2.4g?
And thats exactly how it works…
I hope Mikrotik implement this soon, its causing us a lot of issues on our large deployments.
What kind of clients don’t do this by default? At least Apple devices and modern Windows laptops always prefer 5GHz by themselves. Client decides these things, but if you want to FORCE something else, you can use the Access List settings and set required signal levels etc.
There’s a bit more to band steering than “just” kicking clients off 2.4GHz.
One of the first good things to have would be control of the beacon rate. Not only for band steering. When I deploy large scale (and I mean LARGE) WiFi networks, I already increase beacon intervals to free up more air time. For example setting the 2.4GHz beacon to 152ms and the 5GHz to 120 would make dual-band capable clients see the 5GHz beacon earlier.
Additionally, the band-steering capable AP sees the same client MAC address concurrently probing at 2.4 and 5GHz - so it would not respond to the 2.4GHz probe once it discovered the same MAC address on the 5GHz band. And that’s nothing that can be done with access lists.
Having these two options in routerOS, together with 802.11r and 802.11k, it would enable much more use cases.
Just my two cents,
-Chris
Thank you for the clarification.
How different beacon intervals can assure that one will be always before another if none knows when a client starts to scan and at what frequency it will be and how long he will be scanning before he decides to select an ap to try to connect?
This only increases the statistical chance of the client choosing 5Ghz. It can, still, chooses 2GHz.
Assuming that:
The idea of not responding in 2GHz, once found in 5GHz, is an interesting one.
In reply to Jarda and Paternot,
I can only tell from my experience that it seems to work.
Sample for beacon rate (which I totally agree that the impact is highly statistical):
Two days in the same location: about 25’000 clients connected concurrently, day one with identical beacon intervals: roughly about 50% on 2.4GHz.
Day two, same clients, with adjusted beacon intervals about 25% on 2.4GHz.
And for the statistical chance: It might not be that important with just 500 clients on 5…10 APs but it becomes really important when dealing with about 60’000+ clients on a couple of hundred APs. (Which I do on a very regular basis)
Everything about band steering that is done on AP- or manager/controller-side is more or less guessing and deep analysis of the air - since it is not covered in any 802.11 standard, every vendor is brewing their own ideas and make it a huge secret - some do better, some do it not so well. I’ve seen them all and it’s basically all about MAC addresses on bands - getting better when levels come into the game as well.
-Chris
You can’t be assured [ie 100% certain], but you don’t need to be. It just needs to work the majority of the time, and it will help.
Android has no “prefer 5 GHz” option, it will pick whatever it likes unless you completely disable 2.4 GHz. Android is the most popular OS by far, Windows laptops and Apple devices are very much a minority in the world of devices today. Using access list and signal levels is not a clean solution, since it forcibly disconnects the client which can interrupt downloads, streaming, etc.
Band steering as implemented by most vendors hides the wireless SSID from beacons. When the client wants to connect, it initiates a probe request on both radios. The AP sees the request come in on both radios, and responds with the probe response on only the 5 GHz radio. The client now has enough information to associate with the 5 GHz radio and does so. The downside to this approach is that it impacts how quickly the client can connect or roam when you enter the range of the AP. Since the client must actively scan for networks, it cannot simply passively listen and connect as soon as it sees a familiar SSID in the beacon. This is also a minor benefit, since it means the client is more likely to be in range of both radios before probing.
i think the exact definition is “probe requests” not beacons
i think the beacon interval option its a good idea and maybe the easiest to implement
+1 for tunable beacon intervals (better than nothing) .. I dont know if it’s already in feature requests, but it should be
+1 !!!
yes band steering is a very important and useful feature implemented in most vendors in wifi
airtime fairness is another important feature
even brands like tplink already offer it
We implemented mikrotik at busy airport in India and facing the slow speed issue for Android mobiles on 2.4 . Normis please implement this band steering asap it Will be really helpful to tackle high 2.4 interference zones. Here 80% use Android