We observed this in one of our customer's installation. It turned out to be a false positive and was based, in part, on the fact that in high-density installations (where an LWAP can hear many other neighbors) its table of neighboring LWAPs overflows, causing the IDS to go off because the legitimate LWAPs no longer appear in the LWAP table.
It is possible that you are experiencing this same error.
You may want to review the latest version of the WLC firmware and determine if it is worth an upgrade.
(Our customer is going to upgrade tomorrow morning to fix this and some other related false-positive IDS messages such as Net Stumbler Attack, AP Impersonation Attack, Dissasoc Flood, etc.).
However, that does not necessarily mean that you do not currently have an adjacent neighbor running a wireless system, such as Aruba, that is able to perform auto-containment.
We experienced this first-hand last summer and had to go next door and nicely ask the administrator of the Aruba WLAN to kindly stop jamming us. It can be very difficult to "see" where the jamming/dissassociation is coming from since the AP doing the jamming is attempting to "spoof" (impersonate) the real LWAP and/or client - sending dissassociation messages as if it were them. However, you might be able to use a product such as Ekahau to see if the location of your LWAP appears to be at a different location than it should be. This might be a clue as to where the jamming LWAP might be located (or at least it's general direction away from your LWAP).
I believe that our customer just upgraded to the 4.0.206 version this morning. So far, there have been no snags.
However, he is still seeing false positive IDS errors after the upgrade.
In my conversations with Cisco TAC, they have stated that there is going to be an IDS signature ugrade sometime in the spring which may further address these issues.
However, there had been some hopes that the .206 December release (that became available in January) would fix this and, apparently, there are a number of issues that remain.
If you read the release notes for .206, you will see that one of the known issues is that the table of neigboring APs is too short and in high-density installations (where lots of APs close to each other), if too many APs are detected, then the table overflows, causing legitimate APs to look like rogues.
As far as the built-in Intel Centrino wireless adapter issues, there are some updated drivers available from Intel that are supposed to help.
I also believe that Cisco TAC may have some suggested settings regarding power saving mode that may help as well.