Two significant problems with 802.11 are the inefficiency of the MAC, which limits throughput, and the rapid change in physical layer technology, which makes devices obsolete quickly. A natural reaction to the inefficiency, especially from technically adept engineers, is to want to implement specific optimizations or new protocol features on the hardware they already own.

With wireless LANs, customizing the behavior of the interface is generally not possible. The baseband processor, or the functions of the baseband processor, are implemented directly in the integrated circuit for speed, and cannot be changed. So-called application specific integrated circuits (ASICs) have particular logic laid out in their circuitry, and cannot be used for anything other than what they were designed for. Furthermore, wireless LAN interfaces use radio components optimized to run with the frequencies allocated to wireless LAN usage by regulators.

However, future radios may be reprogrammable. Instead of using dedicated hardware for the baseband processor, designers can use “programmable logic” devices, such as Field Programmable Gate Arrays (FPGAs). Radio waves are analog waves that carry digital data. In many cases, radios only need programmable signal processing, and can use digital signal processor (DSP) chips. No matter what type of programmable logic is used, the end goal is the same. Rather than having a modulation fixed in place during the design phase, radios based on programmable logic can change modulation, coding, and bit rate on the fly with new software. The price of the flexibility is that programmable logic devices are bigger, run slower, and consume more power (and therefore generate more heat) than nonprogrammable devices.^[68] By using programmable devices, the behavior of the radio can be changed at will, simply by loading new software. New modulation types, bit rates, or even new frequency bands can be implemented without changing hardware.^[69]

Radio interfaces controlled completely by software (or programmable logic) are called software-defined radios or universal radios. In environments where the modulation and coding change rapidly or frequently, they are extremely useful. One of the first major software-defined radios was the SPEAKEasy project, launched by the U.S. military to replace 10 radio systems using different modulations with a single software radio that could perform the same work as all 10 radio systems, but in a much smaller package. Software-defined radios are subject to certification rules in the United States that couple the radio software with the hardware, and require manufacturers to take steps to avoid alteration of the software to operate outside the approved range.^[70]

Although software defined radios are an interesting development worth watching, the full programmability will probably not be implemented in 802.11 devices. (Limited programmability is used by both Broadcom and Atheros in their current chipsets.) Programmable logic is much more expensive, and would price the resulting 802.11 devices out of the market. It may find a foothold for use with 802.11 in a radio that implements several types of radio link, of which 802.11 is one.

At the time this book was written, there were four major chipsets used to build 802.11 vendors. In alphabetical order, the established vendors are:

One of the more notable new chipset vendors is Airgo Networks, which is building a MIMO chipset that underlies prestandard 802.11n products on the market.

It is often useful to know the chipset vendor behind the card. Most of the chipset vendors make reference designs available to their customers. Reference designs typically include both hardware and software. 802.11 card vendors can take a reference design, modify it slightly (or not at all), arrange for a new label to be put on the manufactured device, and start selling it. Very few card vendors make significant enhancements to the driver, and will simply repackage reference drivers. Naturally, the track record of different vendors varies. Some make updated drivers available quickly, others may not. Knowing who supplied the chipset in the card can make it easier to obtain either the reference driver, or a more recent driver for another similar card using the same chipset. Naturally, knowing the chipset is vital for picking out the correct driver for open souce operating systems.

802.11 is a complex protocol with many options, and running the newest protocols exposes the newest bugs. 802.11 interfaces use relatively general-purpose microprocessors running software. As with a great deal of software, cards that are in a strange state may be helped by “rebooting" to clear any protocol state stored in the MAC processor. External cards can be rebooted by removing and re-inserting them; internal cards must be rebooted by power cycling them through the system software. It is not sufficient to unload and reload drivers, since the object is to clear all state in the wireless LAN interface.

Restarting a card may be required to clear state that is preventing successful operation. As a first step, restart the card when:

Every card behaves differently when searching for a network to attach to, and in how it decides to move between APs. 802.11 places no constraints on how a client device makes its decision on how to move between APs, and does not allow for any straightforward way for the AP to influence the decision. Most client systems use signal strength or quality as the primary metric, and will attempt to communicate with the strongest AP signal.

Most cards monitor the signal-to-noise ratio of received frames, as well as the data rate in use, to determine when to roam to a new AP. When the signal-to-noise ratio is low at a slow data rate, the client system begins to look for another AP. Many clients put off moving as long as possible, in part because the process of looking for a new AP requires tuning to other channels and may interrupt communications in process. Client stickiness is sometimes referred to as the bug light syndrome. Once a client has attached to an AP, it hangs on for dear life, like a bug drawn to a bug zapper. Even if the client moves a great distance from the AP with a consequent drop in signal strength, most clients do not begin the roaming process until the signal is almost lost.

Roaming in 802.11 is entirely driven by client decisions. Where to send the Association Request frames is entirely in the hands of the client system’s driver and firmware, and is not constrained by the 802.11 specification in any way. It would be 802.11-compliant, though awful, to connect to the AP with the weakest signal! (An unfortunate corollary is that driver updates to fix bugs may alter the roaming behavior of client systems in undesirable ways.) Access points do not have protocol operations that can influence where clients attach to, and whether they will move or not. Implementing better roaming technology is a major task for 802.11 as time-critical streaming applications begin to use 802.11.

802.11 lays out basic ground rules for how multirate support needs to work, but it leaves the rate selection algorithm up to the software running on the interface. Generally speaking, an interface tries to transmit at higher speeds several times before downgrading to lower speeds. Part of that is simply common sense. In the time it takes to transmit a frame with a 1,500-byte payload at 1 Mbps, it would be possible to transmit the same frame 8 times at 11 Mbps, or over 20 times on an 802.11g network running at 54 Mbps with protection enabled. (Without protection, the multiplier is 40!) If the frame was corrupted by a one-time event, it makes sense to retry a few times before accepting the more drastic penalty of lowering the data rate.

Step-down algorithms are generally similar. After trying some number of times to transmit a frame, it falls to a lower data rate. Most cards step down one rate at a time until an acknowledgment is received, though there is no requirement for them to do so. It would be a valid rate selection algorithm to slow down to the minimum data rate at the first sign of trouble. Step-up algorithms work the same way in reverse. When “several” frames are received with a much higher signal-to-noise ratio than is required for the current rate, the interface may consider stepping up to the next highest rate.

As an example, compare the sensitivity of some common 802.11b cards. Sensitivity is defined by each 802.11 PHY. For the direct sequence rates, it is defined as the received power at which the input frame error rate is 8%, for 1024 byte frames. The standards require that the sensitivity be -76 dBm or better for 11 Mbps, and -80 dBm for 2 Mbps.^[71] Lower sensitivity is better because it means the card can receive weaker signals than required.

The sensitivities reported in Table 16-1 were taken from data sheets and user manuals for four well-known 802.11b cards and a new a/b/g card. The Cisco Aironet 350 had a reputation for pulling in weak signals well, which is entirely justified by the data. At 11 Mbps, it was sensitive to a signal half as strong as the Orinoco Gold card, and nearly a quarter of the signal required by the Microsoft card. However, the march of technology has improved sensitivities at higher bit rates. All the older-generation cards are less sensitive than the Atheros-based Cisco tri-mode card currently on the market.

When radio waves bounce off objects, several echos of the wave will converge on the receiver. The difference between the first wave’s arrival and the last arrival is the delay spread. Receivers can pick through the noise to find the signal, but only if the delay spread is not excessive. Some vendors also quote the maximum delay spread on their data sheets. Table 16-2 reports the delay spread for three of the cards listed above.

Cards rated for higher delay spreads are capable of dealing with worse multipath interference. Again, the Cisco Aironet 350 was an extremely capable card for its day, capable of dealing with over twice the time-smearing as the Hermes-based card.