RSSI check for client association/disassociation

[gherbiet]

Hello,

The big "C" is offering a feature called "rssi-check" (called "RSSI Low Check threshold" in the GUI: http://www.cisco.com/c/en/us/td/docs/wireless/controller/7-5/command/reference/cr75/cr75_chapter_010...) on its controllers. This per-radio settings rejects client association if the RSSI of the association request is lower than configured threshold.

They also have a similar parameter (band-select client-rssi: http://www.cisco.com/c/en/us/td/docs/wireless/controller/7-5/command/reference/cr75/cr75_chapter_010...) that is used to control if band-steering shall be applied, based on the RSSI of the 5GHz association request.

Is there any plan to integrate that in the IdentiFi code baseline? This could help in highly dense areas, to eliminate sticky clients and would be particularly useful when you roll 802.11u as this will easily prevent clients to roam to a poor Wi-Fi connection.

The concept could also be improved the "E"-way by :
- making the parameters per-SSID (and not per radio) ;
- also manage client disassociation based on RSSI of later received frames.

Does that sound a good idea to you?

[hsachse]

Great explanation Jon. In could Guillaume-Jean recommand to read the CWNP study guides for details understanding of making such design decision.

[Jon_Linton]

When a client looks for an AP to connect to it sends out frames called a probe request. It is up to the AP to decide whether or not to respond to the probe request. I see issues with manipulating this for "normal configurations" (not high density). Using load groups can acheive what you are asking but not globally. You have to make an engineering decision on where to employ this. Only the strongest AP will respond to the probe request. Let's suppose that a client uses dynamic transmit power control. This would affect the signal that is received the AP. They may want to send probe requests at a power level that is not too high and not too low. If the AP RSSI threshold is set too high it could prevent this client from connecting even though it is close to the AP. This is a power saving technique for mobile devices. Probe requests do not need as much power as a data frame, because their data rate is typically much lower. My advice is that unless this is a high density (50-100 users per AP) scenario, there are better ways to get performance improvements. There is a lot of complexity in WiFi client firmwares.

[Javier_Solis]

Sohil, is this something that the controller does automatically or are you talking about band steering with load groups?

[Thakkar__Sohil]

We already use RSSI as one of the parameter to stir client to "right" AP today. This is just another Cisco complexity left for customer to figureout... how would customer figure out a specific RSSI level that would prevent sticky client? This is not what we do...We believe in simple, fast and smart system 