Migrating to 6GHz – Cisco Blogs

With greater than 18 billion units in use and 4.2 billion extra to be transport in 2022, the sheer measurement of current Wi-Fi deployments worldwide is simply mind-boggling. In view of the brand new Wi-Fi 6E and 6GHz adoption push, it’s vital to judge what are the most effective methods to do a migration from current Cisco on-prem legacy networks into the brand new world of 6GHz deployments.

For Cisco Enterprise clients, there are a number of elements that should be evaluated for any profitable migration planning:

• Current controller sort:

  • is it AireOS?
  • Mannequin? (Principally, can it  run 8.5 or 8.10?)
  • is it IRCM succesful (2504/wism2 can’t do mobility to 9800)

• Entry level Stock:

  • Are there any 802.11n fashions nonetheless in use? (per instance, 2600, 3600, 1520, 1600, and so on)
  • Are there any Wave1 APs? (final era of IOS, per instance 1700, 2700, 3700)
  • Mesh deployments?

• PoE assist:

  • What’s the most supported energy normal? (802.3bt, 802.3at, and so on)
  • Any energy budged constraints per port?
  • Or APs are powered by energy injectors?

• Present 5GHz TX energy

  • Is my community working on common at energy stage 3-4?
  • or it’s round 1-2?

6GHz adoption is just supported within the Catalyst 9800 IOS-XE controllers, working 17.7 or increased. This imposes some further concerns both on controller sort migration, or about legacy entry factors which will must both be migrated, or supported by means of Inter Launch Controller Mobility (IRCM) options

Legacy Entry Factors

Over time, it has at all times been attainable to do co-existence of earlier generations of entry factors with the newly launched fashions, guaranteeing each clean community upgrades and capability enlargement. Including new APs is often not a problem till we hit the situation of inter-generation gaps.

If a community that for any purpose remains to be working units 2 generations away (for instance, a 2602 AP), and now wants to incorporate new 802.11ax fashions (for instance 9130)  or leap to the  9136  for 6GHz assist, this can want extra complicated migration paths, than merely including entry factors.

When there are a number of era gaps, if the legacy controllers can assist IRCM to the IOS-XE 9800,  it’s completely attainable to design a migration plan, with out the necessity to do a “forklift” set up.  This can guarantee little or no ache to customers, and hold the community working till every thing is migrated to the brand new {hardware} and requirements

Within the following desk, we are able to see a abstract of software program assist ranges and migration choices for many entry factors fashions from 11n era fashions:

For an entire listing, you possibly can examine the Cisco Wi-fi Options Software program Compatibility Matrix, alternatively, you possibly can run the Wi-fi Config Analyzer Categorical, to examine your migration readiness

Legacy Controllers

Relying on the present controller sort, the migration could take completely different paths. Some eventualities will probably be easy, permitting a clean transition. Others might have further steps to efficiently migrate right into a Wi-Fi 6E community

What to anticipate:

• “Technology 1” controllers: 5508, 8510. They’ll assist as much as 8.5 AireOS model, which is able to permit mobility eventualities between them and new IOS-XE 9800 controllers (Inter-release Controller Mobility, IRCM assist).  Additionally, they’ll assist  each IOS and AP-COS entry factors, from 1700 to 3800 fashions (Wave1, Wave2 802.11ac )
• “Technology 2” controllers: 5520, 8540, 3504 . All of those can assist as much as 8.10 AireOS, additionally permitting IRCM eventualities with 9800. AP assist will moreover embrace 802.11ax fashions, like the brand new Catalyst 9105, 9120, and 9130. and so on.
• “Technology 1” controllers with out IRCM: 2504, WiSM2, vWLC, 7510. No mobility is feasible between them and IOS-XE, so further steps with completely different migration eventualities are wanted

Migration Eventualities

On the whole, we must always attempt to migrate “per RF blocks”, defining it as a roaming space or area the place shoppers can transfer usually between entry factors, earlier than hitting idle timeout. Principally, transfer these RF blocks fully, into the brand new APs, and IOS-XE controllers. For instance, both transfer a constructing or a whole flooring into the brand new {hardware} and software program.  We should always keep away from “salt & pepper” deployments, mixing APs on completely different controllers on the similar time. Not as a result of it’s not supported, however as a result of mobility will probably be extra complicated, and it might result in points ultimately (only a downside prevention motion)

For eventualities the place it’s not possible to interrupt the RF surroundings into differentiated blocks (for instance a really giant constructing like an airport, or a completely open area workplace), we should both arrange synthetic boundaries primarily based on roaming frequency and utilization or do a forklift improve

What occurs if the AP mannequin isn’t supported in any IRCM model?

This could possibly be the situation of a legacy controller, nonetheless working in 8.3, with some AP fashions that aren’t supported past that model. For instance, the situation of 20 APs of 2700 Sequence, and 10 APs of 1042 Sequence.

The 1040s aren’t supported in 8.5. On this case, the popular choice is to prioritize the alternative of these APs first, shifting the impacted space into 9800 as step one. Typically, clients have blended fashions throughout a given constructing. For instance, the combination of 2700 and 2600. In these eventualities, the best choice is to consolidate fashions per supported model, shifting all APs of a given sort collectively, so they’re contained in a particular RF area  with a view to facilitate migration in blocks

State of affairs 1: Legacy Controller helps IRCM

This would be the most typical situation, the place we now have both 8.5  (5508/8510) or 8.10 (5520/3504/8540) AireOS controller.  The migration image will begin with the creation of  IRCM setup between AireOS and 9800 controllers, then both exchange APs in RF areas connecting them to the brand new controller, permitting mobility to behave when a shopper must roam between legacy and new RF areas.

This technique permits the graceful coexistence of each controllers, with RF areas migrated as wanted, with none in a single day switchover.

Issues to remember:

• If the controller is proscribed to eight.5 (5508, 8510), we are going to want a particular IRCM model (8.5.182.104), to attach them to IOS-XE
• On the whole, it’s best to separate the RF community into completely different areas, configuring completely different RF group names between the legacy and IOS-XE controllers. This fashion every group can do the most effective calculations that their respective model permits. We should always be sure that “Keep away from International AP Interference” is enabled on RRM/DCA configuration (it’s by default)
• At all times configure the first/secondary controller title in entry factors. The brand new controllers will reject unsupported APs, but when any AP may work in each controller varieties, this can keep away from APs becoming a member of the incorrect one, or flip-flopping between them, till the migration is able to proceed

State of affairs 2: Legacy Controller not supporting IRCM

If the legacy community is working on a controller mannequin WiSM2, 2504, 7510, vWLC, it’s not attainable to determine an IRCM connection between the previous controller to the brand new 9800 dealing with the 6E APs. This limits considerably the choices which might be out there, and it forces a extra aggressive migration course of

Migration options:

• Preserve the 2 networks separated, and migrate bodily RF areas as new APs are added, changing the previous ones. No roaming is feasible, and it is extremely vital to maintain shopper VLANs completely different between controllers, to keep away from ARP proxy points between each controllers. Throughout this course of, we should take care on stopping roaming occasions as shopper id, handle, and so on, will probably be misplaced on the change between controller varieties.  For instance, the best situation is to maneuver a whole constructing from one controller to the brand new one, doing a forklift AP alternative in a single day.
• Keep away from migrations “per flooring”, as in most constructing varieties, it’s regular to see shoppers roaming between APs on completely different flooring
• Quickly, exchange the legacy controller with one which helps IRCM

State of affairs 3: AP is supported as much as 17.3 however not in later variations

This can occur when “Wave1” APs are nonetheless current, for instance, 1700/2700/3700 AP fashions. For any such migration, it’s attainable to maneuver all APs into IOS-XE, with the 17.3 launch, then add a secondary wlc to host the brand new Wi-Fi 6E APs, utilizing 17.9, and set up an IRCM hyperlink between each controllers.

On this feature, it’s attainable to do a sleek AP alternative from Wave1, into Wi-Fi 6E fashions, at all times attempting to do the know-how migration, per bodily roaming RF space as described (per constructing, flooring, and so on). As soon as all APs are migrated, the 17.3 controllers might be decommissioned

In some situations, the shopper could deploy a 9800-CL in 17.3 as a short lived controller to host the legacy APs

6GHz RF Protection vs 5GHz. AP alternative eventualities

One widespread dialogue level is: How completely different goes to be the cell protection, in 6GHz, when in comparison with a 5GHz AP?

Individuals will need to take a 5GHz AP and do a 1:1 alternative with a 6GHz supported AP, this may increasingly appear cheap, however there are some elements to contemplate:

• As WiFi-6E makes use of a better frequency, the propagation traits are completely different, the sign drops barely sooner in 6 than in 5GHz. The distinction ought to be round 2 dBm on measurements over the identical distance. Materials absorption will probably be completely different as nicely.
• 6GHz has completely different regulatory energy constraints than 5GHz. At the moment, most deployments will probably be utilizing Low Energy APs (for simplicity sake’s, let’s say 24dBm in FCC, 23 dBm in ETSI). Which means relying on the present community AP radio’s energy ranges,  utilizing 6GHz could lead to a barely decrease energy output

Rule of thumb:

• In case your energy stage common is round 3-4, it’s attainable to do a 1:1 AP alternative, and have the same protection stage in 5 and 6 GHz
• If the ability stage is in 1-2, then it’s possible you’ll want round 10 to twenty% further entry factors

The best option to know the common energy stage per web site is to make use of WCAE software and examine the “Channel Stats 5GHz” tab. This can current a abstract per channel, both at controller, or web site tag stage, of the common energy ranges (amongst different data).  For instance, this can be a community the place migration to 6GHz might have further entry factors:

Versus this different one, the place the deployment is working on low energy, so becoming with out points into 6GHz necessities:

Should you use the most recent model (0.9.11) of WCAE, it’s also possible to get a “6GHz predictive” view of how the ability distribution, Close by relationships, and RSSI for shoppers would look, in the event you changed your present APs with 6GHz succesful {hardware}. The software will match ETSI or FCC regulatory necessities, adapting powers and variations as wanted. That is helpful to get a style of how the community would look, doing a direct migration, with out including any APs.

For complicated or demanding deployment eventualities, the advice will at all times be: do a web site survey

For normal data on Wi-Fi 6E merchandise

Extra Sources

For 6GHz troubleshooting and modeling software go to WCAE