The core network is the most critical component of any private cellular deployment. It handles subscriber authentication, session management, policy enforcement, and data routing. Migrating the core — swapping the EPC (for LTE) or 5GC (for 5G NR) — is the highest-stakes part of any private cell migration.
Our approach is built on one principle: the old core and the new core run simultaneously until the cutover is validated. Here's how it works.
Why the Core Is the Hard Part
Replacing radios is relatively straightforward — you can swap an eNodeB and repoint it to a new core in a maintenance window. But the core is different:
- It holds the subscriber database (HSS/UDM) — every IMSI, authentication key, and subscription profile
- It manages active sessions — a mid-session cutover drops every connected device
- It enforces QoS policies, VLAN assignments, and access control rules
- It anchors data traffic — changing the PGW/UPF changes the data path for every device
A naive approach — shut down the old core, bring up the new one — means every device loses connectivity, re-attaches, and re-authenticates. For a logistics yard with 300 scanners or a mine with safety-critical sensors, that's not acceptable.
Parallel Core Operation
Instead of a hard cutover, we deploy the BATS ECHO core alongside your existing system. Both cores are live and fully operational during the transition period:
- ECHO deployment: The BATS ECHO EPC/5GC is installed, configured, and connected to the same network infrastructure (switches, routers, backhaul) as the legacy core.
- Subscriber database sync: We export subscriber profiles (IMSI, Ki/OPc, APN configurations, QoS profiles) from the legacy HSS/UDM and import them into ECHO. Both cores can authenticate the same subscribers.
- Policy migration: Access control lists, VLAN mappings, traffic rules, and QoS classes are recreated in ECHO's policy engine.
- Validation on ECHO: A subset of devices is moved to the new core first — typically test devices or non-critical endpoints. We validate attach, authentication, data throughput, handover, and integration points.
The Cutover
Once ECHO is validated with test devices, the production cutover happens in one of two ways, depending on the network architecture:
RAN repointing: If the radios support S1/N2 flex or multi-MME/AMF configurations, we repoint the eNodeBs/gNodeBs from the legacy core to ECHO. Devices re-attach to the new core on their next tracking area update or idle-to-connected transition — typically within seconds to minutes, with no user-visible disruption.
SIM-based migration: For networks where RAN repointing isn't possible, devices are migrated by reprovisioning SIM profiles to authenticate against the ECHO core. This can be done in batches — shift by shift, building by building — with both cores running until the last device is moved.
In both approaches, the legacy core stays live until every device has been validated on ECHO. If any issue is detected, devices can be rolled back to the legacy core immediately.
What "Zero Downtime" Actually Means
We define zero downtime as: no device experiences a service interruption that impacts the user or application. In practice:
- Devices may briefly detach and re-attach during RAN repointing (sub-second for most devices)
- Active TCP sessions may reset during core transition, but stateless protocols (most IoT, scanning, push-to-talk) recover instantly
- Voice calls in progress would drop if the device re-attaches — we schedule cutovers during low-traffic windows for voice-heavy deployments
For most industrial deployments (scanners, cameras, sensors, AGVs), the transition is invisible. The device re-attaches to the new core, gets the same IP, the same QoS profile, and the same VLAN assignment — and the application never knows the core changed.
Rollback Capability
Because the legacy core remains live during the transition, rollback is straightforward:
- If a device fails to authenticate on ECHO, it falls back to the legacy core
- If a systemic issue is detected (policy misconfiguration, routing error), we repoint the RAN back to the legacy core
- Rollback takes minutes, not hours — it's the same repointing operation in reverse
We don't decommission the legacy core until the new system has been running in production for an agreed validation period — typically 48 hours to two weeks, depending on the criticality of the environment.
What You Need to Provide
For a smooth core cutover, we need:
- Subscriber data export: IMSI, Ki/OPc, APN profiles, and QoS classes from the legacy HSS/UDM. If your vendor won't export this, we have workarounds (SIM swap, fresh provisioning).
- Network access: IP connectivity between ECHO and your radios, switches, and backhaul infrastructure.
- A maintenance window (optional): For voice-heavy deployments, a low-traffic window for the final cutover reduces risk. For data-only networks, cutover can happen any time.
- Stakeholder alignment: Operations, IT, and management should know the cutover is happening and have a communication channel to report issues.
Everything else — deployment, configuration, testing, cutover execution, and validation — is on us.