Do you know if you are using Event Driven RRM? It's possible there is aggressive channel changes taking place on the 3502, where-by your client would be deauthenticated (then most likely roam to next best candidate/other AP you mentioned). Do you have any inteferers detected by the 3502i AP in question? MONITOR > CleanAir > 802.11a/n or 802.11b/g/n > Interference Devies and AirQuality Report. Is Event Driven RRM enabled? WIRELESS > 802.11b/g/n or 802.11a/n > DCA > "Event Driven RRM"
If this is on, I would suggest turning it off, unless you have a full CleanAir deployment. Whether you let CleanAir force an immediate channel change due to AirQuality (and only on the CleanAir capable AP will it change immediately, as the others will only change once an RRM/DCA interval is reached), or you suffer with interference, it could lead to a client disconnect. The client should be able to re-associate immediately upon channel change, but may just move over to the next heard AP (a ways away) as you described.
If the debug truly only shows the entries in the original post, it would be helpful to have a wireless sniff on the APs channel along with another debug (started before the client ever associates). Channel changes would be reported in the traplog of the WLC, so you can look at your traplog through the GUI or ">show traplog" on CLI and parse for channel changes.
Since 7.2 allows 2 clients to be debugged, you may enable debug client for AP and the Client, and then turn on RRM debug for DCA
>debug airewave-director channel
or for more extensive RRM info
>debug airewave-director all
I'm not sure how this will behave (ie, if it will only show RRM details for the AP specified in the 2nd debug client-- you would just have to try and see.)
You can also enable telnet/ssh to the AP and directly run (these "should" work)
#debug dot11 mgmt station
#debug dot11 mgmt msg
#debug dot11 mgmt state-machine
