1. Green Field Analysis Authors: Date: 2006-07-14 July 2006 Month Year
doc.: IEEE /0452r1
Green Field Analysis
July 2006
Authors:
Date:
Bill McFarland, Atheros Communications
Bill McFarland, Atheros Communications

2. July 2006
Legal
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

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

4. Outline GF throughput analysis Legacy interop issues
July 2006
Outline
GF throughput analysis
Aggregated
Non-Aggregated
Legacy interop issues
11n interop issues
Implementation issues
Conclusion
Bill McFarland, Atheros Communications

5. July 2006
OFDM Packet Formats
Bill McFarland, Atheros Communications

6. July 2006
GF vs. MM
Extra symbols present in the mixed mode preamble serve many useful purposes:
Enable legacy devices in the BSS and neighboring BSSs to stay synchronized with the network
Simplify receiving devices by allowing simple calculation of the correct packet length, even for options the device knows nothing about
Allow the NAV to be communicated through L-SIG TXOP protection
Provide the opportunity for beamforming
Green Field preamble is not legacy compatible
Bill McFarland, Atheros Communications

7. Assumptions for Throughput Analysis
July 2006
Assumptions for Throughput Analysis
Throughput analysis includes the following assumptions:
1 AP, 1 STA
Ideal traffic patterns (e.g., bursting with unlimited TXOP)
No interference/collisions (0% PER), except TCP/IP collisions
No GF protection for legacy devices
Actual improvements due to Green Field preamble will be less in real-world environments
Bill McFarland, Atheros Communications

8. July 2006
Aggregation
Both A-MPDU and A-MSDU reception are mandatory features for all HT devices
Aggregation required to meet throughput expectations
Aggregation reduces any benefit that comes from use of GF preamble
Bill McFarland, Atheros Communications

9. GF Throughput Improvement with Aggregation (UDP)
July 2006
GF Throughput Improvement with Aggregation (UDP)
Data Rate
64 Byte Payload
1500 Byte Payload
20 subframes
2S, 300 Mbps
4.4%
1.2%
2S, 130 Mbps
3.1%
0.5%
1S, 65 Mbps
2.1%
0.3%
1S, 6.5 Mbps
0.4%
0.0%
UDP throughput improvement of GF preamble compared to MM preamble
A-MPDU aggregation, 20 subframes per aggregate
Bill McFarland, Atheros Communications

10. GF Throughput Improvement with Aggregation (TCP)
July 2006
GF Throughput Improvement with Aggregation (TCP)
Data Rate
64 Byte Payload
1500 Byte Payload
20 subframes
2S, 300 Mbps
5.0%
2.0%
2S, 130 Mbps
3.5%
1.0%
1S, 65 Mbps
2.4%
0.5%
0.0%
TCP throughput improvement of GF preamble compared to MM preamble
A-MPDU aggregation, 20 subframes per aggregate
Bill McFarland, Atheros Communications

11. GF Throughput Improvement – Non-Aggregated
July 2006
GF Throughput Improvement – Non-Aggregated
Data Rate
64 Byte Payload
1500 Byte Payload
Normal
Bursting
2S, 300 Mbs
6.6%
15.0%
3.6%
10.2%
2S, 130Mbps
6.5%
14.3%
4.5%
7.0%
1S, 65Mbps
6.2%
13.1%
3.4%
4.8%
1S, 6.5Mbps
3.2%
4.4%
0.0%
UDP throughput improvement with GF, compared to MM preamble
Bursting is SIFs spaced Data – ACK sequence with infinite TXOP
Bill McFarland, Atheros Communications

12. Legacy Mode Quite Efficient for Small Frames
July 2006
Legacy Mode Quite Efficient for Small Frames
Legacy preamble is 20us, while GF is 24/28 us
More power efficient to use single-stream when frame size is small
Data that cannot be aggregated is more likely small packets (e.g. VoIP)
Bill McFarland, Atheros Communications

13. GF Throughput vs. Legacy 54 Mb/s for VoIP Traffic with Bursting
July 2006
GF Throughput vs. Legacy 54 Mb/s for VoIP Traffic with Bursting
Data Rate
G.729, 20ms
(68 Byte payload)
iLBC, 20ms
(86 Byte payload)
2S, 300Mbps
4.2%
8.7%
2S, 130Mbps
0.0%
1S, 65Mbps
UDP throughput percentage is relative to legacy 54Mbs
SIFS bursting in use w/ infinite TXOP limit
Bill McFarland, Atheros Communications

14. July 2006
Green Field?
“green field”: A brand new installation of equipment without the requirement of integrating existing systems.
11n PAR: “The impact of an HT device on the operation of a legacy network shall be comparable to that of any other legacy device identified in the baseline defined above.”
The 5 GHz band is not a “green field”
In some geographies (e.g. Japan, Korea) half of all installed WiFi equipment is 5 GHz 11a/g
Laptops are already shipping with >75% 11a/g dual band cards
Far more dual band devices will reach the field before 11n supplants them
There are an estimated ½ billion legacy a/b/g devices. Many more will be sold before the standard is ratified.
Bill McFarland, Atheros Communications

15. GF – Legacy Interaction
July 2006
GF – Legacy Interaction
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, overlapping BSSs are unprotected
Presence of legacy devices mandates MAC protection for GF, which eliminates any throughput advantage
Bill McFarland, Atheros Communications

16. GF - Legacy Interop Issues
July 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)
L-SIG TXOP protection cannot be used with GF preamble
RTS/CTS NAV protection cannot solve the fairness (too long) issue
Bill McFarland, Atheros Communications

17. Interop Among HT (11n) Devices
July 2006
Interop Among HT (11n) Devices
11n draft includes several optional modes (>2 streams, unequal MCSs, short GI, STBC, LDPC) that will prevent all devices from decoding all packets
Network allocation vector (NAV) is in the body of the packet, and will not be decoded by all devices
L-SIG can be used to maintain NAV among HT devices (L-SIG TXOP protection)
GF preamble eliminates the L-SIG, eliminating the ability to communicate the NAV among all HT devices in a network
Bill McFarland, Atheros Communications

18. Implementation Issues
July 2006
Implementation Issues
Additional receiver complexity/cost/power is required to support GF
Need to decode HT-SIG quickly as next symbol can be data or more HT-LTFs as indicated by HT-SIG
Timing acquisition based on GF preamble is difficult
Large CSD values are applied to HT-LTF1 and HT-SIG
Channel appears to have very long delay spread
Difficult to extract timing accurately
All these problems can be overcome, but not for free
Bill McFarland, Atheros Communications

19. Decoding GF HT-SIG Only
July 2006
Decoding GF HT-SIG Only
Attempts to solve only one of the many issues: implementation complexity
Not as easy as it looks in practice
Symbol timing detection issues still present
Loss of L-SIG spoofing means all receivers must be able to calculate all packet lengths for all combinations of options
20/40 MHz
Short guard interval
Unequal MCSs (76 of them)
STBC
LDPC
NAV still lost – no L-SIG TXOP protection
Bill McFarland, Atheros Communications

20. July 2006
GF as an Option
Current draft specifies sufficient behavior to insure mixed networks of GF and non-GF devices work correctly:
9.14.2: “All STAs in the BSS shall protect Green Field PPDUs when there is at least one non-HT or non-GF STA associated with this BSS.”
20.1.3: “An HT device which does not support the reception of a GF packet shall be able to detect that GF transmissions are HT transmissions (as opposed to non-HT transmissions) and treat them as HT packets with a failing HT-SIG cyclic redundancy check (CRC).”
NAV protection insures non-GF devices don’t transmit too soon
Treatment of GF packets as HT with failing CRC insures non-GF devices to not defer too long
Bill McFarland, Atheros Communications

21. Situations where GF is safe to use and beneficial will be rare
July 2006
Conclusion
Performance benefit of GF is marginal – just a few percent in likely scenarios
GF creates legacy coexistence issues
Overlapping BSS and scanning devices
RTS/CTS protection is ineffective due to one bit parity, sleeping devices
GF creates coexistence issues in pure HT (11n) networks that support different # of streams, STBC, LDPC (no L-SIG TXOP protection)
GF creates implementation issues, increases solution cost, even if just decoding the HT-SIG
All of these issues remain even if GF HT-SIG decoding is mandatory for HT devices
Situations where GF is safe to use and beneficial will be rare
We should not require all devices to implement Green Field HT-SIG decoding
Bill McFarland, Atheros Communications