Green Field Analysis Date: 2006-02-07 Authors: March 2006 Month Year doc.: IEEE 802.11-06/0452r0 March 2006 Green Field Analysis Date: 2006-02-07 Authors: Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Bill McFarland, Atheros Communications Bill McFarland, Atheros Communications

Month Year doc.: IEEE 802.11-06/0452r0 March 2006 Abstract This presentation analyzes the throughput and interoperability effects of the optional Green Field preamble described in 802.11n draft 0.2. Bill McFarland, Atheros Communications Bill McFarland, Atheros Communications

Outline GF throughput analysis Legacy interop issues March 2006 Outline GF throughput analysis Aggregated Non-Aggregated Non-Aggregated vs. legacy Legacy interop issues Implementation disadvantages Bill McFarland, Atheros Communications

OFDM Packet Formats Green Field is NOT legacy compatible March 2006 Bill McFarland, Atheros Communications

Assumptions for Throughput Analysis March 2006 Assumptions for Throughput Analysis Throughput improvements are “best case” including the following assumptions: Only 2 STAs No interference/collisions (0% PER), except TCP/IP No GF protection for legacy devices Actual improvements will be less in real-world environments Bill McFarland, Atheros Communications

GF Throughput Improvement with Aggregation March 2006 GF Throughput Improvement with Aggregation Data Rate 64 Bytes 1500 Bytes 10 subframes 20 subframes 2S, 300Mbps 5.2% 4.8% 1.7% 1.2% 2S, 130Mbps 4.5% 4.0% 1.0% 0.6% 1S, 65Mbps 4.2% 3.0% 0.5% 0.2% TCP throughput improvement of GF preamble compared to MM preamble A-MPDU aggregation Bill McFarland, Atheros Communications

GF Throughput Improvement – Non-Aggregated March 2006 GF Throughput Improvement – Non-Aggregated Data Rate 64 Bytes 1500 Bytes 2S, 300Mbps 6.7% 5.5% 2S, 130Mbps 6.5% 4.4% 1S, 65Mbps 6.0% 3.2% TCP throughput improvement with GF, compared to MM preamble, UDP type traffic But, for very short frames, it is best to use legacy rates Bill McFarland, Atheros Communications

GF Throughput vs. Legacy 54Mb/s March 2006 GF Throughput vs. Legacy 54Mb/s Data Rate Frame Length = 64B 2S, 300Mbps 0.0% 2S, 130Mbps 1S, 65Mbps -3.9% TCP throughput percentage relative to legacy 54Mbs Bill McFarland, Atheros Communications

GF Legacy Interop Issues March 2006 GF Legacy Interop Issues A 3rd party legacy STA may detect a GF frame as a legacy frame If 1-bit parity check passes (50% probability), bits in the SIGNAL field are wrongly interpreted This results in incorrect frame length, which is either dangerous to HT (too short), or unfair to legacy (too long) NAV protection cannot solve the fairness (too long) issue Bill McFarland, Atheros Communications

Legacy Interaction Common March 2006 Legacy Interaction Common Legacy devices are common Hard to go anywhere without seeing WiFi devices In some geographies (e.g. Japan, Korea) half of all WiFi equipment is 5 GHz Problems arise with legacy devices in your own BSS, devices in any overlapping BSSs, and unassociated devices scanning Current spec requires protection only for legacy devices in your own BSS Presence of legacy devices mandates MAC protection for GF, which reduces throughput Bill McFarland, Atheros Communications

RTS/CTS Protection Unreliable March 2006 RTS/CTS Protection Unreliable Devices frequently go in and out of sleep The timing of this sleeping and waking is not controlled or known by the AP If devices are asleep during the RTS/CTS exchange, they miss the protection and awake to find GF packets going by Waking legacy devices will not properly sense GF packets, will cause collisions APSD exaggerates this behavior, since devices go in and out of sleep very frequently when operating in APSD Bill McFarland, Atheros Communications

Implementation Issues March 2006 Implementation Issues Additional receiver complexity/cost/power is required to support GF Auto detections between legacy, MM and GF preambles are required Larger cyclic shifts call for different timing extraction In MM preamble, HT-SIG precedes HT-LTF1, in GF, HT-SIG follows HT-LTF1 All these problems can be overcome, but not for free Bill McFarland, Atheros Communications

March 2006 Conclusions Performance benefit of GF is marginal – just a few percent in likely scenarios GF creates legacy coexistence issues, must consider overlapping BSS as well as scanning devices GF creates implementation issues, increases solution cost All of these issues remain even if GF is mandatory for HT devices Problems associated with GF support outweigh its benefits We should not require all devices to implement Green Field preamble Bill McFarland, Atheros Communications