Forum

I would like to hear your expert views on what is the primary driving factor behind today's 802.11n adoption - is it higher speeds or a larger range per AP/client (yes, at a given link-rate)?

There are several "good" reasons to move to 802.11n, but from my (client device manufacturer) perspective, the best reason to move to "n", is to insure that our devices don't interfere (eg. slow down) anything else that uses the RF medium.
The last thing we want is some customer saying "Don't bring that #%*& device into my office. It will ruin the performance of the other hardware that we just spent big bucks on."
Admittedly, not the best reason, but one that does matter.

for the same reason people switched from 45s to CDs

from 8 track to cassette

from bias ply to radials...

it's the future, at present.

Yes, backward compatibility is one good reason. But, I would like to know if range improvements are a reality with 802.11n. Or is just marketware?

For example, has anybody been able to transition to 802.11n and reduce the number of APs required to cover a given floor area?

Remember that just because an AP can hear stations at a greater range, there is no way to ensure the stations can reach the AP. If you are talking about MIMO to MIMO then the range could honestly be extended. In the near term, most clients are legacy SISO stations. Many of the 802.11n stations are only 20 MHz channel enabled and are not able to obtain the speeds that the 20/40 MHz channel enabled stations are able to reach. I like to focus on the 802.11n APs ability to hear existing stations better and still worry about cell sizing to reduce contention domain size. Coverage area is always a concern in WLAN deployments, but falls second to many other concerns such as data rate, number of stations simultaneously associated and application support like VoFI. It is possible that the hidden node problem could worsen if the APs coverage area is too large.

BryanH, hit the bullseye.So many designs are still based on just coverage and blasting the AP at full power to try to "save money". Some think that when moving to the new High Rate PHY of 802.11n you are going to benefit from the increase range of the MIMO capable AP , and it will plug the holes for the clients, So they think by just swapping out an AP on that kind of design you are adding capacity. I see this first hand in our network with some of the network and RF engineers who have theorectical experience. I have made my recommendations.on designing a capacity based WLAN not just coverage. But the powers that be have their reasons for not or theorectical takes on RF progation. Take it or leave it, when (and it will) the wireless VOIP network fails and the need to add another 20 plus APs to plug the holes. It was documented that they decided not to pull the UTP to support the future network and enhancements of 802.11n and legacy clients in these historically challenging RF environments.

OK - thanks for your insights. What I am hearing is that users generally plan for capacity (or at least need to do this). Hence, speed is probably winning the big fight!

However, if clients in the near term are SISO, we dont even get the speed benefits - correct?

So, is it fair to say that most of the users may actually not be getting any immediate advantages by just deploying 802.11n APs today?

It *is* fair to say most users will see better results with an 802.11N Access Point!

There is more than just the MIMO involved in the benefits of 802.11N. Even when communicating with a SISO b/g card, an 'N' AP will do better than a non-N AP. Hands Down!

Of course, there are much more benefits of N if the clients are N capable as well.

Of course you have to design for Capacity and NOT only coverage. Coverage only designs hardly ever actually work in the real world. Client devices have so many more specs they need to see in a Wireless LAN than only coverage.

Coverage IS important, but not SUFFICIENT.

We also need to design for Overlap (double coverage), Co-Channel Interference (collision domains), Users per AP (Capacity), plus Jitter, Latency, data vs voice on the same frequency, etc.

We need to return to the DESIGN phase - and not stop at just getting simple coverage.