July 2006 doc IEEE 802 11 061388 r

July 2006 doc. : IEEE 802. 11 -06/1388 r 1 Unavoidable Packet Loss Issue in 802. 11 a/g PHY Date: September, 2006 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: // ieee 802. 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>. Submission 1 Tom Alexander, Veri. Wave

Sept 06 doc. : IEEE 802. 11 -06/1388 r 1 Introduction • • • Problem statement Calculation of probability of loss Recommendations Submission 2 Tom Alexander, Veri. Wave

Sept 06 doc. : IEEE 802. 11 -06/1388 r 1 Summary of Problem • An 802. 11 compliant device should have zero actual packet loss on the wireless medium – “Packet loss” is not the same as “frame errors” – A high frame error rate (e. g. , 10%) should still result in zero packet loss; retries will compensate, and data will eventually get through • However, while running throughput tests on standards compliant devices, non-zero packet loss was found – Packets were being lost in spite of retries! – Packet loss was extremely small (0. 001%) but never went away, even with quite small offered loads • • The loss was traced to an inherent deficiency in the 802. 11 a/g PLCP header This has implications for performance tests Submission 3 Tom Alexander, Veri. Wave

Sept 06 doc. : IEEE 802. 11 -06/1388 r 1 ERP-OFDM PLCP Header & Bit Errors Header protected by 1 parity bit RATE, LENGTH define PHY packet time • PLCP RATE & LENGTH fields are key – Used by OFDM PHY to calculate duration of packet – Calculation result takes precedence over actual carrier sense • • See subclause 17. 3. 12 PLCP header protected only by a single parity bit – Probability of undetected header corruption: 50% Submission 4 Tom Alexander, Veri. Wave

Sept 06 doc. : IEEE 802. 11 -06/1388 r 1 Loss Mechanism PLCP header with bit errors RX PKT Wireless Medium RETRY 1 RETRY 2 TX RETRYn Actual Packet Duration RX “blind” time due to PLCP header error • • Example: 100 byte OFDM packet sent at 54 Mb/s Bit errors occur in PLCP header due to channel noise – – • Per Clause 17, RX must use calculated time from PLCP header, not actual All of the retries occur during the “blind” period – • The bit errors “convert” the packet into 4095 bytes @ 6 Mb/s Bit errors in PLCP header not detected because parity check is very weak The receiver is “blinded” for up to 5. 5 milliseconds – • Retries during RX “blind” time RX back to normal After last retry, the TX marks packet as failed and drops it Result: packet is permanently lost Submission 5 Tom Alexander, Veri. Wave

Sept 06 doc. : IEEE 802. 11 -06/1388 r 1 IEEE 802. 11 (2003) 17. 3. 12 • Subclause 17. 3. 12, IEEE 802. 11 -1999 (2003 Edition) "In the event that a change in the RSSI causes the status of the CCA to return to the IDLE state before the complete reception of the PSDU, as indicated by the PLCP LENGTH field, the error condition PHYRXEND. indicate(Carrier. Lost) shall be reported to the MAC. The OFDM PHY will ensure that the CCA indicates a busy medium for the intended duration of the transmitted packet. " • PLCP RX state machine (Fig 129) confirms – RX must be held in busy state until “intended end of PSDU” – Next frame cannot be received until RX goes back to IDLE state • Result: anything received after corrupted PLCP is lost – Depending on retry limit, this could be up to 3 consecutive MSDUs – Retry limits for APs & Vo. IP handsets are usually aggressive • Submission Typically, 2 -4 retries max (APs), 1 -2 retries max (handsets) 6 Tom Alexander, Veri. Wave

Sept 06 doc. : IEEE 802. 11 -06/1388 r 1 Estimated Loss Probability • Factors contributing to loss probability: – Small “actual” packet length and high “actual” PHY bit rate • – PLCP error changes to large “apparent” packet length, low “apparent” PHY bit rate • – 100 byte data packet @ 54 Mb/s 1% FER, uniform error distribution over the PLCP frame Probability calculation: – – • Compliant PHY can have 10% FER; good-quality cabled setups have as much as 1% FER Assumptions for calculation: – – • That is, the receiver is blinded for a very long period of time High FER on link • • That is, a the actual packet takes very little time to transmit or to retry Probability of frame error: 0. 01 Probability error will occur in PLCP header (100 -byte MAC frame @ 54 Mb/s): 0. 2 Probability that parity check will miss error: 0. 5 Overall probability of corrupted PLCP header = 0. 001 Worst-case probability of packet loss due to this mechanism: 0. 1% – Submission The distribution of RATE/LENGTH values in corrupted header balances out with the fact that multiple packets can be lost at one time, especially if retry limits are low 7 Tom Alexander, Veri. Wave

Sept 06 doc. : IEEE 802. 11 -06/1388 r 1 Effect On Performance Tests • RFC 2544 throughput tests are usually run with loss tolerance of zero – Loss of even one frame will cause throughput search algorithm to hunt for a lower throughput • Due to retries, wireless media would normally be assumed lossless – However, a constant frame loss probability regardless of offered load means that throughput tests can hunt right down to zero • Roaming times are significantly affected by such loss – Lose an EAP/4 -way HS packet completely, and handshake will stall • • It can be 30 seconds before RADIUS times out and restarts handshake R-value scores are also an issue – Vo. IP traffic is affected more by packet loss than by delay/jitter Submission 8 Tom Alexander, Veri. Wave

Sept 06 doc. : IEEE 802. 11 -06/1388 r 1 Recommendations • Set acceptable loss tolerance for throughput tests >0 – • Minimize FER during throughput, Vo. IP or roaming tests – – • Restart quickly if an EAP or 4 -way handshake packet is lost Add a section in 802. 11. 2 warning of this issue? – • Higher FER => higher probability of intrinsic packet loss Cabled setups, properly adjusted signal levels, well-matched radios … Set RADIUS client/server handshake retry times low – • 0. 1% acceptable loss is recommended Keep people from chasing ghosts Ensure problem does not occur in 802. 11 n PHY (mixed mode) – – It is unusual for key elements of low-level protocol headers to be protected by something as weak as a parity bit! 802. 11 b does not see this issue • – 802. 11 n in mixed mode will also have this problem • • Submission 32 -bit PLCP header is protected with a 16 -bit CRC => excellent protection HT-SIG has an 8 -bit CRC protecting SIGNAL field => good protection L-SIG has exactly the same structure as 802. 11 a/g (1 parity bit) => weak 9 Tom Alexander, Veri. Wave