Frequent Disconnection by Devices

[NWNSM1]

We have users experiencing disconnections or roaming issues.  Attached is a sample from one user. 

APs are CW9166I, and clients are a mixture of devices (iPad/Apple TV/MacBook/HP Win11)

The environment is 2-story middle school with an AP in every classroom or office/media center.  Students have iPads, but again, this is not device or OS specific.  

The 29 APs are running two 5 Ghz radios, and many of the roams are between the two radios on the same AP.  

We experience a high number of unexplained disconnections, too. 

The environment is RF clean, and the Meraki dashboard indicates that channel utilization and interference are low. 

The APs are new, and we had been running MR42 or MR52 since 2018 without issues.  

[alemabrahao]

I advise you to conduct a site survey of your Wi-Fi network.

You can also check if 802.1r and client load balancing are enabled and disable them to see the result.

[PhilipDAth]

The first thing I check these days is whether the customer has an "RF Profile" configured.  It solves about 90% of the issues immediately by creating one.

https://documentation.meraki.com/Wireless/Operate_and_Maintain/User_Guides/Radio_Settings/RF_Profile...

I mostly use the "Open Office Profile", but in your case the "Classromm Profile" might be best.

Make sure you make the profile the "default", or apply it to all your APs.

And while you are there, make sure you turn on AI channel planning and "busy hour".

https://documentation.meraki.com/Wireless/Operate_and_Maintain/User_Guides/Radio_Settings/AI_-_RRM

[NWNSM1]

I did have an RF Profile enabled and applied.  I opted to ask ChatGPT to fix my network, and by looking at a few specific clients and as a whole, it made suggestions.  It was able to suggest changes that appear to be working. Below is the ChatGPT summary. 

Multiple clients across the SCHOOL SSID experienced intermittent disconnects and excessive roaming in a high-density classroom environment using Meraki CW9611 APs. Analysis of Meraki event logs showed frequent same-AP roaming and rapid disassociate/reassociate cycles despite strong RSSI/SNR, ruling out RF coverage, interference, DFS, or client-specific issues. Root cause was determined to be aggressive roaming behavior related to dual 5 GHz operation combined with 802.11r (fast roaming) in a low-mobility environment. Mitigations applied included disabling 802.11r on SCHOOL, maintaining 20 MHz channels, controlled TX power (11–17 dBm), manual RX-SOP, and disabling client load balancing. Post-change validation shows stable client associations (Windows and iOS), elimination of same-AP roaming storms, and behavior consistent with normal client operation. Issue considered resolved; no further RF changes recommended.