Sept 06
doc.: IEEE 802.11-06/1388r1
Unavoidable Packet Loss Issue in 802.11a/g PHY
Date: September, 2006
Authors:
Name
Tom
Alexander
Partha
Narasimhan
Company
VeriWave, Inc.
Aruba Networks
Address
Phone
8770 SW Nimbus Ave, Suite B,
Beaverton, OR 97008
503-803-3534
1322 Crossman Avenue,
Sunnyvale CA USA 94089
408-227-4500
email
[email protected]
partha@arubanetworks.
com
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
<[email protected]> 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 <[email protected]>.
Submission
Slide 1
Tom Alexander, VeriWave
Sept 06
doc.: IEEE 802.11-06/1388r1
Introduction
•
•
•
Problem statement
Calculation of probability of loss
Recommendations
Submission
Slide 2
Tom Alexander, VeriWave
Sept 06
doc.: IEEE 802.11-06/1388r1
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
Slide 3
Tom Alexander, VeriWave
Sept 06
doc.: IEEE 802.11-06/1388r1
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
Slide 4
Tom Alexander, VeriWave
Sept 06
doc.: IEEE 802.11-06/1388r1
Loss Mechanism
PLCP header
with bit errors
RX
PKT
Wireless Medium
RETRY1
RETRY2
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
Slide 5
Tom Alexander, VeriWave
Sept 06
doc.: IEEE 802.11-06/1388r1
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(CarrierLost) 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 & VoIP handsets are usually aggressive
•
Submission
Typically, 2-4 retries max (APs), 1-2 retries max (handsets)
Slide 6
Tom Alexander, VeriWave
Sept 06
doc.: IEEE 802.11-06/1388r1
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
Slide 7
Tom Alexander, VeriWave
Sept 06
doc.: IEEE 802.11-06/1388r1
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
– VoIP traffic is affected more by packet loss than by delay/jitter
Submission
Slide 8
Tom Alexander, VeriWave
Sept 06
doc.: IEEE 802.11-06/1388r1
Recommendations
•
Set acceptable loss tolerance for throughput tests >0
–
•
Minimize FER during throughput, VoIP 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.11n 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.11b does not see this issue
•
–
802.11n 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.11a/g (1 parity bit) => weak
Slide 9
Tom Alexander, VeriWave