This is a very simple article just explaining how you can connect to a Cisco WLC (aireos) using a python script.

You could use this as a first step in developing more advanced Python scripts to monitor or configure your Cisco Wireless Lan Controllers.

I am still learning Python so this might not be the only and easiest way to do it!

We will assume that you have already Python installed on your computer. I would also advise you to use virtual environment when developing Python scripts on your computer.

Here is the tutorial I have followed in order to setup my laptop (macOS) for Python programming: ​https://developer.cisco.com/learning/lab/dev-mac/step/1

Here are the program and libraries we will be using here:

• Python 3.7
• netmiko

Here is how I setup a virtual environment for Python 3.7 on my  laptop:

Here is how I installed the netmiko library within this new virtual environment:

Here is the Python code you will need to in order to connect via SSH to a Cisco WLC. Obviously you need to gather this information first:

• IP address of the WLC
  
• Username allowed to SSH into the WLC
  
• Password associated with that user 

In this example, we are using the object called ConnectHandler from the netmiko library to establish an SSH connection to the WLC (192.168.20.2).

​Once connected, we are sending the command "show ap summary" and we are displaying the output of this command.

Connecting to the Cisco WLC could be the first step in a more complex script. Therefore, I have done the following in order to ease the process:

1. Created a configuration file where I keep my WLC details (IP address, username and passwords)
2. Created a script that I called ssh_wlc.py that defines function that will establish the connection based on the WLC configuration file

I then re-use my script as a "library" whenever I work on a script and I need to connect to a Cisco WLC.

Note: Python 3.5+ is required here since we are using PEP 484 type hints.

Here is what my configuration file looks like (I used xml so it is easier to parse):

Here is what my ssh_wlc.py script looks like:

As I continue to learn more about Python, I will continue to share it with you guys on the blog.

If you know other alternatives to do the same thing, please feel free to add a comment.

Thank you!


​written by François Vergès

Thanks to Florent Lassia, we were able to configure the Wi-Fi NIC to bride to the Ethernet NIC. In the Hotspot mode, you can now have your Wi-Fi hotspot running, connect a client device to that Wi-Fi network and receive network connectivity to the LAN if your WLAN Pi is connected to the LAN via its Ethernet interface. We have detailed how to do it on this blog post: ​https://www.semfionetworks.com/blog/wlan-pi-bridge-wi-fi-hotspot-to-ethernet-interface

Thanks to Nigel Bowden and Jerry Olla. This feature has been incorporated into the image of the WLAN Pi OS starting with version v1.7. Visit this link to see how it has been implemented: https://github.com/WLAN-Pi/wlanpi-hotspot

It has also been implemented as a new "Action" mode in the new NanoLED menu: https://github.com/WLAN-Pi/wlanpi-nanohat-oled

I love the fact that the WLAN Pi is very small and compact. It is very easy to have it always available with me in my backpack. So I like to use it as a Wi-Fi source when I measure wall attenuation. In order to do so, you need to setup a Wi-Fi hotspot so that the WLAN Pi can broadcast a Wi-Fi signal when you connect a Wi-Fi NIC.

In this article, I will explain how to configure the WLAN Pi so you can use it as a Wi-Fi hotspot. You could then use your WLAN Pi to perform the following:

• Use it as a source to measure wall attenuation (see this article by Nigel Bowden for more details on how to do these measurements: https://www.ekahau.com/blog/2015/09/07/wi-fi-planning-walls-and-dbs-measuring-obstruction-losses-for-wlan-predictive-modelling/)
• Use it to perform Wi-Fi speedtests (I personally use this to show the students what a typical OFDM signal looks like on the spectrum)

Here is the video tutorial that explains the whole setup. You can also find the same steps detailed in this article.

I started this configuration from scratch so you can (hopefully) replicate it on your end. I started from the newest wlanpi image available on github. Follow these steps to start the process:

1. Download the latest version of the wlanpi image on this website: https://github.com/WLAN-Pi/wlanpi/releases
2. Load it unto the microSD card that you will use for your wlanpi (I use the program called etcher on macOS)
3. Insert the microSD card into the wlanpi
4. Connect the wlanpi to your network (via the ethernet interface)
5. Connect the Wi-Fi NIC to the wlanpi (via the USB port)
6. Power the wlanpi ON

Here is a picture of my setup (I connected the wlanpi directly to my laptop):

Once the wlanpi is UP and RUNNING, you should be able to see the IP address that the wlanpi received on its Ethernet adapter. Use this IP address to establish an SSH connection between your computer and the wlanpi. By default, the following credentials are used to connect to the wlan:

• Username: wlanpi
• Password: wlanpi

Once connected, we will create a new user and give this new user some privileges.

1. Use the following command to create a new user: sudo adduser username
2. In the following prompts, specify which password you want to use for this user
3. Use the following command to give this user sudo privileges: sudo usermod -aG sudo username
4. Finally, try to connect using this new username and password: su - username

Finally, we will modify the user PATH so we can get access to some basic commands such as ifconfig, iwconfig or iw.

1. In the home directory of the user, open the .profile file using the following command: sudo nano .profile
2. Modify this file by adding the following line at the end of the .profile file:  PATH=$PATH:/sbin:/usr/sbin
3. Save and close the .profile file
   
4. Once back in the shell, reload the profile using this command: source .profile
5. You should now be able to use the ifconfig command

In order to configure the Hotspot, we are going to use a linux program called hostapd. This program should already be installed on the wlanpi based image.

1 - Verify that the hostapd is installed by using the following command: dpkg --list | grep hostapd

If hostapd is not installed, you can install it using the following command: sudo apt-get install hostapd

2 - Then, we need to configure hostapd so it create a Wi-Fi network. In my case I create a network on channel 36 called "Allez Les Bleus". I defined it on 5GHz as I would use the tool to perform my wall measurements attenuations. In order to modify the configurations, you need to modify the file called /etc/hostapd.conf. You can open it with nano to modify it: sudo nano /etc/hostapd.conf

If you want to modify other settings, feel free to take a look at the hostapd documentations: ​https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf

Now we need to modify the way the W-Fi NIC interface (wlan0) is configured. By default, it will be configured to be used in monitor mode in order to perform Wi-Fi analysis. In order to use it to start up a hotspot, we need to change its configuration and give it an IP address.

1 - Validate that the wlan0 interface is UP (it should be up if you connected the NIC) using the following command: ifconfig.

2 - The network interfaces configurations are located in the following file: /etc/network/interfaces. Update the wlan0 configurations as follow by opening the file with nano: sudo nano /etc/network/interfaces

Feel free to choose whichever IP network you want to use.

Note: some Engineers had to add the following line in the /etc/network/interface file in order to make it work: hostapd /etc/hostapd.conf. You could try it out if this is not working out for you after the first try.

This task gave me a little bit more work. I originally tried to make it work with dnsmasq but failed. I couldn't make it work. So I started to look at alternatives and came across a program called isc-dhcp-server. It also turns out that the package is already installed on the wlanpi base image. In this section, we will explain how to configure the isc-dhcp-server to provide IP address to our hotspot Wi-Fi network.

​1 - Verify that the isc-dhcp-server is installed by using the following command: dpkg --list | grep isc-dhcp-server

2 - We need to tell the isc-dhcp-server that we will be expecting to receive DHCP requests on the wlan0 interface. To do so, modify the /etc/default/isc-dhcp-server file as follow: sudo nano /etc/default/isc-dhcp-server

2 - Then, we need to configure the new DHCP pool that we will be using for our Wi-Fi Hotspot network. To do so, we need to update the following configuration file: sudo nano /etc/dhcp/dhcpd.conf

Make sure that the pool is within the subnet you are using for the wlan0 interface.

All we have to do now is test and validate that everything is working well.

1 - Start the hostapd application using the following command: sudo hostapd -d /etc/hostapd.conf

2 - Validate that the SSID is broadcasting. In my case, I used my iPad to validate that the "Allez Les Bleus" SSID was broadcasting. You can also use a Wi-Fi scanner to validate that it is broadcasting on the configured channel.

3 - Try to connect to this SSID and see if you receive an IP address within the pool configured. In my case, I used my iPad to connect and I received the following IP address: 192.168.88.100.

4 - Navigate the http://192.168.88.1 to validate that you can reach the HTML5 speedtest installed on the wlanpi. From there, you can start a speedtest and validate that everything works fine.

5 - (optional) Open up a spectrum analyzer and look at the activity on the channel while performing the speedtest. This can help you to understand what a Wi-Fi signal (OFDM) looks like on the spectrum.

We will use the crontab program to tell the OS to start hostapd when the WLAN Pi boots up.

1 - Enter the following command to configure the crontab configuration file: sudo crontab -e
2 - In the configuration file, add the following line: @reboot sudo hostapd -d /etc/hostapd.conf

Working on this a couple of other ideas came to mind on how we could improve this:
1 - Work on a script that would active the hotspot automatically when the Wi-Fi NIC is connected
2 - OR EVEN BETTER, reprogram one of the button to start the hotspot when pressed and disable it when pressed again. UPDATE: this is now part of the standard WLAN Pi image starting at v1.7. See https://github.com/WLAN-Pi/wlanpi/releases.
3 - Complete the configuration to bridge the Wi-Fi Hotspot to the Ethernet interface so we can pass traffic through. You could then use it to setup your own local connection when the Hotel Wi-Fi is bad ;). UPDATE: we made it work, check out this blog post: https://www.semfionetworks.com/blog/wlan-pi-bridge-wi-fi-hotspot-to-ethernet-interface.

Please let me know if you have more ideas and please let me know if you have the skills to make the three listed above happen!

I hope this can be useful for some.

Thank you!


​
written by François Vergès

In this article, we will explain how to install the new Cisco Catalyst 9800-CL controller on a VM (under VMFusion) on macOS.
​
The goal here is to have a lab controller that you can bring with you wherever you go and can be booted anytime and intended to be used for testing purposes.

This is the first article of a series of Cisco Catalyst 9800-CL article.

Note: If you want to know how to set it up on a VMware ESXI platform, please check out Rowell Dionicio's article: https://rowelldionicio.com/deploying-cisco-catalyst-9800-controller-on-vmware-esxi/
​

The first step is to download the new Cisco Catalyst 9800-CL Wireless Controller for Cloud. The latest version available to me was called Gibraltar-16.11.1b. It might be different for you if you are downloading it at a later date.

​Here is the link (you will have to log in using your Cisco credentials): https://software.cisco.com/download/home/286322605/type/282046477/release/Gibraltar-16.11.1b

For this setup, we will download the .iso file. Note that you can now download the controller code for free. The licences are not tied to the AP.

Note: In this article, we will present how to create a VM to support the new Wireless controller using VMWare Fusion on MacOS.

Open VMWare Fusion, and select the menu “File / New…” to create the new VM. In the new window opening, select the “Create a custom virtual machine” as shown below:

The operating system to select is “Linux / Other Linux 4.x or later kernel 64-bit” as shown below:

Select “Legacy BIOS” as the boot firmware as shown below: 

Select Create a new virtual disk as shown below:

Validate that all the settings are good and click on Finish. VMware will ask you to save your vm and to choose a name. Note: I have chosen “C9800-Lab” for my VM name.

​We are now going to use the GUI to adjust the RAM allocated to the VM and load the iso file. We need to change the default settings to allocate at least 4Gig of RAM. In order to do so, click on the settings icon located on the top-righthand corner of the Virtual Machine Library window:

Click on the “Processors & Memory” icon to change the RAM settings:

Adjust the Memory to 4096MB (Note: this is aimed to be used in a lab environment, please refer to Cisco deployment guides in order size the VM properly):

Click on “Show All” to go back to apply the new settings.

Then click on “CD/DVD (IDE)” in order to load the iso file previously downloaded on Cisco website:

In the drop down menu, click on “Choose a disc or disc image…” and select the .iso file download before (the name should look like this: C9800-CL-universalk9.16.11.01b.iso).

Click on “Show All” to go back to apply the new settings.

Before we start the VM, we need to adjust the network settings. In my case, the network settings were greyed out in the VM settings. So I couldn’t modify them using the GUI. I had to modify the configuration file of the VM in order to adjust the network settings.

On macOS, the VM configuration file was located at the following location (/replace "C9800-Lab" by the name your chose for your VM and "francoisverges" by your macos username/):

Here is what we need to do:

1. Network Adapter 1: Configure the first network interface as a “custom” interface on a local network. This will be used as the management interface of the controller.
2. Network Adapter 2: Configure the second network interface behind the Wi-Fi card. This will be used to connect the Wi-Fi clients to the internet.

In order to configure your VM network interfaces, you will have to know the name of the interfaces used on your Mac. Open your favourite terminal application and use the `ifconfig` command in order to find it out. In my case, en0 is the name of the Wi-Fi interface and en7 is the name of my ethernet interface:

In your terminal application, open the VM configuration file in order to change its configuration:

​Here is how to configure the first network adapter in the configuration file, change your configuration file accordingly:

​Here is how to configure the second network adapter in the configuration file, change your configuration file accordingly:

​Here is how the network interfaces were configure on my macbook:

​In order to start the VM for the first time, go back to the settings icon located on the top-righthand corner of the Virtual Machine Library window:

Select the “Startup Disk” menu:

Select the “CD/DVD" option and click on “Restart” to start the VM for the first time as shown below:

The controller will boot. The first time, VMWare Fusion might ask you to enter your MacOS password a couple of time. Once the bootup process will be done, you will be ready to perform the initial configurations.

I usually like to perform the inital setup via CLI. The new Catalyst 9800 allows you to do it. But first, you need to decline the autoinstall.
​When asked to start the initial configuration dialog, write "no". Then press RETURN when asked to terminate the autoinstall. Press RETURN one more time and you should then see the WLC prompt:

Then you will need to configure the following:

1. Configure the enable password
2. Create an admin account
3. Configure the network interface G1
4. Configure a default route
5. Configure the country code
6. Configure which interface will be used for management purposes (G1 in our case)
7. Generate the certificate that will be used to establish DTLS connections with the APs

Use the following commands in order to configure all these items:

Once these configurations are done on the Catalyst 9800 controller, you should be able to ping it from your laptop:

If this works well, you should now be able to open a browser, and navigate to https://10.0.0.10 to connect to the controller GUI. Use the admin username defined earlier to login and gain access to the GUI: 

Mission accomplished! You should now have the controller up and running. The next step would be to add an AP and configure an SSID.

To be continued...

• Cisco Catalyst C9800-CL Wireless Controller Virtual Deployment Guide: www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-8/b_c9800_wireless_controller_virtual_dg.html
• Catalyst 9800 CL Install Guide:   www.cisco.com/c/en/us/td/docs/wireless/controller/9800/9800-cloud/installation/b-c9800-cl-install-guide.pdf
• Release Notes for Cisco Catalyst 9800 Series Wireless Controller, Cisco IOS XE Gibraltar 16.11.x: www.cisco.com/c/en/us/td/docs/wireless/controller/9800/16-11/release-notes/rn-16-11-9800.html
• C9800-CL for my Homelab by Tim Saas: http://wifi-blog.com/2019/01/31/c9800-cl-for-my-homlab/

written by François Vergès

I recently purchased a Wi-Fi 6 device (Samsung Galaxy S10), and when I checked which date rate it was using over the Wi-Fi, this is what I got:

I wanted to find out which MCS index and which modulation was used but after doing some research online, I couldn't find any easy resources that could give me the new data rates available with 802.11ax (Wi-Fi 6). So I decided to create that resource myself.

This blog presents the results of the new MCS table updated to include all the new 802.11ax data rates. It also presents how these data rates are calculated.

The following table includes all the MCSs data rates defined by the 802.11n (HT), 802.11ac (VHT) and 802.11ax (HE) amendments:

Here is a link to the full MCS Table: ​http://bit.ly/2G0DIcD

​As you can see, the table is getting very big. In fact, 802.11ax is introducing 2880 new data rates. However, not all data rates will be used in the real world. In order to focus on what will be most useful to Wi-Fi Engineers, I have created some smaller tables which only focuses on sections of the complete table.

This table presents 802.11n (HT), 802.11ac (VHT) and 802.11ax (HE) data rates for up to 3 spatial streams:

Here is a link to the spreadsheet: http://bit.ly/2KksViN

This table only presents the data rates for 802.11ax communications up to 3 spatial streams:

Here is a link to the spreadsheet: bit.ly/2Ia1Pc2

This table only presents the data rates for 802.11ax communications when OFDM is used:

Here is a link to the spreadsheet: http://bit.ly/2VwYNSk

This table only presents the data rates for 802.11ax communications when OFDMA is used:

Here is a link to the spreadsheet: ​​http://bit.ly/2VztdmU

First we need to understand how the MCS data rates are calculated prior 802.11ax. I am only going to focus on 802.11n (HT) and 802.11ac (VHT) here. 

Here is the formula we can use to calculate which data rate is used for both 802.11n and 802.11ac:

Let's detail each of these variables and which value they can have for both 802.11n and 802.11ac:

Now, the formula doesn't change much with 802.11ax. However, some new features will impact the way we calculate data rate for 802.11ax:

• 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 OFDMA.

Even though the formula doesn't change much, the IEEE does define 2 different formulas depending on if OFDMA is used or not. When OFDMA is not used, we can used the formula previously presented above.

Here is the formula we can used when OFDMA is used (it is pretty much the same except that we define the number of data subcarriers per RU and not per channel):

Let's now details each of these variables and which values they can have when HE (802.11ax) is used. 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.

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 5/6

So now that we have this information, let's try to understand the data rate that my phone was using.
The phone is a Samsung GS10 which supports 802.11ax and up to 2 spatial streams. The AP used is an Aerohive AP630. I have configured it with an 80MHz wide channel. OFDMA is not used here because ODFMA was not activated at the time of this capture.

So based on this information, we can determine some of the variables required to calculate the data rate and narrow down the data rates that will be used by this device:

• Number of Data Subcarriers for an 80MHz wide channel: 980
• Number of Coded bit per subcarrier (Modulation): we don't know yet
• Coding: we don't know yet
• Number of Spatial Streams: 2
• OFDM Symbol Duration: 12.8µs
• Guard Interval: we don't know yet

So here is the list of possible data rates used by this device when connecting to this AP:

Because we know that the data rate used was 1200.95 Mbps (as indicated on the picture above), we can now determine that:

• MCS 11 was used
• 1024QAM with a coding of 5/6 ​was being used
• A guard interval of 0.8µs was used

As always, comments and feedbacks are welcomed! Let's make it better together :)
​

Here are some related resources used to create the timeline:

• Wi-Fi Alliance Security Page: https://www.wi-fi.org/discover-wi-fi/security
• Wi-Fi Alliance WPA3 Specifications: https://www.wi-fi.org/download.php?file=/sites/default/files/private/WPA3_Specification_v1.0.pdf
• Wi-Fi Certified Enhanced Open delivers data protection in open Wi-Fi networks: https://www.wi-fi.org/news-events/newsroom/wi-fi-certified-enhanced-open-delivers-data-protection-in-open-wi-fi-networks
• OWE Specifications: https://www.wi-fi.org/download.php?file=/sites/default/files/private/Opportunistic_Wireless_Encryption_Specification_v1.0_0.pdf
• RFC 8110 - Opportunistic Wireless Encryption: https://tools.ietf.org/html/rfc8110
• RFC 7664  Dragonfly Key Exchange : https://tools.ietf.org/html/rfc7664
• IEEE 802.11 Timeline: http://www.ieee802.org/11/Reports/802.11_Timelines.htm

​I am really excited about 2019. The Wi-Fi technology is always evolving, bringing new challenges along the way. And this year is no exception. I am looking forward to the challenges that I will face this year and I am looking forward to the new learning experiences that 2019 will bring.

In this article, I talk about some of the important trends that I think will be quite popular in the discussions we will have among the community or with our customers.

​Last year, we talked a lot about the theory behind Wi-Fi 6 (or 802.11ax). We saw a couple of enterprise vendors coming out with 802.11ax access points (Aerohive, Aruba Networks). We also saw a few consumer 802.11ax access points being released. However, we still haven’t heard about any 802.11ax client devices yet.

So this year, I really hope that we will start seeing some Wi-Fi 6 client devices being release so we can start playing with it. I would like 2019 to be the year of Wi-Fi 6 in practice and not only in theory. I would love to see the future iPhone supporting Wi-Fi 6.

Nevertheless, from an Engineer point of view, I believe that we will have to keep educating ourselves on the technology. First, because we need to apprehend it better. Second, we need to be able to advise and educate our customers. We are going to see a lot of false positive messages around the Wi-Fi 6 technology and we need to be able to guide and help our customers.

​As we will see more and more service providers deploying 5G this year, we will continue to talk about it among the Wi-Fi community. The question is always: will 5G replace Wi-Fi in the long run? It might have the potential to do so in some cases. However, I still think that Wi-Fi will still stick around for a long time. I don’t really see the two technologies necessary competing with one another. I believe they will be complementary in most cases.

In the enterprise space, I have seen a couple of companies in Europe using alternative wireless solutions when Wi-Fi was not perfectly applicable to their use case. So I do see the use of alternative wireless solutions, such as CBRS/private LTE, being used more this year. On that note, Ruckus is coming to market with a set of CBRS LTE access points and the FCC has reserved some spectrum in the 3.5GHz band to be used for CBRS.

I have personally started to see automation changing my work and the way I see my work. I believe that it is becoming more and more part of our work today and will continue in 2019. Automation requires us to learn about programming (or at least scripting). So this is not going to be an overnight transition. This is definitely something that will help us and that we can take advantage of.

With more and more vendors offering APIs to interact with their equipment, it becomes part of the technical solution and can help us configure and monitor our infrastructures. On that note, I have seen a couple companies hiring programmers to add to their networking team in order to program additional services which will interact with the Wi-Fi infrastructure using APIs. From the point of view of a VAR or consultant, it is a good way to perform the work faster and, therefore, be more competitive.

Cisco released their new WLAN controller (Catalyst 9800 Wireless Controller) at the end of 2018. They have completely re-written the code and the new OS looks promising. One of the features is that it can now be installed on a public Cloud (such as AWS). We have also seen very good results from Meraki in 2018 (compared to traditional Cisco WLC). Mist started to really take up being involved with Fortune 10 companies. Aerohive launched their own NAC platform in the cloud (A3).

All of this leads to making me think that Wi-Fi solutions will leverage more and more cloud services in 2019. The cloud clearly allows the systems to be more intelligent, more flexible and we can all appreciate a little fewer bugs (or at least, faster ways to fix them).




What are your thoughts for 2019? Feel free to leave a comment to start the discussion.

Cheers'

François Vergès

This article presents the regulations around the use of the unlicensed 5GHz frequencies for Wi-Fi communications in Canada. It provides an update and consolidation of our previous articles and includes the changes made by ISED (Innovation, Science and Economic Development Canada) in 2017. We are also talking about the future outlook presented by ISED earlier this year.

In May 2017, ISED published a document announcing new regulations for the UNII1 band in Canada. Previously, this band was reserved for indoor use and the maximum EIRP was set to 200 mW. The new regulations now allow the use of these frequencies to be used both indoor and outdoor with a higher power. However, a license is required if you want to use UNII1 outdoor with an EIRP greater than 200 mW. The license is valid for 1 year and is free (for now).

​The new requirements to meet are presented in this table:

Source: ISED

If the equipment you are planning to use is located within 25km for a licensed earth station, you will have to coordinate the earth station operator to determine potential exclusion zones.
Users operating for personal use should not be eligible for that license. The reason is that it would involve too much administration and monitoring work.

DFS (Dynamic Frequency Selection) is a mechanism that allows wireless LANs to coexist with radar systems. It automatically selects a frequency that does not interfere with the radar systems. In Canada, any Wi-Fi devices operating on the channels 52-64, 100-116 and 132-140  have to employ a DFS radar detection mechanism. The use of DFS while implementing a Wi-Fi network is the choice of the Engineer. It allows you to use more channels for sure, however, the frequency change might bring some instability in the network. Moreover, the client devices are not always certified for DFS band operation which is the case for many portable devices. Therefore, many engineers prefer implementing their network without the use of these "DFS" channels.

If you want to learn more about DFS, feel free to take a look at the DFS Operations Infographic we have created:

ISED received comments proposing that some portions of the band become available for license-exempt devices (eg. Wi-Fi). However, they did not propose any specific changes to this band in 2018 pending potential outcomes of the WRC-19 (World Radio Conference).  There will most likely be some changes in the next few years. Since ISED is involved in the WRC-19 conference that will be taking place in Oct/Nov 2019, we could be expecting some changes as early as late 2019. Here are the potential changes:

• Use of the 5600-5650 MHz Band for license-exempt use. Channel 120, 124, 128
• Use of the 5350-5470 MHz Band for license-exempt use. Channel 68, 72, 76, 80, 84, 88, 92, 96
• Use of the 5850-5925 MHz Band for license-exempt use. Channel 169, 173, 171. This is unlikely as ISED prefers to reserve this band for connected vehicle applications. They will only allow Wi-Fi to share this band if they know for sure that it won’t be disruptive.

It feels good to be able to do what you like, it feels even better when there is a purpose in doing it. That is often something I ask myself when working on different projects for different customers. Am I making a difference? Who will benefit from my work? Who am I designing or installing Wi-Fi for?

I have found that our main purpose is to help the end users, perform their work in an easier way. This could be; helping a nurse providing care, a banker moving money around, a school teacher sharing  knowledge, a journalist reporting news, a warehouse worker moving goods or even sport fans supporting  their team.

The end users will be the ones using the Wi-Fi, enjoying the Wi-Fi, taking advantage of the Wi-Fi and maybe sometimes cursing the Wi-Fi. They are the reason why we do what we do. This is why, as a Wi-Fi Engineer, I always try to keep them in mind while designing, installing and troubleshooting a Wi-Fi network.

Focusing on the end user experience helps me to put the human factor back into the game. I consider it a very important part of my work.

François Vergès

The FCC and the EU has been talking about releasing more spectrum for unlicensed use in the 6GHz frequency band (5925 MHz to 7125 MHz). The focus was specifically to release more spectrum that could be used by technologies such as Wi-Fi, LTE-U and LTE-AAA.

This would give access to an impressive number of additional Wi-Fi channels:

• In the US:
  • 59x 20MHz channels 
  • 29x 40MHz channels
  • 14x 80MHz channels
  • 7x 160MHz channels
• In the EU:
  • 24x 20MHz channels
  • 12x 40MHz channels
  • 6x 80MHz channels
  • 3x 160MHz channels

As a Wi-Fi Engineer and seeing channel related problems every day, I get very excited knowing that more channels could become available. It could solve a lot of our issues and improve the overall performances of our Wi-Fi networks.

However, in Canada, the ISED does not have current plans of opening up the 6GHz band for licence-exempt use.

Currently, here is how the 6GHz band is used in Canada:

• 5925-6425 MHz: Two-way Backhaul. Uplink communication for FSS (Fixed Satellite Service) (delivery of broadband services + distribute TV programming) 
• 6425-7125 MHz: two-way Backhaul + TV auxiliary services and studio transmitter links.

​Also, the ISED mentioned that they were « not aware of commercially available equipment that would operate in a licence-exempt fashion in the 6GHz band ». This state might change has these bands might be embraced in the US and in Europe. More and more manufacturers might be interested in producing devices able to operate in the 6GHz band in the near future for these markets.

​n the near future, it does not look like the ISED will be releasing more spectrum in the 6GHz band for Wi-Fi use. The technologies using this band are not going anywhere and are still heavily using the band. Therefore, ISED has classified it as a priority 3 during their Outlook Consultation, earlier this year. This means that nothing much is going to happen in the next few year (between 2018 and 2022).

Here is the spectrum outlook priorities set by ISED for the next 5 years (2018 to 2022). As you can see 6GHz has been assigned a priority of 3:

​They did mentioned, in their Spectrum Outlook 2018 to 2022 document, that they will keep monitoring what is happening in the US and in the rest of the world to see if they could work on a solution where the current technologies using the 6GHz band would co-exist with new services (aka. Wi-Fi). This will probably require some coexistence mechanism to be put in place (The Wi-Fi industry is proposing a mechanism called Automated Frequency Coordination (AFC) that could be used in Canada as well).

​If we look at the FCC timeline, it looks like they will be starting permitting Wi-Fi operations on the 6GHz band by 2021. So, it’s hard to say what will be happening past 2022 but I would think that, at that time, they would have a plan to release some spectrum in the 6GHz band.

In parallel, the IEEE could potentially decide to only allow certain amendment to be used on the 6GHz bands which would strongly push ISED to release these frequencies for Wi-Fi use. It is already being said that the 802.11ax wave 2 devices will be able to operate on the 6GHz band.

•  ISED Spectrum Outlook 2018 to 2022: 
  •  https://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf11403.html
• Wi-Fi Trek Présentation from Chuck Lukaszewski « Opening the 6GHz band for unlicensed operations » :
  • https://doc-08-ac-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/diabgngrluu0j1ruolmbvtq7odhjdja7/1541109600000/13899844155198599612/*/1S5wZbFJrre4_NoD2X3mBUxHpeZQRIkPl?e=download
•  FCC Notice of Proposed Rulemaking « UnLicensed Use of the 6 GHz Band »
  • https://docs.fcc.gov/public/attachments/DOC-354364A1.pdf
• ​ EU Radio Spectrum Committee Working Document « Commission paper on a draft Mandate to CEPT on RLAN in the 6 GHz band (5925-6725 MHz) »
  • https://circabc.europa.eu/d/d/workspace/SpacesStore/d63ea67f-8171-4619-a53d-8feb57387c27/RSCOM17-40_RLAN%206%20GHz.pdf

Written by François Vergès

This infographic was inspired by the work of Nigel Bowden and Devin Akin. Nigel wrote this really good article on DFS that you can find on his website wifinigel.blogpost.com. Devin presented a really detailed webinar on DFS in partnership with Netscout. You can find the recording here.

I would encourage you to go and take a look at their ressources.

Note: there are a lot of disparities in the way DFS operations work between the different ​Wi-Fi vendors. It was a challenge to try to standardize it into one graphic. Please perform detailed testing of your own WLAN solution to find out what the actual DFS operations are in your environment.

​Click on the image below to download the infographic in the PDF format:

​Feel free to look at these ressources if you want to learn more about DFS operations:

• Nigel Bowden's Blog post on DFS: http://wifinigel.blogspot.com/2018/05/the-5ghz-problem-for-wi-fi-networks-dfs.html
• Devin Akin's webinar on DFS: https://www.brighttalk.com/webcast/5522/279895/designing-with-dfs-channels
• DFS Regulations in Canada: http://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf10971.html
• IEEE 802.11-2016 Standards Clause 11.9

I would like to thank Devin and Nigel for their help in reviewing the infographic and providing feedbacks. If you ​think of a way we could improve this infographic, do not hesitate to let me know in the comments below. 

Thank you!

Cheers,
François Vergès