Auto Channel dynamically adjusts the channels of the client serving radios to avoid RF interference (Both 802.11 and non-802.11) and develop a channel plan for the Wireless Network. Auto Channel is a good fit for most wireless networks, providing a baseline channel configuration that can then be adjusted manually if needed.
This article outlines how Auto Channel operates, and how to interpret channel change events.
Auto Channel is enabled by default on all Meraki Access Points. To ensure Auto Channel is enabled on a access point, navigate to Wireless > Configure > Radio settings in Dashboard and select a particular AP. The radio configuration for the Access Point will be displayed on the right hand side of the page. The Auto Channel algorithm will be used on radios that have "Auto" selected for their channel.
Dashboard follows best practices and industry standards in the Auto Channel selection, so APs' 2.4GHz radio will only be set to channels 1, 6, and 11. Since they do not overlap in frequency, these three channels have the least amount of co-channel interference. Other channels are included in the list and may be selected manually to override the Auto Channel algorithm.
Channel availability for 5GHz varies based on AP model and regulatory domain. Dashboard will consider any channel that the AP is certified for in the regulatory domain of operation. A list of channels can be viewed by opening the channel dropdown for the AP on the radio settings page. There is no preference for a particular band and all channels are weighted evenly.
Some use cases may require that DFS channels are excluded from the Auto Channel algorithm. DFS channels can be allowed or excluded on the radio settings page in Dashboard.
Since DFS channels can only be used until radar communication is heard, disabling DFS may be useful if the wireless network is in close proximity to a harbor, airport or weather radar station. Administrators may also want to disable DFS if most local wireless clients do not support DFS channels.
Many helicopters have radar systems that can trigger DFS events on wireless networks which would result in channel changes. Hospitals and other mission critical locations that may have a helipad should consider excluding DFS channels.
Dashboard offers the ability to set a default channel width, which will be factored into the Auto Channel algorithm for 5GHz. This can be left at auto width which will adjust the width of the 5Ghz radio based on the Auto Channel algorithms discussed below. A default setting of 80 MHz width can be configured to allow for optimal wireless throughput however may cause more co-channel contention. The setting can be may be reduced to 40 or 20 MHz to reduce channel overlap in high-density deployments. The default channel width can be specified on the radio settings page in Dashboard. The width may be set differently on a per AP basis either using the overrides by clicking on a AP or by opting to use Auto.
Cisco Meraki APs that do not support 80 MHz-wide channels will default to 40 MHz for their channel width.
Newer Cisco Meraki APs with a dedicated scanning radio are able to use the real-time Auto Channel algorithm. Since these APs have full visibility into RF conditions on all channels, the AP and Dashboard are able to make fast channel planning decisions in high-density RF environments.
Cisco Meraki APs are constantly collecting information from the RF environment; the dedicated scanning radio continually monitors on all channels for Air Marshal and RF. The table below outlines in detail the metrics that are collected by each AP and analyzed by the Cloud Controller for the Real-Time Auto Channel algorithm:
|Usage Demand||Commonly some APs handle a greater load than other APs in the same network. APs within the dashboard network are monitored for their usage demand. Client count and traffic are calculated to weigh the "value" of one AP vs another. This metric helps ensure the cleanest channels are used in the most demanding areas.|
|Airtime Availability|| |
Every access point measures contention and airtime availability for each channel and bandwidth combination. This metric maximizes available airtime for the BSS which also minimizes contention and improves performance and roaming.
Meraki APs within the dashboard and out-of-network APs are considered in this metric. Meraki APs within the dashboard network are weighted higher to optimize roaming and airtime usage distribution. Rather than just counting and considering the number of overlapping networks, this metric ensures that the AP will coexist on a channel and have ample airtime availability.
|Channel Utilization||Channel Utilization includes both 802.11 and non-802.11 sources of utilization. External sources of interference like microwaves and DAS systems are detected by this metric and can be seen on the RF spectrum page.|
*A BSSID is a unique identifier for each 802.11 Access point and is made up of the radio's MAC address. Each SSID that a AP transmits has a different BSSID and in most cases a unique virtual MAC is used that is based on the hard coded radio MAC. BSSIDs are discovered by the Meraki Access point by both passive scanning and active probing on each channel.
Channel adjustments are made by Dashboard using information reported by the deployed APs. Dashboard will instruct a AP to change to a different channel for a number of reasons, outlined below:
Dashboard will adjust the channel on a new AP that is best optimized for the location that the AP is installed automatically. Dashboard will collect information from the newly added AP and select the channel that best fits within the existing wireless network.
Adding a new AP will not cause neighboring APs to change channels immediately. Neighboring APs will adjust their channels based on the other reasons outlined below.
The event log will report this type of channel change as "Channel set for new AP". This event will include the radio number, old channel, and new channel. Below is a example of one of these events:
Pressing the Update Auto Channels button on the radio settings page in Dashboard will force a one-time optimization of channels used by all APs within the Dashboard network. This will usually result in a minute or two of downtime as the APs adjust their channel.
The event log will report this type of channel change as "Auto Channel Update". The event will include the radio number, old channel, and new channel. Below is a example of one of these events:
A new source of interference can cause a channel to become unusable. If one of the AP's radios becomes unusable for clients due to interference, Dashboard will instruct the AP to change its channel to another channel with better RF metrics as outlined above.
Dashboard detects a Jammed channel by analyzing utilization. If the non-802.11 utilization on one of the client serving radios is 65% or greater for 1 min, Dashboard will instruct the AP to change to a different channel. The utilization that is analyzed is non-802.11 interference that would be transmitted by a microwave or wireless video camera.
Clients that are on the AP during the channel switch will be instructed to move with the AP to a new channel via a channel switch announcement which will maintain their connection. Clients that do not hear the CSA over the interference will reassociate with an AP (either the original AP or roam to another one).
The event log will report this type of channel change as "Channel changed to avoid jammed channel". This event will include the radio number, old channel, and new channel. Below is a example of one of these events:
The most common reason for a channel change is the steady state process. The Cloud Controller runs this process every 15 minutes. If there is a channel with a better metric when the steady state process runs, the AP will be instructed to change its channel.
The steady state algorithm is client-aware, and the AP will not change the radio channel if there is active client traffic on a radio. This prevents clients from being disconnected or having their applications disrupted when adjusting the channel. Radios may still change their channel as a result of one of other reasons discussed in this document. The AP's radio will resume steady stage changes once the connected clients change channels or access points.
APs will use channel switch announcements to move clients from one 20Mhz or 40Mhz channel to another. Our tests have found that moving from one 80Mhz channel to another can cause interruptions and thus we do not change from an 80Mhz channel if clients are connected.
CSA for Auto Channel is available in beta firmware, please contact support if you would like to opt-in for this feature.
The steady state algorithm is mesh aware and will not adjust the channel of a AP's radio that is serving mesh repeaters. Radios on an AP that are acting as a gateway for an active mesh repeater will not change channels. The process of a radio changing its channel results in a few seconds of downtime, and dropping a mesh link could result in packet loss. The AP's radio will resume steady stage changes if the mesh topology recalculates the route or will change its channel as a result of one of other reasons discussed in this document.
Changing to a DFS channel requires a CAC backoff which prevents client transmissions for 60 seconds. While clients are connected, only non-DFS channels are considered. However, once clients disconnect from the AP a DFS channel may be reconsidered.
The event log will report this type of channel change as "Channel changed to minimize network interference". This type of event will include the radio number, old channel, and new channel. Below is a example of one of these reports:
Cisco Meraki APs that do not have a dedicated 3rd radio (or APs whose 3rd radio is disabled due to power restrictions) will use the Opportunistic Auto Channel algorithm. This algorithm uses similar metrics to the real time auto channel covered above. The data is collected via opportunistic scanning which is scheduled for every 2 hours will scan off channel if clients are not connected. Since information is collected over a longer time period and the limited real-time visibility to other channels, the frequency of channel changes is much more conservative.
Channel changes are more conservative/less frequent because the AP needs to make more assumptions on the channel quality when comparing it to the real time algorithm. There are three main cases that a channel will be changed with the Opportunistic Auto Channel:
Steady state channel changes will only occur at night, during low network usage. Administrators are able to force a scan with the opportunistic auto channel algorithm by pressing the Update Auto Channel button on the radio settings page in Dashboard.
Dashboard will report when AutoRF changes the channel of an access point in the Event Log, and will show the current status on the radio settings page.
Using the Event Log's built in filtering, you can filter on only AutoRF events and drill down to a particular Access Point. The different types of log messages are outlined above.
The radio settings page will show the current status of Auto Channel via both a list view and a map view.
The Map View of the radio settings page will report the current channel within the AP marker. An administrator can toggle between 2.4Ghz and 5Ghz to change the radio is reported within the map. Using the map toggles in the top right of the map area and administrator can toggle between different floor plans and even the satellite and map view of Google maps.
The List view will report the current operating channel for each AP. An administrator can toggle between 2.4Ghz and 5Ghz to change which radio is being reported within the list. "(Auto)" next to the reported channel will indicate if the AP is participating Auto Channel.