◉ “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
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:
Posts
