Comparison and Conclusions

Both proposals are essentially MIMO evolutions of the 802.11a PHY. Both require support for a 2x2 mode, where both the sender and receiver have two transceivers active. However, it is likely that most products that are based on the eventual 802.11n standard (which may or may not resemble either of the proposals) will support at least some of the optional modes. It is likely that cost constraints on client devices will restrict them to operating in a two-transceiver mode, while APs will have more transceivers. Basic APs may have only two, while the most expensive enterprise-class APs have three or four transceivers.

Table 15-5 shows the data rates for the two spatial stream modes for each proposal. Higher data rates are possible with additional spatial streams, albeit at the extra cost of silicon. TGnSync's proposed peak rates are higher, although at the cost of more aggressive coding. WWiSE's 135 Mbps data rate is accomplished by using 64-QAM at R=5/6; TGnSync gets to 140 Mbps by using a 7/8 rate code and cutting the guard interval to half. (Without the short guard interval, TGnSync's data rate is only 126 Mbps.) The advanced beamforming mode uses the much larger 256-QAM constellation. Though TGnSync's data rates are higher, I expect that the more aggressive coding will lead to shorter range.

Table 15-5. Top speed for major 802.11n proposals (two spatial streams)

 

20MHz channels

40 MHz channels

WWISE

135 Mbps

270 Mbps

TGnSync

   

Basic mode

140 Mbps (+3.7%)

315 Mbps (+16.7%)

Advanced beamforming mode

160 Mbps (+18.5%)

360 Mbps (+33.3%)

Spectral usage is a major point of contention between the two groups. WWiSE has focused much more heavily on improving MAC efficiency than on the data rate, even going so far as to argue that using 40 MHz channels to improve the data rate before improving efficiency is a waste of scarce unlicensed spectrum. While there may be merit to that point, the 40 MHz channelization approach used by TGnSync has the advantage of being able to reclaim spectrum in the middle of a wider channel. WWiSE merely doubles throughput in their 40 MHz mode, while TGnSync squeezes more than double the capacity out of the wider channel. Both approaches have their drawbacks. TGnSync's proposal would probably lead to chipsets that are always capable of 40 MHz operation, adding extra cost and complexity, even though regulators may not allow them. In countries where 40 MHz channels are allowed, the extra speed would be welcome. In areas where 40 MHz channels are only a pipe dream of chipset manufacturers, the extra cost may not be welcome. On the other hand, WWiSE's denial of the need for high-speed channels seems to be denying the five-fold leap in data rates that occurs with every new 802.11 PHY.

For maximum speed, TGnSync requires closed-loop operation, which would be a major undertaking to implement in silicon. Sounding frames must be used to measure the channel, and responses must be collected to calibrate the radio channel. WWiSE uses only open loop operation, which is simpler to implement. The WWiSE proposal also offers the ability to spread a single encoded stream across multiple antennas without using closed-loop operation. If closed-loop operation were to be problematic to implement in silicon, 802.11n could be delayed unacceptably.

Frame aggregation is an important part of meeting the larger goal set for the eventual 802.11n standard. However, taking full advantage of aggregation opportunities requires more intelligent queuing than is currently implemented. Whether 802.11n offers a huge increase in speed is likely to depend a great deal on how well improved queuing algorithms are able to coalesce collections of small packets into large aggregates. Neither proposal specifies queueing, so the performance boost may vary between vendors.

Aggregation as designed by the protocol is a bit more intelligent in TGnSync, although this is only a minor advantage. WWiSE's proposal only allows aggregation when the Address 1 field in the MAC header is the same. In an infrastructure network, the Address 1 field is the BSSID. All frames from a station to an AP can be aggregated, so the two proposals are identical in the upstream direction. In the downstream direction, WWiSE must use a physical-layer frame burst to change directions. Each new direction must have a new PLCP header. TGnSync can reduce overhead by using a multiple-receiver aggregate frame, and collecting responses from each receiver in the aggregate.

Powersaving modes in 802.11 have been neglected, and are not very sophisticated. TGnSync attempts to come up with extended powersaving operations for some of the new MAC structures, while WWiSE does not. This is likely due to the presence of equipment vendors that use chips in the TGnSync consortium, while WWiSE is comprised only of chip vendors. While the trade-off between high speed and battery life is application-specific and may not always make sense, it is always good to see the standards bodies thinking ahead about problems that may occur.

Introduction to Wireless Networking

Overview of 802.11 Networks

11 MAC Fundamentals

11 Framing in Detail

Wired Equivalent Privacy (WEP)

User Authentication with 802.1X

11i: Robust Security Networks, TKIP, and CCMP

Management Operations

Contention-Free Service with the PCF

Physical Layer Overview

The Frequency-Hopping (FH) PHY

The Direct Sequence PHYs: DSSS and HR/DSSS (802.11b)

11a and 802.11j: 5-GHz OFDM PHY

11g: The Extended-Rate PHY (ERP)

A Peek Ahead at 802.11n: MIMO-OFDM

11 Hardware

Using 802.11 on Windows

11 on the Macintosh

Using 802.11 on Linux

Using 802.11 Access Points

Logical Wireless Network Architecture

Security Architecture

Site Planning and Project Management

11 Network Analysis

11 Performance Tuning

Conclusions and Predictions



802.11 Wireless Networks The Definitive Guide
802.11 Wireless Networks: The Definitive Guide, Second Edition
ISBN: 0596100523
EAN: 2147483647
Year: 2003
Pages: 179
Authors: Matthew Gast

Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net