Doc.: IEEE 802.11-06/1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 1 Unavoidable Packet Loss Issue in 802.11a/g PHY Notice: This document has.

Slides:



Advertisements
Similar presentations
Doc.: IEEE /0256r0 Submission February 2007 A. Centonza, D. StephensonSlide 1 Limitations on the Use of EBR Notice: This document has been prepared.
Advertisements

Doc.: IEEE /90r0 Submission Nov., 2012 NICTSlide b NICT Proposal IEEE P Wireless RANs Date: Authors: Notice: This document.
Doc.: IEEE /0930r0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 1 Editor Updates since Jacksonville Notice: This document has been prepared.
Doc.: IEEE /1711r0 Submission November 2006 Matthew Fischer (Broadcom)Slide 1 Serial CTS-to-SELF (CTS2SELF) Proposal: 20/40 MHz Coexistence in.
Doc.: IEEE /0094r0 Submission November 2009 Steve Shellhammer, QualcommSlide 1 Comments on PAR Notice: This document has been prepared.
Doc.: IEEE /0907r0 Submission September 2005 Peter Ecclesine, Cisco SystemsSlide 1 dot1AM management plane Notice: This document has been prepared.
Doc.: IEEE /0644r2 Submission May 2006 Päivi Ruuska, NokiaSlide 1 Measurement Pilot Transmission Information as optional information in Probe.
Doc.: IEEE /0534r0 Submission May 2005 Steve Shellhammer, Intel CorporationSlide 1 Thoughts on Modifications of the TGn Functional Requirements.
Doc.: IEEE /0072r0 SubmissionS. Filin H. Harada, NICTSlide 1 Coexistence algorithms Notice: This document has been prepared to assist IEEE
Doc.: IEEE /0179r0 Submission April 2007 Wu Yu-Chun, Huawei HisiSlide 1 CRC_Length_and_FEC_gain_of_PSDU for the IEEE P Wireless.
Doc.: IEEE /0054r0 Submission May 2011 Slide 1Hyunduk Kang, et al, ETRI Discussion on mode of management service Notice: This document has been.
Doc.: IEEE /0044r0 Submission November 2005 Steve Shellhammer, Qualcomm Inc.Slide 1 Au Update on Estimating Packet Error Rate Caused by Interference.
Doc.: IEEE /1606r0 Submission January 2005 Darwin Engwer, Nortel NetworksSlide 1 AP Functions Diagram Notice: This document has been prepared.
Doc.: IEEE /1212r0 Submission TGT and MEF Liaison Notice: This document has been prepared to assist IEEE It is offered as a basis for.
Doc.: IEEE /86r2 Submission March, 2010 Gabor BajkoSlide 1 Location Proxy Notice: This document has been prepared to assist IEEE It is.
Doc.: IEEE /0667r0 Submission July 2005 Mike Moreton, STMicroelectronicsSlide 1 Multiple Networks Notice: This document has been prepared to assist.
Doc.: IEEE /0039r1 Submission January 2007 Larry Green, Ixia Slide 1 TCP Parameters and Settings Notice: This document has been prepared to assist.
Doc.: IEEE /0197r0 Submission March 2005 Nancy Cam-Winget et alSlide 1 TAP & JIT Merge Process Notice: This document has been prepared to assist.
Doc.: IEEE /0182r1 Submission Sept 2006 Menzo WentinkSlide 1 TIM Request Notice: This document has been prepared to assist IEEE It is.
Doc.: IEEE /0652r1 Submission May 2007 Emily Qi, Intel CorporationSlide 1 TGv Redline D0.12 Insert and Deletion Notice: This document has been.
Beacon Measurement on Pilot Frames
LB84 General AdHoc Group Sept. Closing TGn Motions
[ Interim Meetings 2006] Date: Authors: July 2005
Latency-sensitive Applications - metrics
IEEE WG Status Report – July 2005
LB73 Noise and Location Categories
LB73 Noise and Location Categories
Waveform Generator Source Code
LSIG Spoof Length Error
March 2014 Election Results
Legacy OFDM Transmission on several Antennas
Attendance and Documentation for the March 2007 Plenary
[ Policies and Procedure Summary]
Effect of FCH repetition on the detection of FCH and MAP
Motion to accept Draft p 2.0
Protected SSIDs Date: Authors: March 2005 March 2005
(Presentation name) For (Name of group) (Presenter’s name,title)
On Coexistence Mechanisms
TGu-changes-from-d0-02-to-d0-03
Contribution on Location Privacy
IEEE WG Opening Report – March 2007
On Coexistence Mechanisms
Reflector Tutorial Date: Authors: July 2006 Month Year
TGv Redline D0.07 Insert and Deletion
TGv Redline D0.06 Insert and Deletion
Experimental DTV Sensor
IEEE P Wireless RANs Date:
Selection Procedure Recommendation
IEEE P Wireless RANs Date:
IEEE P Wireless RANs Date:
TGu-changes-from-d0-01-to-d0-02
LB73 Noise and Location Categories
TGy draft 2.0 with changebars from draft 1.0
A novel hidden station detection mechanism
TGv Redline D0.10 Insert and Deletion
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Redline of draft P802.11w D2.2 Date: Authors:
TGu-changes-from-d0-02-to-d0-03
[ Policies and Procedure Summary]
Draft P802.11s D1.03 WordConversion
Questions to the Contention-based Protocol (CBP) Study Group
EC Motions – July 2005 Plenary
TGu-changes-from-d0-04-to-d0-05
for video transmission, Status
TGu-changes-from-d0-03-to-d0-04
Counter Proposal to CID 7177
TGu Motions Date: Authors: May 2006 May 2006
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Greenfield protection mechanism
Unavoidable Packet Loss Issue in a/g PHY
Presentation transcript:

doc.: IEEE /1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 1 Unavoidable Packet Loss Issue in a/g PHY 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, 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. Date: September, 2006 Authors:

doc.: IEEE /1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 2 Introduction Problem statement Calculation of probability of loss Recommendations

doc.: IEEE /1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 3 Summary of Problem An 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 a/g PLCP header This has implications for performance tests

doc.: IEEE /1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 4 ERP-OFDM PLCP Header & Bit Errors 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 PLCP header protected only by a single parity bit –Probability of undetected header corruption: 50% RATE, LENGTH define PHY packet time Header protected by 1 parity bit

doc.: IEEE /1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 5 Loss Mechanism Example: 100 byte OFDM packet sent at 54 Mb/s Bit errors occur in PLCP header due to channel noise –The bit errors “convert” the packet into 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 –Per Clause 17, RX must use calculated time from PLCP header, not actual All of the retries occur during the “blind” period –After last retry, the TX marks packet as failed and drops it Result: packet is permanently lost PKTRETRY1RETRY2RETRYn RXTX Wireless Medium PLCP header with bit errors Retries during RX “blind” time RX back to normal Actual Packet Duration RX “blind” time due to PLCP header error

doc.: IEEE /1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 6 IEEE (2003) Subclause , IEEE (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 PHY- RXEND.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 Typically, 2-4 retries max (APs), 1-2 retries max (handsets)

doc.: IEEE /1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 7 Estimated Loss Probability Factors contributing to loss probability: –Small “actual” packet length and high “actual” PHY bit rate That is, a the actual packet takes very little time to transmit or to retry –PLCP error changes to large “apparent” packet length, low “apparent” PHY bit rate That is, the receiver is blinded for a very long period of time –High FER on link Compliant PHY can have 10% FER; good-quality cabled setups have as much as 1% FER Assumptions for calculation: –100 byte data 54 Mb/s –1% FER, uniform error distribution over the PLCP frame Probability calculation: –Probability of frame error: 0.01 –Probability error will occur in PLCP header (100-byte MAC 54 Mb/s): 0.2 –Probability that parity check will miss error: 0.5 –Overall probability of corrupted PLCP header = Worst-case probability of packet loss due to this mechanism: 0.1% –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

doc.: IEEE /1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 8 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

doc.: IEEE /1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 9 Recommendations Set acceptable loss tolerance for throughput tests >0 –0.1% acceptable loss is recommended Minimize FER during throughput, VoIP or roaming tests –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 –Restart quickly if an EAP or 4-way handshake packet is lost Add a section in warning of this issue? –Keep people from chasing ghosts Ensure problem does not occur in 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.11b does not see this issue 32-bit PLCP header is protected with a 16-bit CRC => excellent protection –802.11n in mixed mode will also have this problem HT-SIG has an 8-bit CRC protecting SIGNAL field => good protection L-SIG has exactly the same structure as a/g (1 parity bit) => weak