802.11ax HE Channel Access

There are multiple functions in which a client or AP can gain access to the channel. What we’re going to discuss is in addition to the HCF and DCF.

• TXOP duration-based RTS/CTS
• Intra-BSS or inter-BSS frame determination
• SRG PPDU determination
• Two NAVs
• MU-RTS/CTS
• EDCA using MU EDCA parameters

GOOD NEWS, CTS IS NOT GOING ANYWHERE!

It’s all new ways of thinking about channel access but with added complexity. You’re dealing with multi-access, TXOP, BSS coloring which complicates the channel access process.

TXOP Duration-based RTS/CTS

HE AP can use TXOP duration-based RTS/CTS exchanges to mitigate interference for dense environments.

RTS/CTS is now under TXOP Duration RTS Threshold.

There is a TXOP Duration RTS Threshold subfield within the HE Operation element. To disable TXOP Duration RTS Threshold, the AP can set this subfield to a value of 1023. A client receiving a non-zero value from the AP will set its TXOP Duration RTS Threshold to the value of the TXOP Duration RTS Threshold subfield.

A client shall use an RTS/CTS exchange to initiate a TXOP if the feature is enabled and:

• The client intends to transmit unicast frames to the AP or to a TDLS peer client
• The transmission opportunity duration is greater than or equal to 32 μs * RTS/CTS threshold. (Ex: RTS/CTS threshold = 300 & duration is 12345. Then 12345 μs > 32*300=9600)

The RTS and CTS frames contain a Duration field that defines the period of time that the medium is to be reserved to transmit the actual Data frame and the returning ACK frame.

The AP can also send a MU-RTS and simultaneous CTS responses by clients prior to the actual Data frames is another means of distribution of the medium reservation information.

Otherwise, the client follows the normal DCF rules used today by 802.11ac.

Intra-BSS and Inter-BSS Frame Determination

Client determines if received PPDU is an inter-BSS PPDU based on the following:

• BSS_COLOR is not 0 and is not the same BSS color which the client is a member. Pretty much is the client doesn’t have the same BSS color.
• BSS_COLOR is not 0 and if HE client is associated with a non-HE AP. If the client is not associated to a 802.11ax AP

Client determines if received PPDU is an intra-BSS PPDU based on the following:

• BSS color is the same as the client
• The frame carries an RA/TA/BSSID field value that is equal to the BSSID the client is associated with

Essentially, in order for a transmitter to determine whether it can obtain access to the shared medium, it must determine if a received frame is within its own BSS color or not.

SRG PPDU Identification

A client looks to the Spatial Reuse Parameter Set element to see if the SRG Information Present subfield has been set to 1. It’s used to identify BSSs that are members of the client’s SRG.

It will be used by the client to identify if the received inter-BSS frame is a SRG frame.

It is used during Spatial Reuse Parameter (SRP) OBSS (Overlapping Basic Service Set) PD operation. We will have a dedicated episode on Spatial Reuse.

Updating Two NAVs

HE clients must maintain two NAVs. A HE AP can maintain two NAVs. Those two NAVs are:

• intra-BSS NAV
• Basic NAV

Within the intra-BSS PPDU will be the intra-BSS NAV. The basic NAV, as we have known it previously, can be updated within the inter-BSS PPDU or a PPDU that is not classified as an intra-BSS or inter-BSS. That classification is covered under Intra-BSS or Inter-BSS frame determination – which we just talked about earlier.

The purpose of two NAVs is to protect frames from clients within the intra-BSS and inter-BSS in dense environments. It gives more control to the AP in order to decide which clients will contend to the channel within a given TXOP.

As HE AP obtains TXOP, the intra-BSS NAV prevents associated clients from contending for the channel. Because the basic NAV is not updated during AP’s TXOP, the client will not transmit even if it received a trigger frame from the AP.

If both NAVs equal zero, the medium is idle. If one of the two NAVs is nonzero, the virtual CS is that the medium is busy. EASY RIGHT? ^^

Intra-BSS NAV Updates:

The intra-BSS NAV will be updated if a client receives/sends a intra-BSS frame with a duration higher than the current value of the intra-BSS NAV within a given TXOP.

The intra-BSS NAV will also be updated if the client receives a trigger frame from the AP.

Basic NAV Updates

The basic NAV will be updated if the inter-BSS frame RA is not the address of the STA. Still using the Duration ID Field.

MU-RTS/CTS Procedure

The MU-RTS/CTS procedure allows an AP to initiate a TXOP and protect the TXOP frame exchange.

The AP transmits an MU-RTS/CTS trigger frame to solicit simultaneous CTS responses from one or more HE STAs.

MU-RTS

The STA will send a MU-RTS and expect to receive a CTS from 1 or multiple STA. Interesting note about MU-RTS, if the STA’s CTS Timeout interval reaches 0 it will assume the MU-RTS Trigger frame has failed and will invoke a backoff procedure.

CTS Response to a MU-RTS

The client shall response if the following conditions are met:

• The medium is idle
• The RU allocation is specified in the User Info field
• There is a User Info field addressed to the client

Otherwise, the client show not send the CTS response.

The CTS will be carried in a non-HE PPDU so everyone can understand it. The data rate used should be 6Mbps.

It should be transmitted on the 20MHz wide channel specified in the RU Allocation subfield of the User Info field of the MU-RTS Trigger frame.

It’s important to know in MU-RTS, an AP can receive simultaneous CTS responses from clients.

EDCA Operation Using MU EDCA Parameters

A MU-EDCA Parameter Set Element might be included in the beacon frames, probe response and re(association) frames.

It can be a copy of the EDCA Parameters and can also be updated.

This is mainly used for QoS purposes. There is a QoS Info field within the (MU-)EDCA Parameter Set Element.

A client receiving a basic trigger frame containing addressed for itself will update various contention window values for the respective access categories.

The client station shall use the parameters set in the mostly recently received MU-EDCA. Including CWmin, CWmax, AIFSN and MUEDCATimer.

Closing Note (From Cisco 802.11ax White Paper)

“Because of this preamble-level compatibility, there is no inherent need for 802.11ax devices to precede their 802.11ax transmissions by CTS-to-self or RTS/CTS, although devices may still choose to implement and send them to protect longer PPDUs. However, 802.11ax adds the capability of multiuser RTS/CTS which allows the access point to reserve the channel (set the NAV) for multiple STAs simultaneously with a single MU-RTS PPDU that is then confirmed with simultaneous CTS PPDUs from multiple STAs. This scenario overcomes the inherent inefficiency of single-user RTS/CTS still prevalent in 802.11ac networks while adding protection to 802.11ax transmissions.”

Sections in the 802.11ax Draft Talking about HE Channel Access

• 27.2 – HE channel access (p.253)
• 10.3.1 DCF General

This Week in Wireless

• Wi-Fi Trek 2019
  • Don’t forget to use discount code: RD10 for the Wi-Fi Trek conference
  • https://rowelldionicio.com/all-good-things-come-to-wi-fi-trek/
• Cisco upcoming event
  • Cisco has announced an upcoming event on April 29th, 2019 called “Wired for Wireless: Reinventing Access”
  • Tune in at this address: https://engage2demand.cisco.com/LP=15068?ccid=cc001075&oid=otren016003&dtid=esolin000261&CAMPAIGN=NB-06+Network+Buyer+Program&Country_Site=us&POSITION=Social%2BMedia&REFERRING_SITE=LinkedIn&CREATIVE=Cisco+Enterprise+Networks
• Nyansa New Product
  • Nyansa is announcing a new product, tomorrow, April 16th
  • https://nyansa.zoom.us/webinar/register/WN_6JA4U7WBTJyRDEGhhVBZwA
• Ekahau Connect Now Available
  • Ekahau has released a suite of solutions called Ekahau Connect. Reach out to Rowell or François, your Ekahau Partners, for a demo or more information.
  • https://www.packet6.com/ekahau-connect-wi-fi-design-tools/
  • https://semfionetworks.com/products.html
• Meraki hits 2M active networks
  • https://meraki.cisco.com/blog/2017/05/a-major-milestone-2/
• Intel launches Wi-Fi 6 AX200 Adapter
  • https://amp.tomshardware.com/news/intel-wifi-6-ax200-adapter-specs-80211ax,38979.html
• CommScope completes the deal to buy ARRIS
  • https://www.commscope.com/NewsCenter/PressReleases/CommScope-Set-to-Shape-Communications-Connectivity-and-Networks-of-the-Future-with-Completion-of-ARRIS-Acquisition/?utm_medium=social&utm_source=twitter&utm_campaign=global-oc-arris-ruckus-acquisitions-press-release&hootPostID=5572d07876f526e659b4870162b48783
• Amazon buys Eero and we now know the price: 97M
  • https://www.theverge.com/2019/4/5/18297619/amazon-eero-price-fire-sale-mesh-wi-fi-buyout
• Aruba announces its 802.11ax APs
  • https://www.arubanetworks.com/products/networking/802-11ax/
  • https://www.arubanetworks.com/products/networking/access-points/
  • AP 510: https://www.arubanetworks.com/products/networking/access-points/510-series/
  • AP 530: https://www.arubanetworks.com/products/networking/access-points/530-series/
  • AP 550: https://www.arubanetworks.com/products/networking/access-points/550-series/
• Mobility Field Day x at ATM19
  • https://techfieldday.com/appearance/mobility-field-day-exclusive-roundtable-at-aruba-atmosphere-2019/
• Thank you guys for the nice reviews 🙂
  • https://twitter.com/cleartosend/status/1113473740875161602
  • https://twitter.com/cleartosend/status/1113867084461760512
  • https://twitter.com/cleartosend/status/1114184422927024128