One strong driver for the use of 802.11n as the network infrastructure is the increased prevalence of 802.11n in devices. For the past few years, when you purchase a laptop with a wireless LAN interface, the underlying technology is 802.11n. The greater proportion of 802.11n devices that are going to be using the network, obviously, the greater driver there is to build an 802.11n infrastructure. A network that is designed to support primarily older 802.11a/b/g devices doesn’t need the same level of infrastructure quality as a network designed to replace switched Ethernet connections with 3-stream 802.11n laptops.

Among different devices, the quality of the wireless infrastructure can vary widely. No standard dictates how to embed an 802.11n interface into a device, and the transmit power, receive sensitivity, and design of the antennas are all choices left to product designers. When two devices, both claiming “802.11n compliance,” connect to an AP, the quality of the service they receive may vary widely depending on how much effort the product designer devoted to the wireless LAN interface. One device may have a top-quality chipset combined with well-designed and placed antennas, along with high transmit power. If it is placed next to a device that uses the cheapest possible chipset with off-the-shelf antennas that are poorly placed, it will experience poor connectivity, even though the AP is providing exactly the same service.

Almost as important as the type of devices is the number and density of devices. When I started working with 802.11 a decade ago, it was common to joke that APs had become the modern-day equivalent of oases, with users clustered around not a water source but a connectivity source. As wireless networks have grown in popularity, it has become common to see new devices that cannot use anything but a wireless network for connectivity. When phones with Wi-Fi first became prevalent, many people predicted that networks would need to support two devices per user (portable computer and phone). With the emergence of tablets, that prediction, if anything, seems conservative. As far as planning network capacity, most tablets are pure wireless devices without the option to connect to Ethernet, but they are also closer to computers than phones, with large screens that can more effectively present large amounts of data.

802.11n and Single-Stream Clients

The word “legacy” in the phrase legacy clients generally means “anything older than what I’m talking about,” and as such, tends to shift over time. In this book, the term “legacy” is used to refer to 802.11a/b/g-only devices, and especially anything that is only using SISO technology. Even 802.11n has single-stream speeds, which are used both by devices that have poor link quality as well as devices that have only a single transmit chain. Portable devices are often built using single-stream 802.11n because each radio chain consumes power, and the amplifiers are especially power-hungry. Using only a single-chain transceiver can dramatically increase battery life. (Apple’s iPad is a good example; although it’s an 802.11n device, it is a single-stream device with a top speed of 65 Mbps.) Single-stream 802.11n clients work very much like 802.11a/b/g devices, with only minor enhancements to transmission speed based on the improved coding unless 40 MHz channels are supported.

802.11n is not magic, and will not enable your older 54 Mbps client devices to suddenly break through that 54 Mbps barrier. What it does, however, is it improves what is called the rate-over-range. At a given distance, the AP with better rate over range will help clients connect at a faster rate. In Figure 7-1, there are two access points shown with the range of each data rate. As with any wireless technology, as you move farther from the AP, the data rate decreases. The older 802.11a/b/g AP at the top is a state-of-the-art design from 2008, and it uses the final generation of 802.11a/b/g chipset. The newer 802.11n AP at the bottom can’t use any data rates faster than 54 Mbps because it still has to transmit at a rate the client understands. What it can do, however, is use the MIMO reception to increase the range at which the client can transmit at its highest data rates.^[34]

Figure 7-1. Rate over range illustration

No matter what you do, single-stream client devices will never exceed 65 Mbps. The job of the network with respect to single-stream clients is to offer the best service possible, at the longest range possible. To support large numbers of single-stream devices, focus on the rate-over-range performance to ensure that you are extending the best possible speeds out to the client. It is in networks that support a large number of single-stream devices that the backwards compatibility of a device comes into play, and if you have a large number of older devices that only support single-stream operation, your selection process should focus on how well 802.11n can improve the client experience.

Note

Overall speed is determined by the number of streams supported by both ends of the link. If you have a large number of single-stream client devices, consider weighting your AP spending towards a higher number of APs for better frequency reuse, not necessarily the fastest APs you can buy.

On the receive side, technology like Maximum Ratio Combining (MRC) improves the SNR by a few dB, but that can make the difference between one or two data rates. MRC works best when there are “spare” radio chains, that is, when the number of radio chains in use is greater than the number of streams. Every radio chain improves performance a little bit, so if you have a number of clients working at medium range, opting for a 3×3 AP may improve performance over a 2×2 AP by increasing the achievable data rate.

Note

A 3×3 AP working with single-stream clients will have somewhat better performance than a 2×2 AP working with single-stream clients.

Although many devices have converted to 802.11n by this point, low-data-rate devices designed around a specific application may still be using older technology. 802.11a/b/g devices can have significantly lower power consumption, making it preferable for legacy devices where battery life is a key consideration. Older barcode scanners are just moving to single-stream 802.11n.

Bring Your Own Device (BYOD)

The wave of enthusiasm for bring-your-own-device (BYOD) programs, which allow employees to use personally-owned devices on a corporate network, has been driven by mobile devices that increase productivity by putting information quite literally in the hands of users. There is a great deal that can be written about BYOD programs and what they mean for network administrators and IT departments. I’m not going to attempt to write much about BYOD because the field is evolving so quickly.

Generally speaking, what it means for network administrators is that there are, broadly speaking, a few classes of devices that get used on a network: corporate-owned devices, such as a company-supplied laptop, phone, or tablet. Corporate-owned devices are often managed and have policy enforcement that requires that you run anti-virus software, perhaps use a web proxy, and possibly even lack administrative rights to the machine. Guest devices are brought in by guests, such as visiting sales people or business partners. Guest devices typically are set up with Internet access and nothing else. In the past, networks have often had an ad hoc procedure in place for contractors to enable them to use their own laptops and have some level of privilege. (I once worked at an organization that created an Active Directory account for an attorney that visited our office once a week, but he only used that account for access to the wireless LAN.) Contractors typically receive some access, but not full access. And that’s before employee-owned devices started showing up.

Why am I writing about BYOD in a book about wireless networks? All the productivity-enhancing devices that people want to use (and in many cases just started using without permission) have wireless LAN interfaces. Many of them don’t even have the ability to connect to Ethernet networks, and therefore are forced into using the wireless LAN. As that first point of contact, it falls to the wireless network administrator to enable access for employee-owned devices…but not too much access.

If you are thinking of supporting a BYOD program on your wireless LAN, look for flexible security mechanisms that can be used to identify and register employee devices, and a wireless LAN that can effectively segregate traffic based on the type and ownership of devices, and can be used to easily identify and register devices. It’s also important to “overbuild” your network for a worst-case scenario. With BYOD, what little control you may once have had over devices on the network is gone. All it takes is one popular device that has poor radio characteristics to ruin your day. As part of starting a BYOD program, pick a “worst case” device performance and design around that for two reasons. First, clearly documenting the minimum supported device will help in explaining performance problems for devices that fall below that baseline. Second, having a clearly documented worst-case scenario provides guidance on how to redesign the network to handle a problematic device. If, for example, you have designed a network to work with devices at an average signal strength of -70 dBm and must cope with a device that requires service of -65 dBm, use your favorite planning tool and see what would be required to redesign the network for a 5 dB increase.

As important as the type and number of devices is the activity that those devices support. 802.11n can dramatically increase the throughput of a network that supports data-transfer applications, especially if paired with 802.11n client devices. Data transfer in bulk can be sped up through the application of higher data rates, aggregate frames and block acknowledgements. Fortunately, most applications fall into this type. File transfers obviously benefit—with 802.11n, you can give a wireless device the full benefit of Fast Ethernet-type data rates and transfer at just over 10 megabytes per second. Any application that works like a file transfer benefits similarly; medical imaging applications must often fetch large, detailed images from a server on to a device for display. Even web browsing, widely viewed as a “light” application, benefits from being able to pack multiple frames from the web server’s response into downstream data.

Real-time streaming applications may or may not benefit, depending on the characteristics of the application.^[35] Block ACK procedures can only be used between a sender and a single receiver, and therefore cannot be used with a multicast application. Multicast applications may benefit from the higher data rates in 802.11n, but it depends on the application and your network equipment. When a frame is destined for a group of receivers, it must be transmitted at a data rate supported by all receivers. Most 802.11n networks are designed to support any type of client, and will therefore send certain management and control frames at older 802.11b rates. The easiest way to ensure that multicast frames are transmitted at a rate that can be understood by all receivers is to pick a very low data rate, but this prevents an 802.11n network from being any better than the 802.11a/b/g network it is replacing. To take full advantage of 802.11n for multicast streaming applications, an AP must monitor the data rates that each receiver is capable of. Typically, that is accomplished by monitoring Internet Group Management Protocol (IGMP) messages to determine when a client has joined or left a multicast group. By maintaining a dynamic list of receivers in the multicast group, the AP can select the highest data rate used by all group receivers instead of all receivers. In a network that supports mixed traffic of 802.11b/g devices and 802.11n devices, such an AP can use the much faster 802.11n data rates if the group members are all 802.11n devices.^[36]

One streaming application that is not directly helped by 802.11n is voice traffic. Voice is a special case because it requires streaming data, but the nature of voice prevents it from being buffered. It is not possible to speed up voice by using 802.11n because there is very little benefit to transmitting the regularly scheduled voice frames at 802.11n speeds. An 802.11n access point may improve voice traffic indirectly by offering superior reception with a more advanced radio design, as well as by increasing the overall capacity of the network and freeing airtime for voice devices.

The starting point for planning out how to connect a wireless access layer to your network is to create a complete inventory of services the network will need to support. Integration of services into the network framework is shown by Figure 7-2. The figure is meant to be conceptual in that it shows where services might attach to an existing network core, and what services the wireless access layer may depend on. This section classifies services based on the part of the network where they require the highest level of support.

Figure 7-2. Network service diagram

Generally speaking, connecting 802.11n to the backbone network is fairly simple. Since even a basic 2-stream AP can readily push 100 Mbps per radio at peak, you want to have gigabit switching infrastructure to support an 802.11n access layer. It is possible to run 802.11n on Fast Ethernet, but any 802.11n AP can easily bottleneck at Fast Ethernet speeds. To support a fully functional 802.11n network, start the project by ensuring that backbone connections are fast enough, whether through an upgrade to gigabit Ethernet switches or using Fast Ethernet link aggregation across multiple uplink ports on the AP.

How you connect the network depends on the services that the network needs to support. Generally speaking, management protocols require very little overhead and are not a key consideration. If possible, map out the major flows of traffic on the network and use that research to determine the major sources and destinations. In a network that supports extensive use of virtual desktop infrastructure (VDI), it is likely that most traffic will be to a handful of VDI servers in a data center. On the other hand, a university campus with highly mobile students and departmental infrastructure likely has more of a mesh-style traffic flow that does not have natural choke points. Network access for guest users over the wireless network typically pulls all guest traffic back to a central point, and naturally fits a centralized forwarding model.

In a network of any significant size, most APs will be powered from edge switches. As a practical matter, AP product designers have recognized that the 802.3af power-over-Ethernet (PoE) standard is widely installed. APs must either operate within the power limits impose by 802.3af, or give network administrators a reason to install special power equipment. Not surprisingly, most APs work within the 803.3af power limit.

In 802.3af, an Ethernet port supplies 15.4 watts of power at the switch, though the standard only guarantees a little bit less than 13 watts over a maximum-length cable due to losses from cable resistance. For a highly functional 802.11n AP, the power limit is quite strict. The major components in an AP are the radio modules that provide the wireless connectivity, the Ethernet controllers that connect the AP to the network, and the CPU that runs all the software to make it happen. AP designers carefully select components with one eye on power consumption to ensure that an AP will run with only 13 watts.

To run the AP, power can be supplied using one of the following methods:

Better than any of these four is to purchase APs that work within the 802.3af power limits, as any high-end 802.11n AP released since 2008 will have been designed to work within the 802.3af power ceiling. Prior-generation APs that consumed more than 13 watts were often designed with a prioritized partial-shutdown list that would power down components to allow the AP to start up within the limit imposed by 802.3af. APs with dual Ethernet ports would often start by shutting down unused Ethernet ports. Typically, the next step would be to limit the clock speed of the CPU, which might limit software functionality. Reducing the functionality of the wireless interfaces was a last resort; 802.11n’s power saving specifications allow for the shutdown of individual radio chains when used for communication with less capable clients. Many vendors exploited that by throttling 3×3 APs back to 2×2 operation to save the power of running the third radio chain. Although shutting down a radio chain limits performance, it will still be faster than 802.11a/g.

If you are upgrading to 802.11n and have an extensive TKIP deployment, the security transition requires its own planning. 802.11n APs will not support TKIP with the fast data rates of 802.11n. It is possible to continue to use TKIP by using the 802.11n APs in a “legacy” mode where they use 802.11a/b/g data rates with the improved radio technology of 802.11n. Such a network will have improved range as well as rate-over-range, but the performance gain will not be as substantial as if the client devices were unleashed to use 802.11n rates.

There are two common methods of handling the transition away from TKIP. Both methods use TKIP and CCMP simultaneously with the same set of network infrastructure, but they do so in slightly different ways.

802.11n made no changes to the user authentication framework. Any user authentication system that works with 802.11a/b/g networks will also work with an 802.11n network.^[38] EAP-based authentication is designed to work on top of many different physical layers, and therefore it does not require any change when moving to 802.11n. Connections between the wireless network and the user account system should not need to be redesigned.