The faster version of the IEEE Wi-Fi standard, 802.11n is now well established and supplied by all vendors, providing resilient and high-performance wireless networks that can compete with wired Ethernet.

Xirrus has installed more than a thousand 802.11n Wi-Fi networks, and here we will share the experience and knowledge we have gained. Every network is different, but we are giving a few simple guidelines that will help optimise 802.11n networks to achieve maximum performance and resiliency.

Network Design

While it may sound obvious to most, proper planning is crucial to deploying an 802.11n network, as these networks are more often used as the primary network connection and have more configuration options than legacy 802.11abg networks.

We have identified five key parameters to help optimise the performance and resiliency of 802.11n networks:

1) Site Surveys:  Executing an onsite site survey with actual products prior to deploying Wi-Fi equipment is important because it lets the network administrator know exactly where equipment needs to be placed – removes the guess work and identifies exactly what product, cable pulls, and switch ports are needed.

It is also important to note the following:

a) 802.11n networks use Multiple Input Multiple Output (“MIMO”) to increase throughput and network performance, but can be affected by walls and other objects. Because of MIMO, 802.11n RF propagation can be significantly different to traditional 802.802.11abg networks.  A site survey should be completed to test the RF characteristics of the environment prior to deployment.
b) Operating 802.11n in the 5GHz band is a key requirement to fully realising the benefits of 802.11n due to the additional channels and cleaner spectrum.  When doing site surveys, it is important to study both the 5GHz and 2.4Ghz bands, as 802.11n can operate in both, and both should be used to support the a wide-range of client devices.
c) We recommend using -72dBm to ensure that multiple radios are available at a sufficient RSSI level.  It is important to survey for at least two radios at all locations, ensuring that at least one 2.4GHz and one 5GHz are visible, though two 5GHz radios would be better.

2) Device Placement:  Use multi-radio Wi-Fi Arrays so that large numbers of users do not have to share a single radio.  Set the cell size to that a minimal number of users are at the fringe of the cell. Don’t assume a lower network device count when designing 802.11n networks.  We recommend against creating large cells for an 802.11n design when high performance is desired.

3) Security:  With any wireless network, a key concern is security.  We recommend using WPA2/AES encryption for 802.11n deployments – anything less is a compromise on security and performance.  Also, legacy 802.11abg monitoring tools may not catch all of the threats for a 802.11n network, so if the network is migrated to 802.11n, the monitoring tools needs to be migrated as well.

4) Wired Switch Network:  In many networks, legacy access points are plugged into 10/100 Ethernet ports, which makes sense when using 802.11abg devices.  However, this creates issues with 802.11n due to the increase in bandwidth and throughout.  802.11n Wi-Fi Arrays should be plugged into Gigabit Ethernet switch ports to take full advantage of the throughput improvement of 802.11n.  It is possible to minimise the traffic load from 802.11n networks at the core by processing as much traffic as possible at the edge, as well as ensuring the core is capable of seeing an increase in data traffic.

5) Power:  Most wireless networking devices are powered through Ethernet cables using Power over Ethernet (“PoE”), and so it will be wise to use power injectors that are able to take full advantage of 802.11n performance and functionality, as well as being prepared for future 802.11n technology advances.

Page: 1 2

adminuk

View Comments

  • Hi Ben,

    I fundamentally disagree with much of point #1.

    First, every multiple channel architecture (MCA) vendor other than Xirrus, that I'm aware of, recommends that you survey to provide -67dBm of coverage with two 5 GHz radios on different channels and then lowers the power on their 2.4 GHz radios to provide an appropriate channel plan with appropriate cell overlap for their particular regulatory domain. For networks providing voice, video, and RTLS services, this design approach isn't really optional, and this approach is highly recommended for high-throughput and high-availability data networking as well. This design allows features like band steering to function properly while also providing the necessary cell overlap for roaming across APs on different channels.

    Second, -72dBm is not adequate signal strength to provide for the "triple play" of voice/video/data, high speed/capacity data, or RTLS. To verify this, simply look at the receive sensitivity of your client devices. This is why every other vendor recommends -67dBm or better, and some voice vendors even recommend -60dBm where possible. Occassionally you'll hear a vendor suggest -65dBm, so I like to split the middle and suggest -66dBm. That's 6dB more power than Xirrus is recommending, which is 4X as much power. That means that Xirrus is recommending 1/4 (25%) of the necessary power to deploy a triple-play, high-speed network. This is puzzling given their marketing campaign of being the most powerful Wi-Fi in the universe... Having competed with Xirrus (and won) on numerous occassions, I suspect it is because their solution is comparatively too expensive when deployed at -67dBm or better. By recommending -72dBm (a sparse coverage deployment strategy), Xirrus can be competitive on price while coming "back to the well" again later when the customer asks why the network isn't handling voice, video, and data as well as they expected, especially a high client densities.

    Point #2 doesn't quite make sense either. By using directional antennas and spacing arrays far apart (as denoted by the -72dBm coverage suggestion), it's a given that there will be lots of fringe clients. It's even more curious that they are suggesting the use of smaller cells with 802.11n while also suggesting a design guideline of -72dBm. Their arrays are, by design, meant to form large cells - very large cells in fact. They have directional antennas on each AP.

    While I agree with this article on Point #4, Xirrus's array can only use a single Gigabit port at a time (not bonding both of their Gigabit ports together), so on ALL of their 8, 12, and 16 radio arrays, the Gigabit port is a massive bottleneck.

    Most of the industry (journalists, analysts, consultants, customers, and even vendors) scream about wanting full AP functionality on 802.3af, and with dual-radio 802.11n, that's not an easy task. If you use 3x3 MIMO with dual-Gig ports, you're usually hosed for 802.3af. So, most vendors have taken a serious liking to 802.3at in order to push more powerful AP hardware into the market. Since 802.3af and 802.3at are standardized, ratified, and mature (with many switches and multi-port injectors in the market now), using these makes sense to 95% of the Wi-Fi consuming population these days. Xirrus requires proprietary, very-high-power PoE injectors for all except their XN4 (4 radio) array, and they can use 802.3at with that array (at least it was on their roadmap a while back). Proprietary PoE just doesn't make sense, as Cisco proved early-on. Once there's a standard, everyone goes with the standard.

    In the RF Design section, you said, "Because wireless is a shared medium, total performance of a radio will drop as more users are added." This just isn't true. The AP's radio performance remains constant, but the amount of capacity that radio offers is shared among the user group connected to that radio at any given time. The caviat is that slower connected clients will introduce PHY/MAC overhead reducing the cell's raw throughput capacity. It's for this reason that we design the network around parameters such as -67dBm, so that clients will connect at high (300Mbps) data rates and not drag down the capacity of the cell with protection mechanisms and the like.

    Thanks,

    Devin Akin
    Chief Wi-Fi Architect
    Aerohive Networks

  • Hey Devin,

    Not sure why you state that you disagree, Ben didn't indicate that -72dBm was for voice or video applications, or for cost reduction to be competitive (frankly that's a cheap shot which I'd expect someone in your role to be above - we see that's not the standard for your company - SAD).

    This -72dBm value is the minimum required for OFDM data rates on most all laptop and notebook computers. Obviously any handset with a coorespondly smaller antenna would require a higher signal level as you indicate and is a part of our standard pre-survey process.

    Your comment that most all vendors suggest -67dBm ignores the reality that Ascom handsets require -65dBm and to gain high data rates with the iPad require -65dBm (at least till Apples most recent update which improved this by a couple dB).

    Splitting the middle as you say would create dead or weak spots for clients that need higher signal levels - I must assume that you'd suggest this would satisfy your customers. Our experience is that this would just frustrate most customers and a pragmatic approach that accounts for these variables specifically is the correct way to design and survey.

    Your claim that you've beat us multiple times without specifics is laughable. I've yet to run into anyone interested in running a metro mesh WiFi vendors gear inside any enterprise environment and would question the wisdom of doing this. In any case, you can always make the argument that you get what you pay for! Not sure we need to go down this road as I'm sure there's a reason we win against Cisco and Aruba on a regular basis. We are asked for side by side tests by prospective customers regularly, we have never lost in these comparisons.

    Your insight on point #2 just indicates you don't understand the tradeoff between capacity and coverage - you trade one for the other. We can deliver either. You can deliver neither.

    Moving on to the Gig ports, we do provide bonding of our ports but that you'd only know if you actually read one of our spec sheets. Arguing from ignorance is not compelling I believe you'd agree. So, to answer your objection there’s NO BOTTLENECK AT ALL since we do bond the Gig ports. Yet, your use of Gig ports is a waste since you will only carry ~170Mbs on a full Gig port to the switch – I believe many would be disappointed by having to pay for a Gig port to attach one of your APs. A Xirrus Array will use the capacity the port was intended and designed to deliver not 1/5 of it as you seem to say is ok.. and while we’re at it, maybe you can address how your controller can avoid bottlenecks when customers oversubscribe with too many APs in order to save money by having to buy an entire controller for the marginal AP that oversubscribes that one extra AP, or how you deal with the limitation of mesh pipe sizes and their associated bottlenecks. You aren't in a position of strength to argue choke points sir.

    Regarding your comments over PoE, you'll note that our injectors are PoE standard which just points to your ignorance of the standard which calls out signaling not power in the spec. Now to your point about using the closet gear, we'd simply point that for every single port we use, you will use 4 ports. Most customers would chose the later not the former in our experience, if for no other reason to save costs which was a big part of your attack of the Xirrus Array deign I believe. Using more ports cost more in all cases, you must agree! Cisco also uses these power modules - just in case you wondered who else might be "proprietary" in your vernacular.

    Regarding you last paragraph, anyone reading this would have assumed the reference to degraded performance was from the stations perspective. People are smart enough to get this, at least we think they are. As to your other points we agree and as I addressed earlier, our preference is for high performance everywhere and no slow clients at the edge with a coverage designed network.

    Jon Freeman
    Xirrus Inc.

  • Ben,

    Your list of items refers specifically to Xirrus equipment, and not to designing for 802.11n in general. You list things that give advantages to, and support ONLY Xirrus fixed antenna arrays.

    It would be a bit more kind to the reader of this article to explicitly specify this fact - it would help lower the already confused public.

    Talking like 'all' 802.11n devices need what you mention is disingenuous at best.

    Keith Parsons, CWNE#3
    Managing Director
    Institute for Network Professionals
    http://WirelessLANProfessionals.com

    By the way - Ben & Devin, I'd love to have you both on an upcoming Wireless LAN Weekly podcast to discuss your differences on designing for .11n

  • Sorry I have been on leave after the finish of Q3, so my response is a bit tardy. While I fully appreciate the comments and take them on board, I have to say that in my experience, a solid reinforcement and attention to the 5 key points for successful real life deployment of Wi-Fi are all solid foundations and necessities on which one should rely on no matter who the vendor is: Site Survey, Device Placement, Security, Wired Network, and Power

    Indeed the point made around -72dBm being insufficient is in fact wholly incorrect, and indeed misleading. Real life experience plus at least a basic reading and understanding of the specification for 802.11n shows that -72dBm is sufficient for high performance data operation on standard laptops. Clients used to have issues with roaming at this level but this is not the case now in our experience across many thousands of implementations. For VoWi-Fi phones, smart phones, hand scanners, and certain other clients, a higher signal criteria is often used based on the requirements of the product.

    In response to the point raised about fringe clients, again a basic understanding of 802.11n would mean awareness of the contention algorithm used in 802.11n whereby performance degrades as more stations use any given channel, leading to greater back off times for all which in turn results in lower performance for all. That is why a Wi-Fi network should be implemented in such a manner where more radios operating on more channels are visible to all users at all locations at all time and that user load balancing is applied to steers users to less crowded radios as well as between 2.4G and 5G bands. In either case it a very simple principle: More radios = More Bandwidth = More Users.

    With regards to the injector point raised - more vendors are using separate injectors as they find that to provide the power needed for full 802.11n operation is higher than that provided by 802.11af.

    With regards to the dual Gigabit port point raised - not being link aggregation capable is incorrect as the Xirrus Array supports link aggregation along with other modes such as port mirroring.

    As requested, I tried to respond with the 802.11n specification as the primary reference and I corrected inaccuracies as shortly and concisely as possible.

    Ben Wilson
    Principal Technologist
    Xirrus

Recent Posts

Tesla Shares Surge On China Advanced Self-Driving Push

Tesla makes key advances toward advanced self-driving rollout in China as chief Elon Musk meets…

22 mins ago

UK Law Aims To Boost Security For ‘Smart’ Devices

New UK rules bring in basic security requirements for millions of internet-connected devices, aiming to…

2 hours ago

Alphabet Value Surges Over $2tn On Dividend Plan

Google parent Alphabet sees market capitalisation surge over $2tn on plan to over first-ever cash…

8 hours ago

Google Asks US Court To Dismiss Federal Adtech Case

Google asks Virginia federal court to dismiss case brought by US Justice Department and eight…

8 hours ago

Snap Sees Surge In Users, Ad Revenues

Snapchat parent Snap reports user growth, revenues in spite of tough competition, in what may…

9 hours ago

Shein Subject To Most Stringent EU Digital Rules

Quick-growing fast-fashion company Shein must comply with most stringent level of EU digital rules after…

9 hours ago