1 / 19

Legacy Coexistence – A Better Way?

Exploring the challenges in coexistence between different Wi-Fi standards and proposing solutions for improved legacy compatibility and performance. Discover how mid-packet CCA and parallel detection mechanisms can enhance wireless network efficiency.

aeloise
Download Presentation

Legacy Coexistence – A Better Way?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Legacy Coexistence – A Better Way? • Authors: • Date: 2007-11-26 Hart et al (Cisco)

  2. Summary • Some say VHT should steer clear of 5 GHz because of the coexistence problems • 11n has taken a long time to resolve just 20/40 coexistence • We argue that this is mainly because of limitations in early implementations leading to standards compromise • If we start with solid PHY coexistence via additional modest RX requirements, many coexistence problems disappear Hart et al (Cisco)

  3. Coexistence of 11n with 11abg is a standards compromise • A collection of protections • some for sound technical reasons • others based on what vendors had (or had not) implemented some time in the past Hart et al (Cisco)

  4. Some coexistence mechanisms are disconnected from legacy behavior • In 20/40, CCA protection via ED at -62 dBm on the secondary • More hidden nodes on the secondary • With GF, CCA protection via ED at -72 dBm • More hidden nodes with GF • In 20/40, no virtual carrier sense on the secondary • RTS, CTS, CTS2self on secondary not respected • Duration/ID field on secondary not respected • Duration/ID field in 40 MHz frames not respected by legacy and non-40MHz devices on either channel (weak ACK protection, should start a TXOP with a 20 MHz frame) • In 20/40 exponential backoff using medium busy measured on the primary only, with a brief (PIFS) CCA inspection on the secondary • Less responsive to congestion on the secondary channel Hart et al (Cisco)

  5. Can We Devise An Improved CCA? • ED at -82 dBm is challenging: • Requires either a low noise floor or causes a higher false-busy rate • Preamble detection at -82 dBm is well understood for 20 MHz • For 40/80/160 MHz, this requires 2/4/8 parallel filters for each 20 MHz sub-channel, and parallel short symbol detectors • Preamble detection is ineffective after a transmission, for in-progress frames on other 20 MHz channels • We need a mid-packet CCA Hart et al (Cisco)

  6. Mid-Packet CCA • Packet detection without a preamble • No carrier frequency recovery • No timing recovery • No channel estimation • OFDM looks like Gaussian noise yet can be identified by its regular cyclic extension • Note: mid-packet CCA is possible for DSSS and CCK also • DSSS cross-correlation • CCK is composed of QPSK chips, so x4/|x|3 looks like DC • Obscured by carrier frequency offsets and delay spread Hart et al (Cisco)

  7. Example Scheme for Mid-Packet CCA for OFDM • Many further improvements are possible (e.g. short GI) Hart et al (Cisco)

  8. Mid-Packet CCA Performance – Channel Type & Detection Duration Hart et al (Cisco)

  9. Mid-Packet CCA Performance – SNR Hart et al (Cisco)

  10. Mid-Packet CCA Performance – Carrier Frequency Offset Hart et al (Cisco)

  11. Mid-Packet CCA Performance – Number of RX Antennas Hart et al (Cisco)

  12. How to Interop Test for Mid-Packet CCA Compliance • Test 1: 40 MHz BSS enabled. 20 MHz BSS on primary alternates (a) periods of near-100% duty cycle long-packet SIFS-spaced traffic with (b) periods of no traffic. Record PER. • Test 2: 40 MHz BSS enabled. 20 MHz BSS on secondary alternates (a) periods of near-100% duty cycle long-packet SIFS-spaced traffic with (b) periods of no traffic. Verify 40 MHz frames are transmitted from B to A (e.g. via MAC stats). Record PER. • Any excess PER from test @ to test 1 is due to disallowed transmissions from DUT B Hart et al (Cisco)

  13. Summary of Coexistence Mechanisms • Parallel start-of-packet detection on each 20 MHz channel is feasible • Parallel filters and short symbol detectors • Parallel mid-packet detection on each 20 MHz channel is feasible • Parallel filters and cyclic extension detectors • Behavior at packet end is TBD: EIFS backoff? Something else? • Parallel PLCP decoding on each 20 MHz channel is tougher but is not so hard it can be ruled out yet • Parallel receivers, but for the brief BPSK PLCP only • Parallel virtual carrier sense on each 20 and 40 MHz channel is infeasible • Fully parallel receivers • Ability to receive on one channel even when transmitting on a nearby channel Hart et al (Cisco)

  14. Questions? • ? Hart et al (Cisco)

  15. Strawpoll • If VHT produced a PAR for 5 GHz operation, would you support further investigation into improved legacy coexistence methods such as are described on slide 13? • Yes • No • Abstain Hart et al (Cisco)

  16. Backup Slides Hart et al (Cisco)

  17. Open Problems • What about false alarms from other wireless systems? • What about false alarms from adjacent-channel WiFi? • How well does this work with short-GI? Hart et al (Cisco)

  18. False Alarms from Non-WiFi Signals • Previous scheme was optimized for OFDM vs noise • What about false alarms from other wireless systems? • Sinusoids that positively autocorrelate at any delay • Narrowband signal that approximate sinusoids • etc • Target the cyclic extension specifically: • We have a positive autocorrelation for 800ns then “noise” for 3.2us • Replace 800ns moving average impulse response with an impulse response with zero mean Hart et al (Cisco)

  19. False Alarms from Non-WiFi Signals – Still OK against noise Hart et al (Cisco)

More Related