wi-fi 6

CTS 169: Just The Tech

May 6, 2019 Rowell Podcast 00:39:59 0 Comments

Rowell and François were invited to Cisco Headquarters, along with many others, as part of the #JustTheTech event which was planned in coordination with the Wi-Fi 6 announcement that happened on April 29, 2019.

It was a jam packed day of discussions with key people from Cisco.

The folks in attendance for #JustTheTech were:

We kicked off the event with a tour of the Customer Experience Center. Taking a look at the possibilities using Cisco solutions. It’s an impressive facility on the first floor of one of many Cisco buildings. There’s an entry way with a large Cisco logo on the wall. On the other side of the wall is the beginning of the Customer Experience Center.

  • Big Cisco logo
  • Hop aboard the Cisco bus
  • Virtual Concierge
  • Industrial switches
  • The Customer Experience Wall
  • Cisco’s first product, the AGS.
  • BGP on a napkin

During our tour we ran into Todd Nightingale who is an SVP, General Manager of Meraki. It was a delightful surprise but he was able to talk to us for a bit and even tour with us.

So the main purpose of #JustTheTech was to take part in the coordinated announcement of Wi-Fi 6 products from both Cisco and Meraki. But instead of marketing material, we were able to speak directly to engineers.

This means taking a look at the new Wi-Fi 6 access points up close

  • Catalyst 9115, 9117, 9120
  • Meraki MX55, MX45

The actual event started off with Sacha Gupta, Senior Vice President, Product Management – Cisco Enterprise Networking. He talked about Reinventing Access, Unplugged and Uninterrupted.

Reinventing Access, Unplugged and Uninterrupted by Sacha Gupta

Next, Jérôme Henry, Principle Engineer, Office of the CTAO, talked about OpenRoaming which is an interesting concept in today’s world where 5G and Wi-Fi 6 will converge. Cisco has developed partnerships with the biggest device manufacturers showing they really want to make these products work on our networks.

Understanding OpenRoaming and the Device Ecosystem Project by Jérôme Henry

Next, Fred Niehaus and Jeevan Patil begin their combined talk about Wi-Fi 6. This is where we really get interested as everyone was expecting new Wi-Fi 6 hardware.

What Wi-Fi 6 will bring to the market by Fred Niehaus & Jeevan Patil

Of course, Fred goes into the details of the new Catalyst access points. These are the equivalent of the AireOS 1800 and 2800 access points.

Introducing Cisco’s Catalyst Wi-Fi 6 Access Points by Fred Niehaus

Jeevan introduces Meraki’s new Wi-Fi 6 access points. They look radically different from the Cisco Catalyst access points. Something out of a Marvel movie.

Next-Generation Meraki Access Portfolio by Jeevan Patil

And as a bonus, we get to hear about the new Catalyst 9600 chassis switch. The thing is a beast.

Bedrock of the Cloud-scale Campus by Shawn Wargo

Speaking of the Catalyst 9600 Series, there was a Roundtable Discussion.

We also took part in a Wi-Fi 6 Roundtable Discussion with Fred Niehaus and Cristian Raducanu.

One of the highlights of the day was taking a shuttle over to another Cisco building where Wi-Fi 6 access points and devices are tested. This facility is essential as all of the tests for Wi-Fi 6 starts here. Inside the building is a caged off room – it literally has a chain-link fence which requires special badge privileges.

There are tables of laptops with Wi-Fi 6 adapters installed and also many Wi-Fi 6 mobile devices. Currently, being all Samsung as they were the first ones out with Wi-Fi 6. On the ceiling are the Catalyst 9115, 9117, or 9120 access points.

Various tools were used to test Wi-Fi 6 connectivity and roaming. We had a question of 1024 QAM come up and the test engineers stated it was possible to get 1024 QAM at some distance. No access point above your head required.

Closing Thoughts

We were fortunate to be invited to Cisco’s headquarters and take part in this awesome event. It does help that we are both Cisco Champions. With a small group of individuals, it was an intimate setting. The access we had to engineers within Cisco was great and led to great discussions about Wi-Fi 6 including an up-close look at the products.

Links & Resources

CTS 168: OpenRoaming

April 29, 2019 François Vergès Podcast 00:27:17 0 Comments

With Wi-Fi 6 and 5G now taking the stage, one has to think – what about the coexistence of the two technologies? Rowell and François met together at Cisco HQ to speak with Jérôme Henry about OpenRoaming and Cisco’s vision of seamless roaming.

François Vergès (left), Jerome Henry (center), Rowell Dionicio (right)

Rowell and François participated at an event called #JustTheTech at Cisco HQ in Milpitas, CA. At this event we were table to speak to technical experts just about the technology and how it works in regards to Wi-Fi 6, switching, testing, and more.

In this episode, François talks with Jérôme Henry, following his presentation on OpenRoaming. In the room is Rowell Dionicio, Sam Clements, and Dave Benham – all who participated at #JustTheTech.

OpenRoaming

What is OpenRoaming? According to Cisco:

Cisco, along with other vendors and enterprises, is working to provide a better bridge between mobile devices and Wi-Fi networks. With frictionless and secure guest onboarding, users can roam across Wi-Fi 6 and 5G networks, automatically maintaining connectivity with security and achieving the ultimate experience.

https://www.cisco.com/c/en/us/solutions/enterprise-networks/802-11ax-solution/openroaming.html

OpenRoaming also bridges the network operator with the provider. A way to seamlessly onboard users to Wi-Fi with existing credentials.

Learn more about OpenRoaming from Jerome Henry by listening to this episode today.

To see more about OpenRoaming check out Cisco’s website.

CTS 167: 802.11ax 1024-QAM & HE-MCSs

April 22, 2019 François Vergès Podcast 00:36:57 0 Comments

1024-QAM

Evolution of the modulation techniques we are using today with 802.11ax (256-QAM).

With 1024-QAM, we are now able to encode 10 bits per cycle on each subcarrier. The way we are able to do that is by increasing the number of different levels of amplitudes used to encode the data.

If you want to learn more about the different types of modulations used by Wi-Fi and how they work, there is a great video where Keith Parsons explains it on youtube: https://www.youtube.com/watch?v=W5DMfEuY2Vg&t=8s

Due to the addition of a new modulation technique (QAM-1024), 2 new MCS indexes are now available with 802.11ax:

  • Index 10: when the 1024-QAM modulation is used with a coding of 3/4
  • Index 11: when the 1024-QAM modulation is used with a coding of ⅚

FEC (Forward Error Correction). Send more than the data bits. If you lose some of the sequence, the remaining bits will help you to understand what you were supposed to be sent.

What is the challenge with more complex modulation techniques?

How well will 1024-QAM in real life?

Will we be able to take advantage to it?

Interesting talk on twitter around the subject (Troy Martin, Andrew, Hendrik Lüth & Jim Vajda). We tend to think that a smaller communication bandwidth will give us a better SNR. But it is not necessarily the case here since the receiver in 802.11ax will still be listening to the whole 20MHz wide channel even if its RU is smaller. Link here: https://twitter.com/VergesFrancois/status/1113779145731977216

HE-MCSs

Download the updated MCS Table

With 802.11ax, we are getting a whole new set of data rates (or MCSs). If we want to understand why, we need to understand how these data rates are calculated.

The amount of data we can transfer through a Wi-Fi link will depend on:

  • The channel width (or the number of subcarriers)
  • The modulation and coding use
  • The amount of spatial streams used
  • The guard interval used
  • The duration of the symbol

And we can actually take all these different variables and calculate the different data rates using the following formula:

802.11n/ac Data Rate Formula

You can take a look at the blog post and see which values can each of these variables can have for 802.11n and 802.11ac:

HT & VHT Parameters

Now, the reason why we have a new set of data rates for 802.11ax is because some of the key variables are changing:

  • A new symbol duration is used: 12.8µs
  • Different Guard Intervals are used: 0.8µs, 1.6µs and 3.2µs
  • The size and number of data subcarriers is not the same (especially with the different RU sizes introduced by ODFMA.

Also, with the introduction of OFDMA and the use of Resource Units, we might be using smaller numbers of subcarriers which impact the data rates.

This is why the draft identify the OFDMA and non-OFDMA MCS differently.

The draft even use specific variables related to each resource unit. And we can therefore define this new formula:

802.11ax ODFMA Data rate Formula

And here are the different values each of these variables can have for 802.11ax communications. The first table details the parameters used when OFDMA is not used. The second table details the parameters when OFDMA and resource units are used.

802.11ax OFDM Parameters
802.11ax OFDMA Parameters

Sections Talking about MCS in The Standards & Draft

  • 28.3.7 HE Modulation and coding schemes (HE-MCSs) (p.442)
  • 28.5 Parameters for HE-MCSs (p. 589)
  • 19.5 Parameters for HT MCSs
  • 21.5 Parameters for VHT-MCSs

Resources


CTS 166: 802.11ax HE Channel Access

April 15, 2019 François Vergès Podcast 00:50:58 0 Comments

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

CTS 164: 802.11ax Target Wake Time

April 1, 2019 François Vergès Podcast 00:48:02 0 Comments

Objectives of TWT

Objectifs of 802.11ax

  • Increase the performance of the Wi-Fi network by a factor of 4 while improving or not impacting power requirements
  • Provide power saving mechanisms for new emerging IoT devices

All the current power saving mechanisms defined today remain usable with ax. In addition, the 802.11ax draft defines a new mechanism called Target Wake Time or TWT.

Target wake time (TWT) is used to help minimize contention between clients and reduce the amount of time a client in power save mode to be awake.

Clients will operate in non-overlapping times and/or frequencies and the frame exchanges are coordinated.

TWT was introduced in 802.11ah and is particularly useful for battery-powered devices that communicate infrequently.

TWT Modes of Operations

There are three modes of operation:

  • Individual TWT
  • Broadcast TWT
  • Opportunistic PS

TWT Power-save options in 802.11ax from Aruba 802.11ax White Paper:

TWT Power-Save options in 802.11ax

Individual TWT

Client will be assigned specific times to wake up and exchange frames. The schedule is determined and delivered by the AP. There is a different mode of TWT such as explicit TWT. A client doesn’t need to know about another client’s TWT values.

Simple process:

  • A client wants to establish a TWT agreement
  • A client communicates its waking schedule information to the AP
  • The AP devises a schedule and delivers TWT values to the client
  • The client wakes up and transmit a frame according to the schedule
  • The AP send the client the next TWT information on when to wake up again (explicit mode)
  • The client wakes up again at the next scheduled time to send a frame and receive a new TWT information
  • When TWT implicit is used, the client calculates the Next TWT by adding a fixed value to the current TWT value

A client can go off of the AP’s TWT parameters. Or a client can “demand” a TWT with indicated parameters for agreement. If agreed upon, the AP will respond with “Accept TWT”. The AP can counter the offer with an Alternate TWT.

A client wanting to utilize TWT will indicate what channel to use as a primary channel during a TWT SP.

Broadcast TWT

The AP will be in charge. The AP will send TWT parameters in the Beacon frame using the TWT Element. The TWT Element might be sent in other management frames as well such as the (Re)Association frame or the probe response frame.

The clients will use the TWT parameters from the most recently received TWT element carried in the Management frames of its associated AP. The client is also called “TWT Scheduled STA” in this case in the draft. The AP is called “TWT Scheduling AP”

The AP will provide the schedule to all the clients that supports broadcast TWT.

The AP will send a trigger frame to discover which clients are awake. The AP will then send frames to these clients that will, then, be able to doze again. This is called a trigger-based TWT SP (Service Period).

Clients can device to join or leave a broadcast TWT. This is done by an exchange of frame that carry TWT elements.

Find the information in 802.11ax Frames

Subfields to identify client support of TWT modes:

  • TWT Requester Support
  • TWT Responder Support
  • Broadcast TWT Support

TWT Element

The Control field will indicate the negotiation type: Individual, Broadcast or Wake TBTT interval.

When Individual TWT is used, the TWT parameter Information field will have this format:

When Broadcast TWT is used, the TWT Parameter Information field will have this format:

Sections Talking About TWT in the 802.11ax Draft

9.4.1.60 – TWT Information field – p.118

9.4.2.200 – TWT element – p.139

9.6.25.9 – TWT Teardown frame format – p.185

10.43 – Target wake time (TWT) – p.234

27.7 – TWT Operation – p.312

Example

Here is an example of a beacon frame coming from a 802.11ax Aerohive AP (AP630). If we look into the “HE Capabilities” information element, we can drill down into the “HE MAC Capabilities Information” and validate both the “TWT Requester Support” and “TWT Responder Support” flags. In this case, they are set to 0, which means that the feature is not yet supported by the firmware used on this AP.

Then, we can take a look at the “TWT Required” flag located in the “HE Operation Parameters”. Here again, it is set to 0.

We should be able to show you example of TWT being supported later on this year as vendors update their 802.11ax AP firmware and start enabling the feature.

This Week In Wireless

Top 5 Episodes

CTS 086: Capacity Planner, Ubiquiti and Fedex Forum

CTS 064: Wi-Fi Roundtable 1 – Part 1

CTS 052: How To Validate Wi-Fi Infrastructure

CTS 084: Channel Widths with Devin Akin

CTS 062: K12 Wi-Fi Deployments with Jim Vajda