Association process - many clients and AP's that use client steering/load balancing

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
NiMc_1688136
Level 5
Level 5
10 sign-ins 50 questions asked 10 solutions authored

I have been seeing association issues in our test setup of 100 devices with ubiquiti AP's that use client steering algorithms to balance clients across AP's. We have around two or 3 AP's in the area of the clients but a third of the clients struggle to associate if all are reset at one time, ie OTA update. I am thinking the join behavior hits the closet AP, association fails, and then on the retries it hits the same AP. This behavior appears to be in the WLAN driver and not in WWD/WICED. Is there any way to improve this or at least test for it, short of writing a custom scan and associate function (wouldn't help with roaming and I do not think i would have feedback of association response codes)?

Referencing this site: Client Balancing - Cisco Meraki , client balancing works by either the AP rejecting the association with a response code 17 OR by using 802.11v - BSS-TM to push the client to an AP.

Device: CYW43907

SDK 6.2

0 Likes
1 Solution
RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

A custom scan function can be implemented using wiced_wifi_scan_networks_ex API where you can use the last four optional parameters (specifically wiced_scan_extended_params_t)  to debug/improve on this issue. Similarly, you can try modifying the wiced_join_ap implementation based on the ap_client_events and then check for the issue again. If you want to add the other two APs as well for the retries, you can also do that in DCT based on How to switch AP connection in an application​Please let me know if that helps you to debug the issue.

View solution in original post

3 Replies
RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

A custom scan function can be implemented using wiced_wifi_scan_networks_ex API where you can use the last four optional parameters (specifically wiced_scan_extended_params_t)  to debug/improve on this issue. Similarly, you can try modifying the wiced_join_ap implementation based on the ap_client_events and then check for the issue again. If you want to add the other two APs as well for the retries, you can also do that in DCT based on How to switch AP connection in an application​Please let me know if that helps you to debug the issue.

RaktimR_11​ Thanks for the suggestion. This was the path that I was moving towards so it is great to have a second opinion to confirm the idea.

0 Likes
NiMc_1688136
Level 5
Level 5
10 sign-ins 50 questions asked 10 solutions authored

RaktimR_11

Do you know if 802.11k and 802.11v is fully supported as of 6.2.1?

0 Likes