General Structure of an 802.11 Interface

Figure 16-1 shows a block diagram of a generic wireless LAN interface. It is not representative of any particular manufacturer's product, but is intended to serve as a general guide to the discussion of how cards are put together. Cards must implement the physical interface and the link-layer control expected by the operating system.

Like any other system based on radio technology, wireless LAN interfaces have antennas. Most 802.11 interfaces have two antennas for antenna diversity to improve reception in the presence of multipath interference. When a radio signal is received, the radio system selects the antenna with the strongest signal, and runs with it. Antenna diversity alleviates multipath because one of the two antennas should receive a signal if the weak signal is caused by self-interference of multiple signals. Diversity cannot help if the signal weakness is caused by distance because both antennas will receive equally weak signals. Many types of diversity are possible, but by far the most common implementation is to perform diversity reception on received frames only. Most, if not all, products on the market do not have any diversity for transmitted frames, and will always use a "primary" antenna for transmissions.

Early antenna diversity implementations were helpful, but limited by lack of sophistication. Multiple-input/multiple-output (MIMO) technology promises higher data rates and better performance. Detailed descriptions of MIMO are beyond this book. In essence, it improves the receiver's performance by using both antennas rather than choosing one exclusively.

Figure 16-1. Generic wireless card structure

Antennas deliver the radio signal to a transceiver. The transceiver is sometimes called a radio "modem" by analogy with the modems commonly used for telecommunications. Transceivers will use amplifiers to boost the outgoing signal for distance, or the incoming signal for further processing. Radio transceivers also downconvert the high-frequency signals into much more manageable signals by extracting the data bits from the high-frequency carrier waves. Transceiver systems are usually shielded to prevent the high frequencies in use from interfering with other system components, which is why radio interfaces typically have a metal shield covering a good chunk of the interface card's area.

After the transceiver, the next step in the chain is the baseband processor, which is the interface between the digital and analog parts of the wireless LAN system. Bits come from the computer, and are turned into radio waves for the antennas. Turning bits into radio waves is called modulation; the reverse process is called demodulation. The baseband processor is responsible for handling the complex spread-spectrum modulations, as well as physical carrier sensing. Generally speaking, physical carrier sensing is integrated with demodulation. When radio energy is received in excess of a threshold, the baseband processor attempts to demodulate it. Many different modulation techniques exist for use with wireless LANs. One of the reasons why older 802.11b stations are blind to the existence of 802.11g transmissions is that the older baseband processors used in 802.11b stations are not capable of demodulating OFDM transmissions.

At the heart of the interface is the medium access controller (MAC), which is responsible for taking incoming frames from the host operating system's network stack and deciding when to squirt the frames out the antenna into the air. The MAC accepts frames from the operating system for delivery through a system bus interface. Most wireless LAN interfaces are based on the CardBus standard; some interfaces use Mini-PCI. On the other side of the MAC, it ties into the baseband processor to send frames to the radio system.

MACs may work with several frames at once, and can use a small RAM buffer to store frames being worked on. One of the most common reasons to work on a frame is to offload security functions from the host operating system. Rather than requiring frames to have been encrypted by the main system CPU before transmission, a MAC with security functions can accept frames from the driver that are to be encrypted with a specified key. Frequently, such MACs implement a key cache, which can store multiple keys. Drivers queue frames with a notation to encrypt with key 1 before transmission, and the MAC offloads the encryption from the host system. Older MAC chips could perform RC4 encryption offload for WEP and could be retrofitted for TKIP, while the newest MAC chips are able to perform AES encryption in hardware.

In addition to the RAM buffer for frames in process, most interfaces also have a small flash memory to store firmware for the MAC. When the MAC is powered up, it retrieves and runs code from flash. To implement a new security protocol like TKIP, put new firmware in the flash and reboot the MAC. Firmware allows the use of relatively generic processors rather than hard-to-change application-specific integrated circuits (ASICs), which is a great help when working with protocols like 802.11 that may change quickly. Most 802.11 MAC chips are actually fairly generic microprocessors.

Some MACs implement a "real-time" section of the 802.11 MAC for items that require immediate response. Rather than requiring the host operating system to respond to power-save polling operations or send acknowledgments, these frames are often automatically generated by the MAC. In other systems, the real-time functions are handled by the baseband processor. (Most modern systems implement both the MAC and baseband in a single chip, so the distinction is no longer of burning relevance.)

The block diagram of Figure 16-1 is a general guide only. To reduce cost and complexity, many systems use a single chip for both the MAC and the baseband processor. Some solutions even implement the radio transceiver on the same chip as the MAC and baseband controller. Interfaces based on Atheros chipsets do not have flash memory for firmware because Atheros chips are given code when the MAC is started by the driver. Firmware generally refers to code stored with the hardware; Atheros devices can be programmed by system software.

Software-Defined Radios: A Digression

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.[*] 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.[]

[] Its intereting to note that the open source process has started to adopt programmable logic. OpenCores (http://www.opencores.org) is the repository of hardware designs in the same pattern that SourceForge (http://www.sourceforge.net) is for software.

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.[]

images/ent/U2021.GIF border=0>] The FCC rules regarding the certification of software-defined radios are in Appendix B of FCC 01-264, which is available at http://www.fcc.gov/Bureaus/Engineering_Technology/Orders/2001/fcc01264.pdf. The first software-defined radio, a GSM base station developed by Vanu, was certified in November 2004.

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.

A Few Words on 802.11 Hardware Implementations

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:

Atheros

Most interfaces that include 802.11a are based on Atheros chipsets. Many 802.11g devices are based on Atheros chipsets as well.

Broadcom

Most of the non-Centrino built-in 802.11g interfaces available at the time this book was written were based on the Broadcom 802.11g chipset. Apple's AirPort Extreme is based on Broadcom silicon.

Conexant (Prism)

The Prism chipset line went through several corporate transitions before it wound up at Conexant.

Intel (Centrino)

Many built-in wireless LAN interfaces in laptops are based on Intel's "Centrino" brand. Technically, Centrino is a marketing term that refers to a whole set of Intel silicon, including the system CPU. For example, the Intel/PRO 2200 card is the the Centrino 802.11g interface.

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.

Learning more about cards: FCC filings

802.11 interfaces are, in the language of regulatory agencies, intentional radiators. Rather than simply complying with a standard that limits the amount of radio frequency energy given off, 802.11 interfaces are designed to spew radio waves into the air. Intentional radiators are tested for compliance with every country's regulatory requirements, which generates a great deal of paperwork.

In the United States, radio devices are regulated by the Federal Communications Commission (FCC), and radio transmission devices are tested for compliance with FCC rules. Before a device can legally be sold, it must be assigned an identification number. Take a look at your favorite card and look for the FCC ID.

An FCC ID is composed of two parts: the grantee code, which is the first three letters, and the product code, which may be up to 14 letters and numbers. Grantee codes are unique to an organization. (The grantee code may be separated by a space, dash, or not at all.) For example, the FCC ID for a Lucent Gold card is IMR-WLPCE24H. IMR is Lucent's grantee code, while WLPCE24H is specific to the Gold card.

As part of the testing process, manufacturers must submit test reports, product photographs, and other documentation, which becomes part of the public record. To look up information on your favorite card, go to the search engine maintained by the FCC's Office of Engineering Technology at http://www.fcc.gov/oet/fccid/.

FCC identifiers can be useful if you are trying to figure out what driver to use with a particular card. Most products have internal photographs available, which may enable you to determine whose chipset is in use. Say, for example, you had a Proxim Gold a/b/g combo card and wanted to know what chipset it used. By searching the FCC database on its ID (HZB-8460), you could obtain internal photographs of the device, which clearly show the presence of Atheros chips on the system board.