Page 1 of 1

Band Steering implementation?

Posted: Tue Nov 14, 2017 8:20 pm
by ionas
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.

Re: Band Steering implementation?

Posted: Tue Nov 14, 2017 9:34 pm
by jarda
Client decides where to connect. Set a preferred band to your clients.

Re: Band Steering implementation?

Posted: Tue Nov 14, 2017 11:36 pm
by ionas
Ubiquiti has implemented this a long time ago.

Re: Band Steering implementation?

Posted: Wed Nov 15, 2017 3:36 am
by Paternot
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.

Re: Band Steering implementation?

Posted: Wed Nov 15, 2017 8:02 am
by blingblouw
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?

Re: Band Steering implementation?

Posted: Wed Nov 15, 2017 10:47 am
by nz_monkey
And thats exactly how it works...

I hope Mikrotik implement this soon, its causing us a lot of issues on our large deployments.

Re: Band Steering implementation?

Posted: Wed Nov 15, 2017 10:50 am
by normis
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.

Re: Band Steering implementation?

Posted: Wed Nov 15, 2017 11:19 am
by cdiedrich
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

Re: Band Steering implementation?

Posted: Wed Nov 15, 2017 11:22 am
by normis
Thank you for the clarification.

Re: Band Steering implementation?

Posted: Wed Nov 15, 2017 12:56 pm
by jarda
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?

Re: Band Steering implementation?

Posted: Wed Nov 15, 2017 2:41 pm
by Paternot
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.
This only increases the statistical chance of the client choosing 5Ghz. It can, still, chooses 2GHz.
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
Assuming that:

1) The client probe both frequencies at the same time. I don't know if this is the norm or the exception.
2) The client chooses 5GHz over 2GHz. Time and again I see a client using 2GHz - even if crowded - instead of 5GHz. I had, in some cases, to disable the function that chooses based on quality signal - the client kept jumping between APs, without stopping on none. Samsung mobiles love to do this.

The idea of not responding in 2GHz, once found in 5GHz, is an interesting one.

Re: Band Steering implementation?

Posted: Wed Nov 15, 2017 3:04 pm
by cdiedrich
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

Re: Band Steering implementation?

Posted: Wed Nov 15, 2017 6:09 pm
by troffasky
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?
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.

Re: Band Steering implementation?

Posted: Mon Nov 20, 2017 2:42 pm
by R1CH
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.
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.

Re: Band Steering implementation?

Posted: Mon Nov 20, 2017 2:51 pm
by chechito
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?

i think the exact definition is "probe requests" not beacons

Re: Band Steering implementation?

Posted: Mon Nov 20, 2017 2:54 pm
by chechito
i think the beacon interval option its a good idea and maybe the easiest to implement

Re: Band Steering implementation?

Posted: Fri Nov 24, 2017 9:33 pm
by bajodel
+1 for tunable beacon intervals (better than nothing) .. I dont know if it's already in feature requests, but it should be

Re: Band Steering implementation?

Posted: Tue Nov 28, 2017 2:17 am
by chechito
+1 for tunable beacon intervals (better than nothing) .. I dont know if it's already in feature requests, but it should be

+1 !!!

Re: Band Steering implementation?

Posted: Tue Nov 28, 2017 2:24 am
by chechito
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.

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

Re: Band Steering implementation?

Posted: Sun Dec 03, 2017 10:13 am
by rogers3b2
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

Re: Band Steering implementation?

Posted: Mon Dec 04, 2017 9:40 pm
by chechito
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
which ap did you use in that project??

Re: Band Steering implementation?

Posted: Sun Dec 17, 2017 11:02 am
by rogers3b2
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
which ap did you use in that project??
We used 952 dual band ap that comes with sfp port.in our observation most dual band android phones first connect on 2.4 and later auto shifts to 5 band . we need steering so that phones with both bands connect only with 5 . Thanks

Re: Band Steering implementation?

Posted: Mon Dec 18, 2017 9:57 pm
by andriys
rogers3b2, what tx-power levels do you use? Making tx-power on 2.4G band lower then on 5G band may help a lot.

Re: Band Steering implementation?

Posted: Fri Dec 22, 2017 7:35 pm
by chechito
rogers3b2, what tx-power levels do you use? Making tx-power on 2.4G band lower then on 5G band may help a lot.
yes, some people call that "making organic 5ghz" but in some cases you need to lower 2,4ghz to levels as low as 5dbm, sacrificing too much coverage, only suitable for high density setups

Re: Band Steering implementation?

Posted: Fri Dec 22, 2017 7:51 pm
by anuser
rogers3b2, what tx-power levels do you use? Making tx-power on 2.4G band lower then on 5G band may help a lot.
It does. e.g. A room with 3x WAP AC and ~150 clients. I set 5Ghz at 23db and 2.4Ghz at 17db. This gives me ~2/3 of 5Ghz clients and ~1/3 of 2.4Ghz clients

Re: Band Steering implementation?

Posted: Fri Dec 22, 2017 8:16 pm
by andriys
in some cases you need to lower 2,4ghz to levels as low as 5dbm, sacrificing too much coverage, only suitable for high density setups
From my experience, the best working multi-AP setups is the ones where 2G coverage is as close to the 5G coverage as possible for each AP in the setup.

Re: Band Steering implementation?

Posted: Fri Dec 22, 2017 8:23 pm
by andriys
I set 5Ghz at 23db and 2.4Ghz at 17db.
Those values a way too high. For the best user experience the tx-power of your APs should never exceed the max. tx-power of your wireless clients, which lies in the range from 13dBm to 17dBm (depending on the channel) for an average smartphone or tablet.

Re: Band Steering implementation?

Posted: Sun Dec 24, 2017 4:24 am
by chechito
I set 5Ghz at 23db and 2.4Ghz at 17db.
Those values a way too high. For the best user experience the tx-power of your APs should never exceed the max. tx-power of your wireless clients, which lies in the range from 13dBm to 17dBm (depending on the channel) for an average smartphone or tablet.

thats the difference in tx power needed between 5ghz and 2.4ghz to make clients to prefer 5ghz "organically"


to avoid having to do that is that we require the mechanism of band steering

Re: Band Steering implementation?

Posted: Sun Dec 24, 2017 9:47 am
by andriys
I set 5Ghz at 23db and 2.4Ghz at 17db.
Those values a way too high. For the best user experience the tx-power of your APs should never exceed the max. tx-power of your wireless clients, which lies in the range from 13dBm to 17dBm (depending on the channel) for an average smartphone or tablet.
thats the difference in tx power needed between 5ghz and 2.4ghz to make clients to prefer 5ghz "organically"
That's clear. What I was trying to say is that setting power for 2GHz to 17dBm and then rising the power for 5GHz above that value is not the right way to go. Instead, one should set power for 5GHz to 15-17dBm and then lower the power for 2GHz below that.

Also keep in mind that tx-power for ac-capable chipsets means total power, whereas for non-ac-capable chipsets it means power per chain (see here), so tx-power=17dBm for a 2-chain 2GHz hardware actually means 20dBm total power.

Re: Band Steering implementation?

Posted: Tue Dec 26, 2017 8:30 pm
by chechito
I set 5Ghz at 23db and 2.4Ghz at 17db.
Those values a way too high. For the best user experience the tx-power of your APs should never exceed the max. tx-power of your wireless clients, which lies in the range from 13dBm to 17dBm (depending on the channel) for an average smartphone or tablet.
thats the difference in tx power needed between 5ghz and 2.4ghz to make clients to prefer 5ghz "organically"
... then lower the power for 2GHz below that.
coverage at that power level you suggest is very poor

because that we need other mechanism to steer clients toward 5ghz

Re: Band Steering implementation?

Posted: Tue Dec 26, 2017 9:56 pm
by andriys
coverage at that power level you suggest is very poor
Do you remember that wireless is a bidirectional thing? I mean not only your clients should hear your access point, but you access point should hear you clients too. And so "at that power level" you actually get the best coverage possible for ordinary clients (like smartphones, tablets and laptops); tx-power values above that level will make you clients show you 5 bars of signal level on a greater distance, but that will not make the coverage any better (in fact, it usually makes it worse).

This, of course, does not apply to situations where all your clients are Mikrotik (or other brand) CPE devices, which allow the max tx-power value to be adjusted to the same level as it is on your AP.

Re: Band Steering implementation?

Posted: Tue Dec 26, 2017 10:07 pm
by Petri
coverage at that power level you suggest is very poor
@chechito I can see you have long experience with MT, but this answer puzzles me. Wi-Fi connection is bidirectional. With high power levels the AP can be received over a long distance, yes. However, there is no way for the low-powered client to reply or even ack. Thus, the high power of the AP is useless, even though the nominal coverage is great. I would agree with @andriys that the power levels of the AP and the clients should be equal.

Physically the 5GHz is about twice the frequency of 2.4GHz. The attenuation grows in square of the frequency, so the received level of 2.4GHz is four times or 6dB higher than 5GHz. By lowering the transmit power by 6dB on 2.4GHz both signals are received at equal strength. Changing that to 7dB would make more clients connect to 5GHz unless they natively prefer 5GHz (like Apple iOS devices do for example).

High transmit power levels are useful for PtP and PtMP scenarios where you control both sides of the link. Even then you should set the transmit power to the same level.

Re: Band Steering implementation?

Posted: Wed Dec 27, 2017 8:17 pm
by chechito
i am talking about wifi for smartphones tablets and laptops no client device under control, low tx power on client devices, mixed devices, windows, mac, android, iphone

i have the following example in some project, a small building, 3 floor with 1 ap per floor, fortunately is a high density deployment, most user concentration was on floor 2 the AP location was intended to distribute floor 2 users between the avaliable AP, because the lack of band steering, i barely achieve the required coverage because i had to lower 2.4ghz radio tx power until i get better signal in 5ghz ssid than 2.4ghz ssid that way 5ghz capable wifi device prefer 5ghz ssid, the following power setting was needed,

FLOOR 1 (brick walls)
mapa piso 1.jpg
2.4ghz 12dbm setting effective power 15dbm
5ghz default (23dbm)

FLOOR 2 (open space less walls)
mapa piso 2.jpg
2.4ghz 2dbm setting effective power 5dbm
5ghz 20dbm

FLOOR 3 (brick walls)
mapa piso 3.jpg
2.4ghz 10 dbm setting effective power 13dbm
5ghz default (23dbm)


as you can see is a very small area and 5ghz tx power are maxed out while 2.4ghz is very limited
only was possible use 20mhz channels in 5ghz to improve signal level over 2.4ghz, trying 40mhz channels on 5ghz to improve throughput was not possible because the signal level was always under 2.4ghz

Re: Band Steering implementation?

Posted: Thu Dec 28, 2017 1:03 pm
by Petri
@chechito If you want to get by with just one access point per floor, you need to locate it centrally. Just a bit north from the staircase in this case. (I assume its is a staircase at the middle of the bottom part of the floor map.) If you place the APs in the corner of the floor you are wasting 3/4 of the signal and there are more walls to penetrate on the way to the opposite corner.

Quite often you need more access points to get a good coverage in a brick building. Fortunately the APs are less expensive these days and CAPsMAN makes management easy. I just had a case where a client wanted ALL floor area covered, even in the basement with reinforced concrete walls. I made a plan and I placed one AP per room with tx power turned way down. I still don't know why it was so important to get coverage in all utility rooms and storage areas, I tried to talk them out of it.

I believe 2,4GHz band would fit your case better. The signal penetrates the brick walls better and the building appears to be separate so hopefully the neighbouring APs won't cause that bad interference. You'd get better throughput with 5GHz and 40MHz channels of course. Perhaps you can use both: 5GHz in the high density areas and use 2,4GHz for the additional supporting APs. The 2,4GHz APs are less expensive if you are on a budget (hAP Mini or cAP Lite for example). When you have more access points it is even more important to turn down the tx power to keep cell sizes small.

(Yes, I would like to see MikroTik implementing a band steering option, too. However, it won't solve all problems.)

Re: Band Steering implementation?

Posted: Wed Jan 03, 2018 11:57 pm
by haik01
It all depends on noise. If you have a noisy neighbours or your windows overlook a flat with 49 AP's or more.... forget it with 2,4 GHz. Use 5 GHz ONLY!!!

Use 2,4 for legacy devices which cannot do 2,4. yes, 5 GHz equipment is more expensive, and you need more of that stuff to cover the area, but once done, you have a very good / perfect network. especially if you can use DFS channels.....

Re: Band Steering implementation?

Posted: Thu Jan 04, 2018 10:22 am
by Petri
@haik01 Yes, it depends on the environment. OP didn't give a hint about it. The floor plan looks like it could be a small hostel (no bathrooms). The hostel could be in the jungle, mountains or downtown Bogota. There might be neighbours or not. Your advise suits Netherlands or Finland, where a single breakfast setup might cost 200€. In some other parts of the world, that might be the total budget for a WiFi installation: parts and labor. Even then it will make a big dent in the annual profit figure for a small business. Over here it is hard to keep in mind what it is to live on a shoestring. I try to give options and not to appear arrogant. Although it could just as well be that this is a wealthy villa with money to spend, too.

Yes, I agree with you and that is exactly the same advise I give to my Finnish customers.

Re: Band Steering implementation?

Posted: Thu Jan 04, 2018 12:43 pm
by NetworkMeister
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.
We are in the networking business, not in desktop/phone business. When I get an order for a WiFi deployment, I cannot blame Apple, no client in the world will buy that excuse. Other WiFi vendors understand that and adjust their products to bad client behavior and band steering/client handoff/roaming controlled by the AP controller is industry standard. MikroTik, you need to get this (as proven by other WiFi vendors) functionality implemented or you will never get your share in Enterprise WiFi.

Re: Band Steering implementation?

Posted: Tue Jan 09, 2018 8:28 pm
by rogers3b2
At last some improvement by mikrotik they introduced adaptive noise immunity on capsman in there latest release 6.41.
To tacle my issue at airport i make differnt ssid for 5 and 2 for 5 i just Mentioned word FAST only 5 ghz clients will be able to see these ssids.
Thanks

Re: Band Steering implementation?

Posted: Wed Jun 06, 2018 12:37 pm
by Petri
At the start there was discussion how to implement band steering. Selective beacons would be an easy solution. I found documentation how Ubiquiti does it. It requires keeping track of the clients even across multiple access points, so It requires quite a bit more work:

How Band Steering Works
  • Controller maintains a list of 5GHz-capable devices, which is shared with access points.
  • If a client connects to the 5GHz band, it is added to the list of 5GHz-capable devices.
  • If a known 5GHz-capable device attempts to connect to the 2.4GHz band, the device is dropped initially and moved to the 5GHz band.
  • To accommodate for legacy clients and coverage issues, if more than 8 such requests are received within 10 second period, the client is allowed to connect to the 2.4GHz band.
Different Band Steering Modes
Prefer-5GHz: If you configure the access point to use 'prefer-5GHz' band steering mode, the access point will not respond to 2.4 GHz probe requests from a client if all the following conditions are met:
  • The client has already probed the access point on the 5GHz band and therefore is known to be capable of sending probes on the 5GHz band.
  • The client is not currently associated on the 2.4GHz radio to this access point.
  • The client has sent less than 8 probes requests in the last 10 seconds. If the client has sent more than 8 probes in the last 10 seconds, the client will be able to connect using whatever band it prefers.
Force-5GHz: When the access point is configured in 'force-5GHz' band steering mode, the access point will not respond to 2.4GHz probe requests from a client if all the following conditions are met:
  • The client has already probed the access point on the 5GHz band and therefore is known to be capable of sending probes on the 5GHz band.
  • The client is not currently associated on the 2.4GHz radio of this access point.
  • All dual-band clients are pushed to connect to the 5GHz radio.

Re: Band Steering implementation?

Posted: Wed Jun 06, 2018 2:34 pm
by nz_monkey
Oh how I wish Mikrotik would implement this !

Re: Band Steering implementation?

Posted: Thu Jun 07, 2018 4:44 pm
by skept2it
For Phone and tablets 1x1 / 2x2 5Ghz coverage is only limited anyhow to very good signal strength areas
(like one concrete wall and not more)
Only 3x3 MacBooks or 4x4 STB can sustain far reaching 5G connections across walls etc.
So my target is to get 1x1 and 2x2 clients as quick as possible to 5Ghz once they have good RSSI
to free up frequency for far our 2.4G devices.

Assuming you have same SSID on 2.4 and 5G you can steer clients with access entries.
You need to provide 2 access list entries per device (for those dual band capable).
One access entry on 2.4G i/f with signal range -120 to -70 (-70 means it becomes quit good)
If client has better than -70 is kicked out quickly after 3 seconds.
One 5Ghz i/f access entry allows connection only from -85 to + 120. Again is worse then kicked out after 3 seconds
to move quickly to 2.4G. This values depend on how agressive you want to steer or not...

Ideally would be: be able to add per interface (5GHz mainly) a signal strength limitation, and not per client.
Because you really do not want to stick 5G devices too long to the network.

Also having a "hysteresis" would be good. Once device goes out of one network, should not come back immediately.
This is also why you need some overlap between signal strength.

For Samsung, Apples, pads/phones this works quit well, but means lot of effort to program the access list.

Some scripting (which I am not good at) could do lot of that automatically, specially detecting if the
device will look at 2.4G and 5G and then add this automatically into the dual band steering access list.

Re: Band Steering implementation?

Posted: Mon Aug 27, 2018 7:19 pm
by netusernoname
i'm still wait for band steering feature from Mikrotik Wireless Access Point

Re: Band Steering implementation?

Posted: Mon Aug 27, 2018 8:05 pm
by juliokato
The Mikrotik should not implement this feature. unfortunately.

Re: Band Steering implementation?

Posted: Thu Sep 27, 2018 8:28 pm
by Mikhail73
Assuming you have same SSID on 2.4 and 5G you can steer clients with access entries.
You need to provide 2 access list entries per device (for those dual band capable).
This not working (for me, at least). Mikrotik disconnects from 5Ghz and tries to connect to 2.4Ghz. Infinitely.
Can't understand, why not to introduce 1 simple setting: if 5Ghz signal level is over 70 (for example), do not move client device to 2.4Ghz, even it has much better signal level?

Re: Band Steering implementation?

Posted: Sat Dec 15, 2018 5:49 pm
by oscar555
+1 Let us change the beacon interval, at least, please.

Re: Band Steering implementation?

Posted: Sun Dec 16, 2018 4:07 pm
by r00t
It's sad when features like "Kid control" have higher priority and are implemented sooner than band steering that's been requested for years...

Re: Band Steering implementation?

Posted: Sun Dec 16, 2018 10:49 pm
by anuser
For 2.4Ghz I set TX power to 9db, for 5.0Ghz I set TX power to 16db. This helped at lot to get more dual band devices into 5.0 Ghz. I had Enterasys access points before I changed to MikroTik. With band steering enabled, Apple IOS devices refused to connect to the access point at all...

Re: Band Steering implementation?

Posted: Mon Oct 28, 2019 1:03 am
by Hammy
*bump*