Problem connecting clients 802.11 k/v

peterv

I switch 802.11 k/v on and off and lost all but one client. My clients can not connect I rebooted all and updated them what can I do?

Zyxel_Joslyn

Hi @peterv

802.11 k/v is used to suggest the stations to connect to which neighbor APs, and not all stations support this feature. Disabling this function will not affect the wifi connection. However, the wifi interface will be down when AP receives the setting. After AP applies the conifguration successfully, the WiFi service should be back. If you said all the stations cannot connect the AP, there should be another problem. Can you provide me your org/site name and enable ZYXEL support for me? If possible, please also provide me the station MAC address and test timing. I will search for the logs and realize the status.

Joslyn

Levente

Hi Joslyn,

Do you plan to separate the two features, and let the users enable them separately?
While 802.11k is good to have, 802.11v is what causes issues almost everywhere. It does not make sense to have a single switch for both.

Zyxel_Joslyn

Hi @Levente

Since 802.11k and 802.11v are used to assist station roaming, we will not seperate them to ensure the roaming mechanism will be smooth.
About you mentioned 802.11v causes issue, can you describe the detail for me? Since we did not receive the similar issue, we are curious what kind of issue that you met. If you can let us know the symptom, it will help us how to make it better.

Joslyn

Levente

Hi Joslyn,

BSS Transition Management enables an AP to request a client to transition to a specific AP, or suggest a set of preferred APs to a client, due to network load balancing or BSS termination. This helps the client identify the best AP to which that client should transition to as that client roams. 

The BSS Transition capability can improve throughput, data rates and QoS for the voice clients in a network by shifting (via transition) the individual traffic loads to more appropriate points of association within the ESS.

The problem is not every client supports 802.11v, in fact a very few of them have this capability supported. This in turn takes it to a variety of 802.11v implementation modes on those that support it.

Hence there will be a bunch of applications, like voice clients, that will be periodically dropped off by the AP to roam to another AP in vicinity, that might not only have a lower signal level, but also the transition time will be longer. So this was my point when asking for separate handling of k and v.

There are sticky clients who like to stay connected to a 10% signal strength that's getting 500kb of bandwidth when a full strength AP is right next to them. (for clients with newer drivers who understand the standard it'll suggest they leave this AP and switch to a better one when the bandwidth gets low.) (for clients with older drivers who don't understand the standard, it'll kick them off/forcibly disassociate them if they're at a low bandwidth/signal strength threshold for a long amount of time. Which helps facilitate them connecting to the better AP right next to them. 
But voice clients are pretty fine with such low bandwitdhs, they actually benefit from this stickyness, and a steering may just loose way to many voice packets during a transition, they have not asked for. You will see a bunch of unwanted deauths, and client kicks off.

The situation here in my opinion is pretty similar to 802.11r. I don't suggest using this either unless you have a really homogenous environment, since it prohibits older and not so older clients from connecting at all.
Having the possibility to set these features separately, gives you a lot more control over how the clients will behave in the WiFi environment. And currently Nebula has way too many limitations, unbundling v from k would just decrease this number.

Greenlight

In my using experience, enabling 802.11k/v won't affect my unsupported devices(Ex: Sony smartphone). Check the standard flow, you'll find both standards just allow AP to "recommend" some support candidates to wireless station. And station can decide whether to adopt or ignore that list. (Furthermore, the above process won't be triggered if AP knows client doesn't support 11k/v during association)

If AP actively kick-off station, I'd think it is trigger by other features like "smart steering" and "band select", not by 802.11k/v.

I also agree to separate 802.11k/v into two items for user with strong domain knowledge, which allows them to customize the setting in detail aspect. But for other users, binding those two functions together provides a more intuitive option: Want to let AP assist your client roaming? Just enable them together!

Zyxel_Joslyn

Hi @Levente

If the wireless client does not support 802.11v, it will only ignore the bit in the beacon. This should not take any effect to the wireless client who cannot understand the bit. A wireless client will decide to roam when it detects a better signal from a new AP than the one it is currently associated with. This behavior is normal, especially for mobile devices such as laptops, tablets, and mobile phones. Our responsibility is to reduce the connection lost time once the station decideds to roam to another AP. 802.11k/v is designed for this situation. The beacon will content the k/v information to let the stations prepare the roaming status to reduce the down time, especially to a phone call. Since the voice stream will not transmit again, making the connection smoothly is the most important thing to do.

802.11v describes enhancements to wireless network management, such as:

Network assisted Power Savings - Helps clients to improve battery life by enabling them to sleep longer. For example, mobile devices use a certain amount of idle period to ensure that they remain connected to access points and therefore consume more power when performing the following tasks in a wireless network.

Network assisted Roaming - Enables the WLAN to send messages to associated clients, for better APs to associate with clients. This is useful for both load balancing and in directing poorly connected clients.

The 802.11k allows 11k capable clients to request a neighbor report containing information about known neighbor APs that are candidates for roaming.

For our opinion, enabling 802.11k and 802.11v at the same time can help station to choose the AP with better signal to connect.
If you really meet any 802.11v issue, please just raise the issue and let us know.

Joslyn

Levente

Hello Joslyn,

In an ideal world, it would look like depicted by you above... :-)

802.11v BSS transition can be applied to 3 cases:

• Upon client request - Client can send an 802.11v BSS Transition Management Query before roaming for a better option of AP to re-associate with a client.
• Unsolicited LB request- If an AP is loaded heavily, it sends out an 802.11v TMR to the client
• Unsolicited Optimized Roaming request- If a client's connection rate and RSSI do not meet the set level, AP sends out an 802.11v TMR to client.

802.11v BSS Transition Management Request is a suggestion given to client. Client can make its own decision whether to follow the suggestion or not. Problem is on different vendor's 802.11v implementations. Who guarantees all clients act in the same way on these requests?

So overall this is a possibility from an AP perspective to force dropping a client regardless of what the client wants. It is not always a decision a client can take unfortunately. A client, and here you are right - can be ASKED instead of being forced to disassociate and connect to another AP, and not to try reconnecting over and over again to the one it has been kicked off from when not supporting 802.11v. And sadly enough, this requested transition can be done to an AP that is providing in turn a worse RSSI for the client... So here is my point why I believe v should be split off from k. 

802.11k was released earlier than 802.11v, and even Apple started to support 802.11k in IOS 6 and 802.11v in IOS 7. So nothing justifies in my opinion to have them tied to a single switch.

All the big vendors I know have it separated, Cisco, Aruba and so on. 

More than that by looking just to r/k, also pinpoints certain reasons why they should be separated. Still only a few clients support them. By enabling r/k, in the majority of the cases causes an issue for clients to connect/reconnect. Especially by using Samsung phones, older Macbooks waking up from sleep, using W10 machines with WPA2-PSK (which is still unsupported), so I'd vote for a revision here. I'll take your decision, but here it would be better to go with the flow...

Zyxel_Joslyn

Hi @Levente

Thanks for sharing the information. During theperiod of develope time, we have already considered these standards. Based on our design mechnism, 802.11v is used to suggest band select(2.4G/5G), but not kick stations as you described. In our design, 802.11v(band select) and 802.11k(neighbor report) will be not be separated since they are both used to provide better WiFi roaming experience. 
If the stations support 802.11k/v, the stations will inform AP their capability throught these kind of parameters. If the station does not support, this content will not be included in. According to this behavior, enabling 802.11k/v at the same time will not affect the older devices connection because the AP will not reply these kind of information.

If you meet any issue which is related with 802.11v, please provide us the diagnostic inform and station MAC address here to let us know. It will be a great help.

Joslyn