1. Green Field Analysis Date: 2006-02-07 Authors: March 2006 Month Year
doc.: IEEE /0452r0
March 2006
Green Field Analysis
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Bill McFarland, Atheros Communications
Bill McFarland, Atheros Communications

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

3. 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

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

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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