A class 5 switch is a hugely important piece of network equipment – providing phone services, including 911 calls to thousands of homes, businesses, hospitals and governments. So any time you need to replace the switch – and migrate service to a new platform – you need to plan and execute the switch migration carefully to minimize service impact.
This article won’t attempt to explain all the details of the switch migration process – instead we’ll give an overview of the key steps so you can talk knowledgeably about the topic with vendors, consultants and other interested parties.
Goal: Minimal service impact
Most service providers have two goals for a class 5 switch migration.
- Move all traffic onto the new switch, so the old platform can be decommissioned.
- Do this with as little service impact and as little risk as possible.
The process described below is designed with this second goal in mind – to minimize the risk of an outage or service interruption.
Example switch with SS7 links, ISUP trunks and subscribers
For the purposes of our example, we’re going to assume a fairly traditional class 5 switch migration, where the network consists of SS7 A-links to a pair of STPs, multiple ISUP trunk groups to different tandems and end-offices, and then subscribers connected to the class 5 switch via a variety of technologies (e.g. SIP, GR-303, MGCP/NCS, PRI, H.248).
Given this network, and given our goal of minimizing risk, we can come up with some intermediate goals.
- We want to be able to move subscribers one-by-one, or in small groups – which means we need both switches to support active subscribers simultaneously.
- We want to be able to move PSTN trunks one-by-one. This means that service is always available on every trunk group (just at a reduced capacity during the cut).
Vendors often have a couple of other goals, which also influence the typical process that’s followed:
- do the complicated part of the project first – to free up the professional services engineers as soon as possible.
- don’t rely on outside expertise – because no vendor wants to be asking their competitor for help to replace their switch.
Class 5 switch migration process
Based on those goals, the standard switch migration process consists of the following key steps.
Move the SS7 links to the new switch
The SS7 links contain the signaling (call set up, and call tear-down) messages for calls over ISUP trunks – but the media flows over the trunks themselves.
In order for this cut to work, the new switch needs to be pre-configured with the point-code of the old switch, so that the STPs don’t know anything has changed.
But then the new switch also needs to be configured to pass the signaling messages through to the old switch, and to emulate the STPs, so that the old switch is ALSO unaware that anything changed.
This idea – sharing a point-code between two switches – is known as point-code proxy.
Move the ISUP trunks one-by-one
Once the SS7 signaling flows through the new switch, you can configure the new switch to proxy calls on some trunks through to the old switch, but to handle some calls locally.
In other words, you can move the ISUP trunks (with the actual voice channels) over to the new switch one-by-one – by updating the proxy configuration. This allows you to cut the trunks without ever disrupting service to more than one T1 at a time.
You do however need to configure the new switch as a tandem to route calls over some IMTs to the old switch, since the subscribers are still hosted there.
Move the subscribers one-by-one
Once the trunk cut is complete, all voice traffic is passing through the new switch, which is tandeming all the calls over to the subscribers on the old switch.
At this point you can move an individual subscriber from the old to the new switch, and the new switch can intercept incoming calls for that subscriber before they are sent to the old switch.
Continue this process until there are no subscribers left on the old switch.
Flip the power switch
And finally, the day you’ve all been waiting for – when you get to turn off that old system and save a ton of money on your power bill.
Sadly, it’s much more complicated than that
Anyone who has worked closely on a migration will immediately recognize that I’ve skipped a bunch of details. I haven’t covered TCAP services, or the complexity of the point-code-proxy configuration, or how to build translations in the new switch, or how to update the old switch to use the IMTs, or how to migrate a subscriber’s data between systems…
Maybe one day I’ll finally write the ultimate guide to a class 5 switch migration – but that’s going to be a much longer document than this one!
So yes, in reality, the process is a lot more complicated than I’ve described, but it’s still helpful to keep these key stages in mind. These are the core phases of the migration, and knowing these core phases will help you to understand why we approach things the way we do, and where the details fit into the big picture.
If you find yourselves considering a migration (to/from a Metaswitch*), or perhaps you want to consolidate two switches within your network, then feel free to reach out. We’d be happy to help plan, oversee or execute the process – whatever makes most sense for your situation.
———————
*Personally, I’m not sure why anyone would ever want to move away from a Metaswitch… but I guess it’s possible.
