meraki

CTS 162: 802.11ax OFDMA Subcarriers

With OFDMA in 802.11ax, the size of the subcarriers has been divided by 4. Going from 312.5KHz wide with OFDM to 78.125KHz wide.

The symbol duration has been increased by 4 times in the meantime. Going from 3.2 microseconds with OFDM to 12.8 microseconds.

Zooming into the subcarriers of a 20 MHz channel width

View the full image here

Advantages of having more subcarriers

  1. Allow OFDMA to extend to small sub-channels. Each sub-channel requires at least one (usually two) pilot subcarriers, and with a 2 MHz minimum sub-channel size, a smaller subcarrier spacing loses a much smaller percentage of the overall bandwidth to pilots.
  2. The number of guard and null subcarriers across a channel can be reduced as a percentage of the number of usable subcarriers, again increasing the effective data rate in a given channel. The figures above show a ~10% increase in usable subcarriers compared to 802.11ac, after allowing for the 4x factor. Example: OFDM: 64 subcarriers, 12 GuardNull subcarriers = 18.75%, OFDMA: 256 subcarriers. 22 GuardNull subcarriers = 8.5%.
  3. The longer OFDM symbol allows for an increase in the cyclic prefix length without sacrificing spectral efficiency, which in turn enables increased immunity to long delay spreads, especially in outdoor conditions. The cyclic prefix can be reduced to a smaller percentage of the symbol time, increasing spectral efficiency even while more robust to multipath conditions. And it reduces the jitter-sensitivity of uplink multi-user modes.

The smallest sub-channel is composed of 26 subcarriers.

Type of subcarriers:

  • Data subcarriers
  • Pilot subcarriers
  • DC subcarriers
  • Guard subcarriers
  • Null subcarriers

A 26-tone RU consists of 24 data subcarriers and 2 pilot subcarriers.

A 52-tone RU consists of 48 data subcarriers and 4 pilot subcarriers.

A 106-tone RU consists of 102 data subcarriers and 4 pilot subcarriers.

A 242-tone RU consists of 234 data subcarriers and 8 pilot subcarriers.

A 484-tone RU consists of 468 data subcarriers and 16 pilot subcarriers.

A 996-tone RU consists of 980 data subcarriers and 16 pilot subcarriers.

DC (Direct Current) subcarriers are used for the subcarriers located in the center of the channel. Depending on the channel width and the number of tone used, the number of DC subcarriers can vary (Ex: 3 or 7 for a 20MHz wide channel). Most of the time it will be 7 for the 20MHz and 80MHz wide channels and 5 for the 40MHz wide channels.

A 20MHz wide channels has 11 guard interval: the first 6 and the last 5 of the channel.

Here are the diagrams extracted from the 802.11ax draft document detailing the structure of the subcarriers for each channel width using different RUs sizes:

Links & Resources

Meraki MR55 and MR45 802.11ax (Wi-Fi 6) access points
Meraki MR45 802.11ax (Wi-Fi 6) access point
Meraki MR55 802.11ax (Wi-Fi 6) access point

CTS 144: Meraki Wi-Fi Tips

Rowell and François discuss their tips and advice when running a Meraki Wi-Fi network in challenging environments such as warehouse, hospitals, and dense office environments.

Meraki Wi-Fi Tips

There’s a big appeal for organizations to use Meraki. The ease of management is the biggest factor. With the management interface being user friendly and the hardware having a very minimalistic look and feel, there’s no question why it’s so popular.

But making something easy to use does create other challenges when it comes to Wi-Fi. Some scenarios are not as easily solved with Meraki, or any other vendor for that matter. There are a lot of configurations which could lead to poor performance. We’ve seen it before with our existing clients and wanted to offer our tips.

Design

We’ve noticed many people opt to skip design altogether. Or maybe they are unaware that a design is needed. This is the biggest mistake. Before we dive into Meraki specifics, we wanted to take this chance to remind everyone to have a design completed by a Wi-Fi expert.

Know your devices and applications

Planning and design are critical. This involves knowing what type of devices will be using Wi-Fi. Those devices will dictate how your configuration will be for your Meraki network. We’ve seen many misconfigurations which lead to users complaining about Wi-Fi performance due to not knowing how the devices utilize Wi-Fi and what applications are being used.

Turn off 2.4 GHz radios

By default, every single 2.4 GHz radio is enabled. In a warehouse, every AP can hear each other because of reflections and open space. Signal travels very far. In one example, a warehouse was seeing over 60% channel utilization on every AP in the 2.4 GHz spectrum. After about half of the radios were disabled, the channel utilization dropped to under 20%. A design will provide indicate which AP should or should not have a 2.4 GHz radio enabled. Coverage holes should not be created if devices must use 2.4 GHz.

Channels

With every radio being enabled by default, we must keep in mind what channels are being used and how much we can reuse. Using wider channel widths can look appealing because of the high throughput but at the cost of minimizing how many channels you can reuse in your environment before causing co-channel contention. Again, a design will produce a channel plan in both 2.4 GHz and 5 GHz. Our guidance is to stick to 20 MHz or 40 MHz wide channels.

Transmit Power

All we have to say here is tune down the power. There’s no need to transmit at full power. That signal travels very far and can contribute to co-channel contention. Sometimes the AP cannot hear the client device transmitting back to the AP because clients don’t have the same power capabilities as APs. Use a design to determine the transmit power settings of an AP.

Placement is key

Again, we must reiterate the benefits of doing a design. Placement is important especially when dealing with scanner guns, roaming clients, and VoIP calls. APs placed away from obstruction will provide the best performance and will minimize the amount of client issues.

External antennas help tremendously

Sometimes omnidirectional antennas just don’t do the job. We need to provide better quality signal to the clients and this is where antennas help a lot. You can shape the signal you want, for example, down an isle. Or if you need to wall mount an AP but direct a signal to a specific area then an antenna can do that job for you.

Client balancing

Sometimes the client balancing feature within Meraki can cause issues with clients on voice calls. I’ve seen clients on a VoIP call get dropped due to client balancing. In a warehouse, scanner guns weren’t roaming properly because some APs had more users than others so client balancing was affecting how users were roaming.

Band steering

Clients ultimately decide where they want to go. So why force them over to 5 GHz if 2.4 GHz is better? Or maybe the device is a 2.4 GHz only client? Another way of doing this is to create two specific SSIDs for each band. Either way, sometimes band steering doesn’t work the way we expect it to because clients control where they want to go.

RRM

RRM can be a very useful feature if you have many APs. It can help tune your environment. But most people don’t tune their settings in favor of RRM. So we see suboptimal settings selected for each AP. Honestly, sometimes the Meraki algorithm doesn’t pick ideal settings. Sometimes static configuration can be beneficial if RRM isn’t making the right choices.

Hidden network for mesh

If you aren’t using mesh capabilities, submit a ticket to have this feature turned off. By default there are hidden networks being broadcasted for mesh. You don’t see them but they show up on a validation survey.

Meraki Weirdness

Are you seeing these narrowband spikes when viewing the RF Spectrum within the dashboard? Do you see the same thing at channel 1, 4, 5, 9, and 11? Here are examples from our networks:

François’ networks:

Rowell’s network:

Meraki Health Aims for Rapid Root Cause Analysis

Meraki Health

Cisco Meraki is rolling out the new Meraki Health dashboard to customers. The goal is to allow IT staff to quickly identify root causes to various Wi-Fi issues. It’s the common trend amongst cloud-managed Wi-Fi vendors.

Troubleshooting Wi-Fi connectivity is a difficult skill to master by an individual. Without the in-house expertise, IT is often left relying on dashboards to tell them what’s wrong.

Heuristic Approach

Meraki Health is taking a heuristic approach to troubleshooting. The dashboard uses a technique to help in problem-solving by learning and discovering what’s happening on the Wi-Fi network. Then those root causes are presented on-screen.

This new visual method of troubleshooting allows a quick look into what types of issues clients are experiencing. It can be narrowed down to specific access points and into types of applications.

The Client Journey

We’re provided insight into the client journey on a Wi-Fi network. Meraki Health takes a look at 5 different steps of the client journey:

  • Association
  • Authentication
  • DHCP
  • DNS
  • Latency

At each step there’s a visualization into the percentage of successful or failed connections. Breaking out each step provides a simple approach to troubleshooting and getting down to the real cause of the issue.

An example could be at the authentication step with a user incorrectly typing in the password for the SSID.

Latency visibility offers insight into how applications are performing over Wi-Fi. Latency is broken down into traffic types, drawing similarities to QoS traffic types. The visualization indicates the percentage of latency traffic encountering poor performance.

The scope can then be narrowed down to specific applications such as YouTube, Skype, or other applications.

View of the Meraki Health visualizations.

Spotting the anomalies

Rowell’s Take

It’s a great addition to the Meraki solution. By giving the power to network operators, they are more capable of solving some of the most common Wi-Fi issues. The biggest advantage with Meraki Health is the ability to solve these issues quickly.

What I find interesting is Meraki Health takes a heuristic approach rather than stepping into artificial intelligence and machine learning to take troubleshooting to the next level.

Meraki can leverage their cloud infrastructure to build a solution which can help solve issues automatically by learning client traffic patterns and flows to help the network tune itself. For example, seeing where an area is about to become highly dense with devices and capacity is to increase.

The dashboard can help network operators become more proactive over these situations by bringing it to attention before the event impacts clients.

François’ Take

Meraki is often used by customers having a small IT team without extensive Wi-Fi expertise. So this new feature is a great tool which will help them to troubleshooting day-to-day Wi-Fi issues. I won’t be surprised if this feature keeps getting better over time so it can be used and understood by most IT professionals.

I believe it is very interesting to see network companies spending more and more time on developing software which will help the customer provide a better over solution. It is just the beginning. I am expecting to see more and more vendors coming out with software solutions in order to complement their hardware offers and help the users better take advantage of the hardware. It is also a way for them to create a competitive advantage over the competition.

User experience is very important for me on every project I work on and that’s why I like this new Health feature as it helps us to provide a better user experience overall.

CTS 117: A Wi-Fi Engineer Goes to DevNet Create

What’s coming up for Wi-Fi with developers and how can we learn to automate our Wi-Fi day-to-day?

DevNet Create 2018

I was expecting to be amongst the developers but I left feeling inspired about what we can create while working with Wi-Fi. This was my first time attending DevNet Create and it certainly won’t be my last.

The event was held at the Computer History Museum in Mountain View, California.

It’s not too far from Googleplex so I could already smell the scent of developer..just kidding.

This small event had maybe around 300 attendees. Each workshop was held on in a large room where the presenter spoke to a small crowd. Very intimate.

DevNet Create had an interesting agenda line up. I was primarily interested in the workshops which had to do with Wi-Fi. The sessions I joined in on were:

NetDevOps Engineer Everyday Skills
Gabriel Zapodeanu | Cisco, Global Partner Organization
Do you want to learn how to write simple ChatOps apps for IOS XE network devices? This session will explore a few IOS XE device programmability capabilities to help you create your first ChatOps application using NETCONF, RESTCONF, and Guest Shell.
Planning to join the workshop?

Indoor Location-based Services Using Wi-Fi
Mathieu Gerard | Mapwize
In this workshop, we will build a simple mobile application allowing users to view the map of the building, see their position provided by the Cisco CMX or Meraki infrastructure, and get directions across multiple floors.

Automate your Network with Python and Meraki
Colin Lowenberg | Cisco, Meraki George Dorsey | Cisco, Meraki
You only need a basic understanding of programming and Meraki to complete this quick lab. Take Cisco’s own internal training on Python for network automation. We will walk through the setup on your laptop and use a pre-written Python script to interact with the Meraki Dashboard API.

Introduction to Meraki API’s Through Node Red
Michael Chenetz | Cisco
Meraki is intended to be an easy platform. So why not have any equally easy way to program interactions through the use of visual programming? In this talk I’ll introduce you to Node Red for Meraki. Learn programming by combining objects to create applications.
Planning to join the workshop?

Anyone who attended the event had a chance to get a free Meraki switch with a 3-year license by just completing a Meraki challenge. You yourself can try out the challenge (minus receiving the free switch).

Overall, I thought it was a great event. I was able to meet up with good friends and learn how automation and coding can help us in our day-to-day jobs. I feel very inspired about what I may be able to do in the near future. At the end of the conference I purchased my own copy of Learn Python 3 The Hard Way.

Links and Resources