No.
The HTC phone connected to wifi on n and AES doesn't navigate and doesn't mind how much load had the wifi network.
I've made tests using AP105 with or without load. The behavior is the same:
(n+AES) makes navigation bad ALWAYS,
(no n+AES) makes navigation good always.
The number of users I said previously are distributed by more than 500 APs and the tests was made over non congested AP105s and over one special AP105 mounted only for these tests.
The traffic load or the simultaneous users over AP can not be the reason, we think.
We used several AP105s and there isn't any phone or laptop that showed the same behavior.
The tests were made simultaneously with two HTC phones, two Sony phones, several Iphones and one laptop. The only affected equipment were the two HTC phones I wrote.
The other phones and laptop navigate good in every kind of encryption and every type of network (n or no n).
And the HTC phones doesn't navigate ONLY if n and AES were SIMULTANEOUS.
As I said in my first post, the most annoying result is that one ping to ip NUMBER in the phone didn't fail.
The ping utility could be very slow to obtain the DNS answer (maybe one of the reasons to the bad navigation but not the only one) , but when packet from DNS arrived, the ping to ip NUMBER never failed.
How is it possible that in n + AES, the DNS answers and http packets were so slow, and ping packets to ip numbers were so good?
Thanks again and sorry for my english,
Nicolas