Migrating to 6GHz

With more than 18 billion devices in use and 4.2 billion more to be shipping in 2022, the sheer size of existing Wi-Fi deployments worldwide is just mind-boggling. In view of the new Wi-Fi 6E and 6GHz adoption push, it is critical to evaluate what are the best ways to do a migration from existing Cisco on-prem legacy networks into the new world of 6GHz deployments.

For Cisco Enterprise customers, there are several aspects that need to be evaluated for any successful migration planning:

• Existing controller type:
  • is it AireOS?
  • Model? (Basically, can it  run 8.5 or 8.10?)
  • is it IRCM capable (2504/wism2 can’t do mobility to 9800)
• Access point Inventory:
  • Are there any 802.11n models still in use? (per example, 2600, 3600, 1520, 1600, etc)
  • Are there any Wave1 APs? (last generation of IOS, per example 1700, 2700, 3700)
  • Mesh deployments?
• PoE support:
  • What is the maximum supported power standard? (802.3bt, 802.3at, etc)
  • Any power budged constraints per port?
  • Or APs are powered by power injectors?
• Current 5GHz TX power
  • Is my network running on average at power level 3-4?
  • or it is around 1-2?

6GHz adoption is only supported in the Catalyst 9800 IOS-XE controllers, running 17.7 or higher. This imposes some additional considerations either on controller type migration, or about legacy access points that may need to either be migrated, or supported through Inter Release Controller Mobility (IRCM) solutions

Legacy Access Points

Over the years, it has always been possible to do co-existence of previous generations of access points with the newly introduced models, ensuring both smooth network upgrades and capacity expansion. Adding new APs is normally not an issue until we hit the scenario of inter-generation gaps.

If a network that for any reason is still running devices 2 generations away (for example, a 2602 AP), and now needs to include new 802.11ax models (for example 9130) or jump to the  9136/9166/9164  for 6GHz support, this will need more complex migration paths.

When there are multiple generation gaps, if the legacy controllers can support IRCM to the IOS-XE 9800,  it is perfectly possible to design a migration plan, without the need to do a “forklift” installation.  This will ensure very little pain to users, and keep the network running until everything is migrated to the new hardware and standards

In the following table, we can see a summary of software support ranges and migration options for most access points models from 11n generation models:

 

Model/Series	Last AireOS Support	IOS-XE support	IOS-XE AP equivalent	Migration Notes
700/700W Series	8.10	Not supported	9105	Migration through IRCM
1040	8.3	Not supported	9115	AP needs to be replaced
1260	8.3	Not supported	9115	AP needs to be replaced
1600	8.5	Not supported	9115	Either 8.5 IRCM, or Hardware replaced
1700	8.10	17.3	9115	Migration through IRCM
2700	8.10	17.3	9120	Migration through IRCM
3700	8.10	17.3	9130	Migration through IRCM
1810/1810W	8.10	Up to 17.3	9105	Hardware replaced or IRCM between IOS-XE versions
1830/1840/1850	8.10	Supported	9105	Directly supported
AP802/AP802H	8.5	Not Supported	ISR10xx	Migration through IRCM
2600	8.5	Not Supported	9120	Migration through IRCM
2800/3800/4800	8.10	Supported		Directly supported
1540	8.10	Supported		Directly supported
1550	8.5	Not supported		Migration through IRCM
1560	8.10	Supported		Directly supported
1570	8.10	Up to 17.3		Migration through IRCM

For a complete list, you can check the Cisco Wireless Solutions Software Compatibility Matrix, alternatively, you can run the Wireless Config Analyzer Express, to check your migration readiness

 

Legacy Controllers

Depending on the existing controller type, the migration may take different paths. Some scenarios will be simple, allowing a smooth transition. Others may need additional steps to successfully migrate into a Wi-Fi 6E network

What to expect:

• “Generation 1” controllers: 5508, 8510. They can support up to 8.5 AireOS version, which will allow mobility scenarios between them and new IOS-XE 9800 controllers (Inter-release Controller Mobility, IRCM support).  Also, they will support  both IOS and AP-COS access points, from 1700 to 3800 models (Wave1, Wave2 802.11ac )
• “Generation 2” controllers: 5520, 8540, 3504 . All of these can support up to 8.10 AireOS, also allowing IRCM scenarios with 9800. AP support will additionally include 802.11ax models, like the new Catalyst 9105, 9120, and 9130. etc.
• “Generation 1” controllers without IRCM: 2504, WiSM2, vWLC, 7510. No mobility is possible between them and IOS-XE, so additional steps with different migration scenarios are needed

 

Migration Scenarios

In general, we should try to migrate “per RF blocks”, defining it as a roaming area or domain where clients can move normally between access points, before hitting idle timeout. Basically, move these RF blocks completely, into the new APs, and IOS-XE controllers. For example, either move a building or a complete floor into the new hardware and software.  We should avoid “salt & pepper” deployments, mixing APs on different controllers at the same time. Not because it is not supported, but because mobility will be more complex, and it may lead to issues sooner or later (just a problem prevention action)

For scenarios where it is impossible to break the RF environment into differentiated blocks (for example a very large building like an airport, or a fully open space office), we will have to either set up artificial boundaries based on roaming frequency and usage or do a forklift upgrade

What happens if the AP model is not supported in any IRCM version?

This could be the scenario of a legacy controller, still working in 8.3, with some AP models that are not supported beyond that version. For example, the scenario of 20 APs of 2700 Series, and 10 APs of 1042 Series.

The 1040s are not supported in 8.5. In this case, the preferred option is to prioritize the replacement of those APs first, moving the impacted area into 9800 as the first step. Sometimes, customers have mixed models across a given building. For example, the mix of 2700 and 2600. In those scenarios, the best option is to consolidate models per supported version, moving all APs of a given type together, so they are contained in a specific RF space  in order to facilitate migration in blocks

Scenario 1: Legacy Controller supports IRCM

This will be the most common scenario, where we have either 8.5  (5508/8510) or 8.10 (5520/3504/8540) AireOS controller.  The migration picture will start with the creation of  IRCM setup between AireOS and 9800 controllers, then either replace APs in RF areas connecting them to the new controller, allowing mobility to act when a client needs to roam between legacy and new RF areas.

This method allows the smooth coexistence of both controllers, with RF areas migrated as needed, without any overnight switchover.

Things to keep in mind:

• If the controller is limited to 8.5 (5508, 8510), we will need a special IRCM version (8.5.182.104), to connect them to IOS-XE
• In general, it is best to split the RF network into different areas, configuring different RF group names between the legacy and IOS-XE controllers. This way each group can do the best calculations that their respective version allows. We should make sure that “Avoid Foreign AP Interference” is enabled on RRM/DCA configuration (it is by default)
• Always configure the primary/secondary controller name in access points. The new controllers will reject unsupported APs, but if any AP could work in both controller types, this will avoid APs joining the wrong one, or flip-flopping between them, until the migration is ready to proceed

Scenario 2: Legacy Controller not supporting IRCM

If the legacy network is running on a controller model WiSM2, 2504, 7510, vWLC, it is not possible to establish an IRCM connection between the old controller to the new 9800 handling the 6E APs. This limits significantly the options that are available, and it forces a more aggressive migration process

Migration alternatives:

• Keep the two networks separated, and migrate physical RF areas as new APs are added, replacing the old ones. No roaming is possible, and it is very important to keep client VLANs different between controllers, to avoid ARP proxy issues between both controllers. During this process, we must take care on preventing roaming events as client identity, address, etc, will be lost on the change between controller types.  For example, the ideal scenario is to move a complete building from one controller to the new one, doing a forklift AP replacement overnight.
• Avoid migrations “per floor”, as in most building types, it is normal to see clients roaming between APs on different floors
• Temporarily, replace the legacy controller with one that supports IRCM

Scenario 3: AP is supported up to 17.3 but not in later versions

This will happen when “Wave1” APs are still present, for example, 1700/2700/3700 AP models. For this type of migration, it is possible to move all APs into IOS-XE, with the 17.3 release, then add a secondary wlc to host the new Wi-Fi 6E APs, using 17.9, and establish an IRCM link between both controllers.

On this option, it is possible to do a graceful AP replacement from Wave1, into Wi-Fi 6E models, always trying to do the technology migration, per physical roaming RF area as described (per building, floor, etc). Once all APs are migrated, the 17.3 controllers can be decommissioned

In some instances, the customer may deploy a 9800-CL in 17.3 as a temporary controller to host the legacy APs

6GHz RF Coverage vs 5GHz. AP replacement scenarios

One common discussion point is: How different is going to be the cell coverage, in 6GHz, when compared to a 5GHz AP?

People will want to take a 5GHz AP and do a 1:1 replacement with a 6GHz supported AP, this may seem reasonable, but there are some aspects to consider:

• As WiFi-6E uses a higher frequency, the propagation characteristics are different, the signal drops slightly faster in 6 than in 5GHz. The difference should be around 2 dBm on measurements over the same distance. Material absorption will be different as well.
• 6GHz has different regulatory power constraints than 5GHz. Currently, most deployments will be using Low Power APs (for simplicity sake’s, let’s say 24dBm in FCC, 23 dBm in ETSI). This means that depending on the current network AP radio’s power levels,  using 6GHz may result in a slightly lower power output

Rule of thumb:

• If your power level average is around 3-4, it is possible to do a 1:1 AP replacement, and have a similar coverage level in 5 and 6 GHz
• If the power level is in 1-2, then you may need around 10 to 20% additional access points

The easiest way to know the average power level per site is to use WCAE tool and check the “Channel Stats 5GHz” tab. This will present a summary per channel, either at controller, or site tag level, of the average power levels (among other information).  For example, this is a network where migration to 6GHz may need additional access points:

 

Versus this other one, where the deployment is running on low power, so fitting without issues into 6GHz requirements:

 

If you use the latest version (0.9.11) of WCAE, you can also get a “6GHz predictive” view of how the power distribution, Nearby relationships, and RSSI for clients would look, if you replaced your current APs with 6GHz capable hardware. The tool will match ETSI or FCC regulatory requirements, adapting powers and differences as needed. This is useful to get a taste of how the network would look, doing a direct migration, without adding any APs.

For complex or demanding deployment scenarios, the recommendation will always be: do a site survey

 

For general information on Wi-Fi 6E products

visit Wi-Fi 6E At-a-Glance

 

Additional Resources

For 6GHz troubleshooting and modeling tool visit WCAE