1 / 9

Cropping VHT Basic/Supported MCS Sets from Below

Cropping VHT Basic/Supported MCS Sets from Below. Date: 2012-03-06. Slide 1. Situation (1/3). Very challenging environment 500 people each with devices in close proximity, starting with 20-40% retries in reality Native client algorithms are not optimized for this case

noreen
Télécharger la présentation

Cropping VHT Basic/Supported MCS Sets from Below

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. Cropping VHT Basic/Supported MCS Sets from Below Date: 2012-03-06 Slide 1 Brian Hart, Cisco Systems

  2. Situation (1/3) • Very challenging environment • 500 people each with devices in close proximity, starting with 20-40% retries in reality • Native client algorithms are not optimized for this case • Clients mostly stick to the doorway AP, stick at 2.4 GHz, rate adapt to inefficient low MCSs • Infrastructure has to load balance across APs, band-steer 5 GHz-capable devices to 5 GHz, control cell size by a) constraining TX powers, b) cropped-from-below Basic sets, and c) cropped-from-below-but-less-so Supported sets, change WMM/EDCA parameters, etc • Infrastructure needs every tool in the toolkit • We don’t want to go backwards! 500 great 802.11 customers

  3. Situation (2/3) • In the past, Basic Rate Set/Basic MCS Set has been used in two ways: • “My hardware can’t go higher than this data rate” • “To improve spectral efficiency (and reduce sticky clients), don’t send data/mgmt frames within the BSS below this rate” •  11a/b/g/n defined a bit mask so they enable both ways trivially. • In 11ac, our encoding only enables the first way

  4. Situation (3/3) • Too many clients are optimized for the home/isolated hotspot • Once associated to an AP, clients stick to it, even when there is a much closer AP • Data rates are much slower than they need to be • Spectral efficiency and spatial reuse is markedly diminished • So we control cell size by deleting lowest 11a/11n rates • Beacons at are sent at 12/24 Mbps • Clients must roam when they can’t decode the beacon

  5. Problem • But, just deleting the lowest 11a/11n MCSs still leaves spectral efficiency at the mercy of the client • We see clients not receiving acks due to collisions rate-adapt down from 64QAM, 16QAM, QPSK to BPSK • Even though only 10 ft from the AP • Even though these lower rates lengthen the PPDU and actually increase collision rates! • We see clients always sending BAs at the lowest PHY rate, impacting BSS throughput • We need the ability to crop the basic and AP’s supported rate sets from below as a workaround for these clients • Distracted by the beauty of the 11ac encoding, we made an oversight in 11acD2.0

  6. Proposal (1/3) • Define 3 bits to delete VHT MCSs from below in the VHT Basic MCS Set and VHT Supported MCS Set • VHT Operation element is (often thought of as) extensible (see P65L10) so append an optional octet containing these 3 bits 2 or 3 In this optional octet, use these 3 bits to indicate compactly which VHT MCSs are deleted from the VHT Basic MCS Set Also delete them from the RX MCS Map (i.e. VHT Supported MCS Set)

  7. Proposal (2/3) What not to worry about: • “Mandatory” means mandatory and this has higher precedence than “Basic”. • Basic and Supported rates just define the required and desired rates within the BSS • Even if we remove a rate from the VHT Basic MCS Set, a) an AP must still be able to receive frames from outside the BSS (such as a Probe Request sent in a VHT PPDU), and b) a STA ultimately must still be able to receive control frames sent at a non-basic mandatory rate: e.g. • 9.7.6.5.3 Control response frame MCS computation … If none of the above conditions is true, the CandidateMCSSet is the combination of the BSSBasicMCSSet and the VHTBSSBasicMCSSet parameters. If the combined BSSBasicMCSSet parameter is empty, the CandidateMCSSet shall consist of —the set of mandatory HT PHY MCSs, if the STA eliciting the response is an HT STA that is not a VHT STA; —the set of mandatory HT and VHT PHY MCSs, if the STA eliciting the response is an VHT STA. • Deleting rates from “Basic” just means we don’t want data/mgmt frames sent within the BSS at those deleted rates – but the PHY RX HW will still receive them (note: upper layers could discard them)

  8. Proposal (3/3) • We could disable by spectral efficiency, under the assumption that an overlapping BSS can use the unused medium time*medium bandwidth • Least true for 20 MHz (since secondary20 is a disfavored primary channel), BUT rates in 11n can only enabled/disabled by spectral efficiency (i.e. no BW granularity); but sadly we’re pretty-much stuck with this (see backup slide) • Yet, we don’t want to push devices towards 20 or 40 MHz just for range, and thereby using more medium time, so we delete the lower-bandwidth PHY rates more aggressively • This is our preferred proposal

  9. Backup Slide • 10.39.1 Basic VHT BSS functionality • A VHT STA sets the Rx MCS Bitmask of the Supported MCS Set field of its HT Capabilities element according to the setting of the Rx MCS Map subfield of the VHT Supported MCS Set field of its VHT Capabilities element as follows: for each subfield Max MCS For n SS, 1<=n<=4, of the Rx MCS Map field with(#2098) a value other than 3 (no support for that number of spatial streams), the STA shall indicate support for MCSs 8(n-1) through 8(n-1)+7 in the Rx MCS Bitmask, where n(#2043) is the number of spatial streams.

More Related