802.11ac
Following is the list of the main characteristics of 802.11ac. Most of these main characteristics would lead to some addition / modification of PLDC and MAC frame structure. These detailed changes will be summarized in each corresponding sections. If you are not familiar with WLAN frame structure and basic operations I would recommend you to go through WLAN Frame structure and WLAN protocol page first.
- Motivation and Strategy
- Overall Specification/Requirements
- VHT
- Detecting 802.11ac AP
- Detecting 802.11ac Station (Device)
- Dynamic Bandwidth Allocation
- Additional Frame Types
- Beamforming Report Poll Frame
- VHT NDP Announcement
- VHT Compressed Beamforming Frame
- VHT preamble format for sounding PPDUs
- Channel measurement (sounding) procedures
- MU-MIMO BeamForming
- Compatibility
Motivation and Strategy
As in almost every evolution of every communication technology (except IoT), the major motivation of 802.11ac is to achieve much higher throughput than the previous highest throughput technology (802.11n in this case). I am pretty sure that you will see another technology targeted for even higher throughput than 802.11ac (We are already hearing of 802.11ad).
Then what is the technical strategy to achieve this high throughput ? Overall strategy is also same as other technology (If you have seen the evolution process of celluar technology (e.g, WCDMA -> HSPA -> DC HSPA or LTE -> LTE MIMO -> Carrier Aggregation etc), you will easily understand the strategy. Some of the technologies for this evolution can be listed as follows
- More Antenna
- More Data Stream
- Wider Channel (Wider RF Bandwidth)
- Higher Modulation Depth
- Larger MAC (or higher) Layer Frame
With the list in mind, if you try to correlate each of these technologies to each items of specification of 802.11ac, it will be much easier to get the big picture or motivation of those specification.
Just to give you more practical insight on this motivation, I would compare 802.11n (the most advanced technology before 802.11ac) and 802.11ac with the respect t the features/technologies listed above. (NOTE : I got most of these information from Ref [13]. I would recommend you to read through this document at least once if you have time)
|
Features/Technologies |
802.11n |
802.11ac |
Comments |
| Max Number of Data Stream |
4 |
8 |
802.11ac can achieve max 100% gain from this |
| Max Modulation Depth |
64 QAM |
256 QAM |
802.11ac can achieve around 33% gain from this |
| Max Bandwidth |
40 Mhz |
80 or 160 Mhz |
802.11ac can achieve 117 or 333% gain from this |
| MU MIMO |
Not Supported |
Supported |
In 802.11ac, multiple UEs can communicate with Access Point at the same time. |
| PHY Guardband Length |
Longer |
Shorter |
802.11ac Physical frame length generally shorter than 11n. This would give user the experience of quicker response time. |
|
|
|
Overall Specification / Requirement
The first key word (fundamental characteristics) of 802.11 ac is
No new technology can be invented overnight. We all understand this. However, we don't want to wait forever until everything is ready all at once. A common practice in this case is to split those requirement/wishlist into multiple chunks and attack them chunk by chunk. In some technology, they call these chunk as 'Stage' (like Stage 1, Stage 2 etc) and in some technology they call them as 'Phase' (e.g, Phase 1, Phase 2 etc). In 802.11ac, they call them as Wave (e.g, Wave 1, Wave 2 etc). 802.11ac has been evolved as two Waves (at least as of now, Aug 2016) as listed below.
< Wave 1 >
- 3 x 3 : 3 Data Streams Max
- Max 80 Mhz <== Twice the max bandwidth of 802.11 n
- 400ns GI (Guard Interval)
- 256 QAM
- 5/6 Coding Rate
- 1300 Mbps under all of the max condition
< Wave 2 >
- 4 x 4 : 4 Data Streams or 8 x 8 : 8 Data Streams Max
- Transmission BeamForming (based on Explicit CSI)
- AP support MU-MIMO
- Max 160 Mhz
- 800ns GI (Guard Interval)
- 256 QAM
- 5/6 Coding Rate
- 3466.7 Mbps with 4 x 4
- 6933.3 Mbps with 8 x 8
Detecting 802.11ac Access Point
If you have a 802.11ac WLAN Card (device), the first thing you have to do is to figure out the Access Point (AP) around the device support 802.11ac. (Actually you don't need to figure out this, your WLAN device will figure out :).
Then how your WLAN device will figure out whether the AP support 802.11ac or not ? It is by decoding the special information signal from the AP called Beacon. If your AP support 802.11ac, it will broadcast Beancon signal containing following information.
Following Beacon Signal is the one from a WLAN Test equipment, Anritsu MT8862. Anritsu kindly provided me a full sample log starting from Beacon through user data and it will be a great resource for my study. I will sharing more as I learn more from the log. You can see the test setup on how this log is captured.
![]()
It may look simple two lines of information, but it will contain a lot of details of the 802.11ac capability that the AP supports. Following is the full decoded information.
Tag: VHT Capabilities (IEEE Stc 802.11ac/D3.1)
Tag Number: VHT Capabilities (IEEE Stc 802.11ac/D3.1) (191)
Tag length: 12
VHT Capabilities Info: 0x03800022
.... .... .... .... .... .... .... ..10 = Maximum MPDU Length: 11 454 (0x00000002)
.... .... .... .... .... .... .... 00.. = Supported Channel Width Set: Neither 160MHz
nor 80+80 supported (0x00000000)
.... .... .... .... .... .... ...0 .... = Rx LDPC: Not supported
.... .... .... .... .... .... ..1. .... = Short GI for 80MHz: Supported
.... .... .... .... .... .... .0.. .... = Short GI for 160MHz and 80+80MHz: Not supported
.... .... .... .... .... .... 0... .... = Tx STBC: Not supported
.... .... .... .... .... .000 .... .... = Rx STBC: None (0x00000000)
.... .... .... .... .... 0... .... .... = SU Beam-former Capable: Not supported
.... .... .... .... ...0 .... .... .... = SU Beam-formee Capable: Not supported
.... .... .... .... 000. .... .... .... = Compressed Steering Number of Beamformer Antennas
Supported: 1 (0x00000000)
.... .... .... .000 .... .... .... .... = Number of Sounding Dimensions: 1 (0x00000000)
.... .... .... 0... .... .... .... .... = MU Beam-former Capable: Not supported
.... .... ...0 .... .... .... .... .... = MU Beam-formee Capable: Not supported
.... .... ..0. .... .... .... .... .... = VHT TXOP PS: Not supported
.... .... .0.. .... .... .... .... .... = +HTC-VHT Capable (VHT variant HT Control field):
Not supported
.... ..11 1... .... .... .... .... .... = Max A-MPDU Length: 1 048 575 (0x00000007)
.... 00.. .... .... .... .... .... .... = VHT Link Adaptation: No Feedback (0x00000000)
...0 .... .... .... .... .... .... .... = Rx Antenna Pattern Consistency: Not supported
..0. .... .... .... .... .... .... .... = Tx Antenna Pattern Consistency: Not supported
00.. .... .... .... .... .... .... .... = Reserved: False
VHT Supported MCS Set
Rx MCS Map: 0xfffe
.... .... .... ..10 = Rx 1 SS: MCS 0-9 (0x0002)
.... .... .... 11.. = Rx 2 SS: Not Supported (0x0003)
.... .... ..11 .... = Rx 3 SS: Not Supported (0x0003)
.... .... 11.. .... = Rx 4 SS: Not Supported (0x0003)
.... ..11 .... .... = Rx 5 SS: Not Supported (0x0003)
.... 11.. .... .... = Rx 6 SS: Not Supported (0x0003)
..11 .... .... .... = Rx 7 SS: Not Supported (0x0003)
11.. .... .... .... = Rx 8 SS: Not Supported (0x0003)
...0 0000 0000 0000 = Rx Highest Long GI Data Rate (in Mb/s, 0 = subfield not in use):
0x0000
Tx MCS Map: 0xfffe
.... .... .... ..10 = Tx 1 SS: MCS 0-9 (0x0002)
.... .... .... 11.. = Tx 2 SS: Not Supported (0x0003)
.... .... ..11 .... = Tx 3 SS: Not Supported (0x0003)
.... .... 11.. .... = Tx 4 SS: Not Supported (0x0003)
.... ..11 .... .... = Tx 5 SS: Not Supported (0x0003)
.... 11.. .... .... = Tx 6 SS: Not Supported (0x0003)
..11 .... .... .... = Tx 7 SS: Not Supported (0x0003)
11.. .... .... .... = Tx 8 SS: Not Supported (0x0003)
...0 0000 0000 0000 = Tx Highest Long GI Data Rate (in Mb/s, 0 = subfield not in use):
0x0000
Tag: VHT Operation (IEEE Stc 802.11ac/D3.1)
Tag Number: VHT Operation (IEEE Stc 802.11ac/D3.1) (192)
Tag length: 5
VHT Operation Info
Channel Width: 80 MHz (0x01)
Channel Center Segment 0: 42
Channel Center Segment 1: 0
Basic MCS Map: 0xfffc
.... .... .... ..00 = Basic 1 SS: MCS 0-7 (0x0000)
.... .... .... 11.. = Basic 2 SS: Not Supported (0x0003)
.... .... ..11 .... = Basic 3 SS: Not Supported (0x0003)
.... .... 11.. .... = Basic 4 SS: Not Supported (0x0003)
.... ..11 .... .... = Basic 5 SS: Not Supported (0x0003)
.... 11.. .... .... = Basic 6 SS: Not Supported (0x0003)
..11 .... .... .... = Basic 7 SS: Not Supported (0x0003)
11.. .... .... .... = Basic 8 SS: Not Supported (0x0003)
Detecting 802.11ac Station (Device)
Communication is the exchange of information between two or more parties. The previous section showed how the device can figure out the 802.11ac capability of AP. Then you would ask how the AP can figure out 802.11ac capability of the device. The AP can figure out the device capability from [Probe Request] message from the device as shown below.
IEEE 802.11 Probe Request, Flags: ........C
Type/Subtype: Probe Request (0x04)
Frame Control Field: 0x4000
.... ..00 = Version: 0
.... 00.. = Type: Management frame (0)
0100 .... = Subtype: 4
Flags: 0x00
.... ..00 = DS status: Not leaving DS or network is operating in AD-HOC mode
(To DS: 0 From DS: 0) (0x00)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
.000 0000 0011 1100 = Duration: 60 microseconds
Receiver address: Anritsu_07:91:0e (00:00:91:07:91:0e)
Destination address: Anritsu_07:91:0e (00:00:91:07:91:0e)
Transmitter address: e0:cb:ee:f9:4a:de (e0:cb:ee:f9:4a:de)
Source address: e0:cb:ee:f9:4a:de (e0:cb:ee:f9:4a:de)
BSS Id: Anritsu_07:91:0e (00:00:91:07:91:0e)
Fragment number: 0
Sequence number: 2048
Frame check sequence: 0xfe06c6aa [correct]
[Good: True]
[Bad: False]
IEEE 802.11 wireless LAN management frame
Tagged parameters (83 bytes)
Tag: SSID parameter set: MT8862A6000000008
Tag Number: SSID parameter set (0)
Tag length: 17
SSID: MT8862A6000000008
Tag: Supported Rates 6, 9, 12, 18, 24, 36, 48, 54, [Mbit/sec]
Tag Number: Supported Rates (1)
Tag length: 8
Supported Rates: 6 (0x0c)
Supported Rates: 9 (0x12)
Supported Rates: 12 (0x18)
Supported Rates: 18 (0x24)
Supported Rates: 24 (0x30)
Supported Rates: 36 (0x48)
Supported Rates: 48 (0x60)
Supported Rates: 54 (0x6c)
Tag: DS Parameter set: Current Channel: 36
Tag Number: DS Parameter set (3)
Tag length: 1
Current Channel: 36
Tag: HT Capabilities (802.11n D1.10)
Tag Number: HT Capabilities (802.11n D1.10) (45)
Tag length: 26
HT Capabilities Info: 0x01ef
.... .... .... ...1 = HT LDPC coding capability:
Transmitter supports receiving LDPC coded packets
.... .... .... ..1. = HT Support channel width: Transmitter supports 20MHz and
40MHz operation
.... .... .... 11.. = HT SM Power Save: SM Power Save disabled (0x0003)
.... .... ...0 .... = HT Green Field: Transmitter is not able to receive PPDUs
with Green Field (GF) preamble
.... .... ..1. .... = HT Short GI for 20MHz: Supported
.... .... .1.. .... = HT Short GI for 40MHz: Supported
.... .... 1... .... = HT Tx STBC: Supported
.... ..01 .... .... = HT Rx STBC: Rx support of one spatial stream (0x0001)
.... .0.. .... .... = HT Delayed Block ACK: Transmitter does not support
HT-Delayed BlockAck
.... 0... .... .... = HT Max A-MSDU length: 3839 bytes
...0 .... .... .... = HT DSSS/CCK mode in 40MHz: Won't/Can't use of DSSS/CCK
in 40 MHz
..0. .... .... .... = HT PSMP Support: Won't/Can't support PSMP operation
.0.. .... .... .... = HT Forty MHz Intolerant: Use of 40 MHz transmissions
unrestricted/allowed
0... .... .... .... = HT L-SIG TXOP Protection support: Not supported
A-MPDU Parameters: 0x03
.... ..11 = Maximum Rx A-MPDU Length: 0x03 (65535[Bytes])
...0 00.. = MPDU Density: no restriction (0x00)
000. .... = Reserved: 0x00
Rx Supported Modulation and Coding Scheme Set: MCS Set
Rx Modulation and Coding Scheme (One bit per modulation): 2 spatial streams
.... .... .... .... .... .... 1111 1111 = Rx Bitmask Bits 0-7: 0x000000ff
.... .... .... .... 1111 1111 .... .... = Rx Bitmask Bits 8-15: 0x000000ff
.... .... 0000 0000 .... .... .... .... = Rx Bitmask Bits 16-23: 0x00000000
0000 0000 .... .... .... .... .... .... = Rx Bitmask Bits 24-31: 0x00000000
.... .... .... .... .... .... .... ...0 = Rx Bitmask Bit 32: 0x00000000
.... .... .... .... .... .... .000 000. = Rx Bitmask Bits 33-38: 0x00000000
.... .... ...0 0000 0000 0000 0... .... = Rx Bitmask Bits 39-52: 0x00000000
...0 0000 0000 0000 0000 0000 000. .... = Rx Bitmask Bits 53-76: 0x00000000
.... ..00 0000 0000 = Highest Supported Data Rate: 0x0000
.... .... .... ...0 = Tx Supported MCS Set: Not Defined
.... .... .... ..0. = Tx and Rx MCS Set: Equal
.... .... .... 00.. = Maximum Number of Tx Spatial Streams Supported: 0x0000,
TX MCS Set Not Defined
.... .... ...0 .... = Unequal Modulation: Not supported
HT Extended Capabilities: 0x0000
.... .... .... ...0 = Transmitter supports PCO: Not supported
.... .... .... .00. = Time needed to transition between 20MHz and 40MHz:
No Transition (0x0000)
.... ..00 .... .... = MCS Feedback capability: STA does not provide MCS feedback
(0x0000)
.... .0.. .... .... = High Throughput: Not supported
.... 0... .... .... = Reverse Direction Responder: Not supported
Transmit Beam Forming (TxBF) Capabilities: 0x0000
.... .... .... .... .... .... .... ...0 = Transmit Beamforming: Not supported
.... .... .... .... .... .... .... ..0. = Receive Staggered Sounding: Not supported
.... .... .... .... .... .... .... .0.. = Transmit Staggered Sounding:
Not supported
.... .... .... .... .... .... .... 0... = Receive Null Data packet (NDP):
Not supported
.... .... .... .... .... .... ...0 .... = Transmit Null Data packet (NDP):
Not supported
.... .... .... .... .... .... ..0. .... = Implicit TxBF capable: Not supported
.... .... .... .... .... .... 00.. .... = Calibration: incapable (0x00000000)
.... .... .... .... .... ...0 .... .... = STA can apply TxBF using CSI explicit
feedback: Not supported
.... .... .... .... .... ..0. .... .... = STA can apply TxBF using uncompressed
beamforming feedback matrix: Not supported
.... .... .... .... .... .0.. .... .... = STA can apply TxBF using compressed
beamforming feedback matrix: Not supported
.... .... .... .... ...0 0... .... .... = Receiver can return explicit CSI
feedback: not supported (0x00000000)
.... .... .... .... .00. .... .... .... = Receiver can return explicit uncompressed
Beamforming Feedback Matrix: not supported (0x00000000)
.... .... .... ...0 0... .... .... .... = STA can compress and use compressed
Beamforming Feedback Matrix: not supported (0x00000000)
.... .... .... .00. .... .... .... .... = Minimal grouping used for explicit
feedback reports: No grouping supported (0x00000000)
.... .... ...0 0... .... .... .... .... = Max antennae STA can support when CSI
feedback required: 1 TX antenna sounding (0x00000000)
.... .... .00. .... .... .... .... .... = Max antennae STA can support
when uncompressed Beamforming feedback required:
1 TX antenna sounding (0x00000000)
.... ...0 0... .... .... .... .... .... = Max antennae STA can support
when compressed Beamforming feedback required:
1 TX antenna sounding (0x00000000)
.... .00. .... .... .... .... .... .... = Maximum number of rows of CSI explicit
feedback: 1 row of CSI (0x00000000)
...0 0... .... .... .... .... .... .... = Maximum number of space time streams for
which channel dimensions can be simultaneously
estimated: 1 space time stream (0x00000000)
000. .... .... .... .... .... .... .... = Reserved: 0x00000000
Antenna Selection (ASEL) Capabilities: 0x00
.... ...0 = Antenna Selection Capable: Not supported
.... ..0. = Explicit CSI Feedback Based Tx ASEL: Not supported
.... .0.. = Antenna Indices Feedback Based Tx ASEL: Not supported
.... 0... = Explicit CSI Feedback: Not supported
...0 .... = Antenna Indices Feedback: Not supported
..0. .... = Rx ASEL: Not supported
.0.. .... = Tx Sounding PPDUs: Not supported
0... .... = Reserved: 0x00
Tag: Vendor Specific: Microsof: Unknown 8
Tag Number: Vendor Specific (221)
Tag length: 7
OUI: 00-50-f2 (Microsof)
Vendor Specific OUI Type: 8
Type: Unknown (0x08)
Tag: VHT Capabilities (IEEE Stc 802.11ac/D3.1)
Tag Number: VHT Capabilities (IEEE Stc 802.11ac/D3.1) (191)
Tag length: 12
VHT Capabilities Info: 0x338051b2
.... .... .... .... .... .... .... ..10 = Maximum MPDU Length: 11 454 (0x00000002)
.... .... .... .... .... .... .... 00.. = Supported Channel Width Set:
Neither 160MHz nor 80+80 supported (0x00000000)
.... .... .... .... .... .... ...1 .... = Rx LDPC: Supported
.... .... .... .... .... .... ..1. .... = Short GI for 80MHz: Supported
.... .... .... .... .... .... .0.. .... = Short GI for 160MHz and 80+80MHz:
Not supported
.... .... .... .... .... .... 1... .... = Tx STBC: Supported
.... .... .... .... .... .001 .... .... = Rx STBC: 1 Spatial Stream Supported
(0x00000001)
.... .... .... .... .... 0... .... .... = SU Beam-former Capable: Not supported
.... .... .... .... ...1 .... .... .... = SU Beam-formee Capable: Supported
.... .... .... .... 010. .... .... .... = Compressed Steering Number of Beamformer
Antennas Supported: 3 (0x00000002)
.... .... .... .000 .... .... .... .... = Number of Sounding Dimensions: 1
(0x00000000)
.... .... .... 0... .... .... .... .... = MU Beam-former Capable: Not supported
.... .... ...0 .... .... .... .... .... = MU Beam-formee Capable: Not supported
.... .... ..0. .... .... .... .... .... = VHT TXOP PS: Not supported
.... .... .0.. .... .... .... .... .... = +HTC-VHT Capable (VHT variant HT Control
field): Not supported
.... ..11 1... .... .... .... .... .... = Max A-MPDU Length:1 048 575 (0x00000007)
.... 00.. .... .... .... .... .... .... = VHT Link Adaptation: No Feedback
(0x00000000)
...1 .... .... .... .... .... .... .... = Rx Antenna Pattern Consistency:Supported
..1. .... .... .... .... .... .... .... = Tx Antenna Pattern Consistency:Supported
00.. .... .... .... .... .... .... .... = Reserved: False
VHT Supported MCS Set
Rx MCS Map: 0xfffa
.... .... .... ..10 = Rx 1 SS: MCS 0-9 (0x0002)
.... .... .... 10.. = Rx 2 SS: MCS 0-9 (0x0002)
.... .... ..11 .... = Rx 3 SS: Not Supported (0x0003)
.... .... 11.. .... = Rx 4 SS: Not Supported (0x0003)
.... ..11 .... .... = Rx 5 SS: Not Supported (0x0003)
.... 11.. .... .... = Rx 6 SS: Not Supported (0x0003)
..11 .... .... .... = Rx 7 SS: Not Supported (0x0003)
11.. .... .... .... = Rx 8 SS: Not Supported (0x0003)
...0 0011 0000 1100 = Rx Highest Long GI Data Rate
(in Mb/s, 0 = subfield not in use): 0x030c
Tx MCS Map: 0xfffa
.... .... .... ..10 = Tx 1 SS: MCS 0-9 (0x0002)
.... .... .... 10.. = Tx 2 SS: MCS 0-9 (0x0002)
.... .... ..11 .... = Tx 3 SS: Not Supported (0x0003)
.... .... 11.. .... = Tx 4 SS: Not Supported (0x0003)
.... ..11 .... .... = Tx 5 SS: Not Supported (0x0003)
.... 11.. .... .... = Tx 6 SS: Not Supported (0x0003)
..11 .... .... .... = Tx 7 SS: Not Supported (0x0003)
11.. .... .... .... = Tx 8 SS: Not Supported (0x0003)
...0 0011 0000 1100 = Tx Highest Long GI Data Rate
(in Mb/s, 0 = subfield not in use): 0x030c
VHT (Very High Throughput)
One of the most important keywords in 802.11ac would VHT. VHT stands for Very High Throughput. You would not need any additional explanation on what this means. The meaning is obvious and self-explanatory.
The question is how to achieve VHT and what kind of new frames and protocols are introduced to implement this.
The VHT is a Physical layer frame concept which is defined as shown below.

In wireshark log, you may see this framing information from Radiotap Header as shown below.

Dynamic Bandwidth Allocation
802.11ac support various types of bandwidth combination like 20 Mhz, 80 Mhz, 160 Mhz. Then the question would 'how do they allocate the bandwidth ?'. Statically or Dynamically ?
Static allocation means that Transmitter (Initiator) and Reciever(Responder) negotiate and determines the bandwidth during early stage of connection setup and keep it same until the end of communication (a session).
Dynamic allocation means that Transmitter and Reciever SOMEHOW negotiate/determine the bandwidth in very short interval even during a single session.
802.11ac picked up the dynamic allocation approach. It allows the change of the bandwidth at every transmission.
Then the question is 'HOW ?'. What kind of negotiation they use to determine/agree upon the bandwidth between Transmitter and Reciever ?
Basic Idea is simple. As you see in Data Transmission in Detail section, basic channel acquisition process for all 802.11 is based on RTS/CTS mechanism. 802.11ac use the same mechanism to determine the avaiable bandwidth dynamically. The idea is to split the whole possible 802.11ac band into multiple blocks of basic segments (e.g, 20 Mhz, 40 Mhz, 80 Mhz etc) and perform the multiple RTS/CTS simulateneously across the multiple frequency block. (It is very similary for Carrier Aggregation in LTE). First, the initiator sends multiple RTS accross the multiple frequency block and wait for CTS. If the initiator recieves CTS accross the all the blocks, it can use all the frequency blocks (very wide aggregated bandwidth). If the initiator recieves only a few CTS for the all transmitted RTS, it uses the smaller bandwidth for which CTS is recieved. (Refer to Ref [9] for the details).
Let me give you a couple of examples with illustration on how Dynamic Bandwidth goes. Here goes only two cases but there can be much more variations on this.
This is the case where there is no interference between Node A(initiator) and Node B(recipient) and the full bandwith is avaiable for both nodes. Of course, these nodes does not know anything about the bandwidth availability before it completes step 3.

- Step 0 : Right before Step 1, it is assumed that Node A split the whole 80 Mhz section into 4 contiguous 20 Mhz block and performed carrier sensing for each of these 20 Mhz block. And it is assumed that all of these 20 Mhz block turned out to be available.
- Step 1 : Node A wait for a certain time period called DIFS(DCF Inter Frame Space), assuming that the scheduling is done in DCF.
- Step 2 : Node A transmit RTS for each of 20 Mhz block to Node B using 802.11a frame and it is assumed that all of these RTS reached Node B successfully.
- Step 3 : (Assuming that Node B detected RTS for all of 20 Mhz blocks) Node B transmit CTS using 802.11a frame for every 20 Mhz subblocks.
- Step 4 : (Assuming that Node A detected CTS for all of 20 Mhz blocks) Node A assumes that all 80Mhz BW is clear/no-interference and transmit the data in 802.11ac mode utilizing the full 80 Mhz.
- Step 5 : (Assuming that Node B received and decoded the whole data) Node B sends Ack for every 20 Mhz blocks (40 Mhz in total).
This is the case where there is some interference in some spectrum blocks within the 80 Mhz block on Node B(recipient). Of course, these nodes does not know anything about the bandwidth availability before it completes step 3.

- Step 0 : Right before Step 1, it is assumed that Node A split the whole 80 Mhz section into 4 contiguous 20 Mhz block and performed carrier sensing for each of these 20 Mhz block. And it is assumed that all of these 20 Mhz block turned out to be available.
- Step 1 : Node A wait for a certain time period called DIFS(DCF Inter Frame Space), assuming that the scheduling is done in DCF.
- Step 2 : Node A transmit RTS for each of 20 Mhz block to Node B using 802.11a frame.
- Step 3 : (In various reason, e.g, Node B failed to receive RTS due to interference or Medium is busy based on carrier sensing ) Node B transmit CTS using 802.11a frame for only two consecutive 20 Mhz blocks.
- Step 4 : (Assuming that Node A detected CTS for the two 20 Mhz blocks) Node A assumes that only 40Mhz BW is clear/no-interference and transmit the data in 802.11ac mode utilizing the 40 Mhz.
- Step 5 : (Assuming that Node B received and decoded the whole data) Node B sends Ack for the two 20 Mhz blocks (40 Mhz in total).
Additional MAC Frame Types
In 802.11ac, Following new Frame Types are added to the existing type. Most of New Frametype is for impelementing Channel Measurement and Report to perform MU-MIMO Beamforming.
|
Type |
Type Description |
Sub Type |
Sub Type Description |
|
01 |
Control |
0000-0011 |
Reserved (This is changed from existing field) |
|
01 |
Control |
0100 |
|
|
01 |
Control |
0101 |
Beamforming Report Poll Frame

VHT NDP Announcement
This frame is used for BeamFormer (AP) to initiate Channel Measurement Process. (Refer to 802.11ac 8.3.1.20 VHT NDP Announcement frame format for the details)

< Field Description of Station Info >
|
Field |
Description |
|
AID12 (B0-B11) |
The 12 least significant bits of the AID of a STA expected to process the following VHT NDP and prepare the sounding feedback. Set to be 0 if the STA is an AP, mesh STA, or STA that is a member of an IBSS |
|
Feedback Type (B12) |
The type of feedback requested. Set to 0 for SU. Set to 1 for MU. |
|
Nc Index (B13-B15) |
This applies only when Feedback type is 1(MU) It indicates the number of columns, Nc, in the Compressed Beamforming Feedback Matrix Set to 0 to request Nc = 1 Set to 1 to request Nc = 2
Set to 7 to request Nc = 8 |
VHT Compressed Beamforming Frame
This frame is used for BeamFormee (user) to report channel measurement result (Refer to 802.11ac 8.5.23.2 VHT Compressed Beamforming frame format for the details)

VHT preamble format for sounding PPDUs
Refer to 802.11ac Table 22-4Fields of the VHT PPDU for each field label.

Channel measurement (sounding) procedures
To perform proper beamforming for specific devices, it is crucial to figure out accurate channel condition between BeamFormer and BeanFormee. To figure out the channel condition, BeamFormer and BeamFormee performs a specific sequence of calibration process and this process is called Channel Measurement or Sounding process. It goes as follows.
Refer to 802.11ac 9.31.5.2 Rules for VHT sounding protocol sequences, Figure 9-41a and Figure 9-41a for the details.
- Step 1 : BeamFormer (usually AP) transmit NDP(Null Data Packet) Announcement frame
- Step 2 : BeamFormee (usually WLAN user device) responds to NDP announcement (Other device that are not sepecified in NDP defer channel access until the channel measurement process is complete)
- Step 3 : Beamformer transmit Null Data Packet carrying Training Sequence (NDP Frame, VHT preamble format)
- Step 4 : BeamFormee analyze the training sequence and send feedback Matrix (Refer to 802.11ac 8.4.1.48 VHT Compressed Beamforming Report field for the details of the feedback matrix)
- Step 5 : BeamFormer calculate the steering matrix based on the feedback matrix
- Step 1 : BeamFormer (usually AP) transmit NDP(Null Data Packet) Announcement frame
- Step 2 : BeamFormee (usually WLAN user device) responds to NDP announcement (Other device that are not sepecified in NDP defer channel access until the channel measurement process is complete)
- Step 3 : Beamformer transmit Null Data Packet carrying Training Sequence (NDP Frame, VHT preamble format)
- Step 4 : BeamFormees analyze the training sequence
- Step 5 : BeamFormee1 send send feedback Matrix (Refer to 802.11ac 8.4.1.48 VHT Compressed Beamforming Report field for the details of the feedback matrix)
- Step 6 : BeamFormer send BeamForming Report Poll for next BeamFormee
- Step 7 : The next BeamFormee send send feedback Matrix
- Step 8 : Repeat Step 6,7 until BeamFormer get all the information for all BeamFormees.
- Step 9 : BeamFormer calculate the steering matrix based on the feedback matrix
MU-MIMO BeamForming
MU-MIMO stands for Multi User MIMO and this is adopted only in 802.11ac (not in 802.11n and lower). When we say MIMO(Multi Input Multi Output), it normally mean SU-MIMO(Single User MIMO), which is a MIMO targeted to only one device(user). On the contrary, MU-MIMO is the MIMO targeted to multiple user simulateneously. It mean that in MU-MIMO the transmitter (Access Point) can transmite the multiple stream of data targeted to multiple user.
It sounds fancy, right ? However, the implementation of this technology would not be as easy as it sound and real performance would not be as good as expected. Probably it would need to go through a long way of evolution. Let's think of some of the challenges and possible issues related to MU-MIMO
- In order to the best optimized beam to each of users, it needs very accurately estimated radio channel information for each users.
- Usually to have the proper channel estimation for each users, the AP would require some channel quality information from each users(devices), this process would some overhead in terms of signaling or data communication.
- Since the multiple beams for multiple users are being transmitted simultaneously, there is always chances for one beam to interfere other beams. So it would be difficult to apply the very high order modulation schedule (e.g, 64 QAM or 256 QAM).
- To make a better pointed beam for a device, it require many antenna for the beam forming. Considering the fact that we would have 8 antenna maximum, I am not so confident on how well formed beam we can generate for multiple users (especially the number of user increases).
Putting aside the practical feasibility of this MU-MIMO, the specification is done. In most case of technology (even though it is not all the case), once the specification is issued the technology continues to evolve and get better and better.
802.11ac MU-MIMO Beamforming is expressed in a mathematical expression as follows (this is based on 802.11ac 22.3.11 SU-MIMO and DL-MU-MIMO Beamforming)

Compatibility
Whenever a new version of any technology comes out, one of the most concerning thing is compatibility. Can this new stuff work with all of those old stuffs out there already ? You would have the same questions about 802.11ac. Is 802.11ac compatitle with the existing (previous) techology (e.g, 802.11a and 802.11n) ? The answer is Yes. 802.11ac is designed from beginning to be compatible with 802.11a / n both for Access point and devices.
Reference
[3] Understanding IEEE 802.11ac VHT Wireless
[4] 802.11ac Testing with the Vector Signal Transceiver
[5] Gigabit Wi-Fi 802.11ac In Depth (YouTube)
[6] 802.11ac Gigabit WiFi: Fact vs. Fiction (YouTube)
[7] Demonstrating the Performance of the Aruba Networks 802.11ac (YouTube)
[8] Aruba Controller-based and Controllerless Wi-Fi (YouTube)
[9] 802.11ac : A Survival Guide - Chapter 3. The MAC
[10] 802.11ac Wireless Packet Captures
[11] Deploying, Testing, and Tuning 802.11ac
[12] How to validate the WI-FI Information within Wireshark Part I: Determining the WLAN capabilities
[13] 802.11ac: The Fifth Generation of Wi-Fi Technical White Paper