Private 5G Network Management Software Problems: The 7 That Stop a Shift, and How to Avoid Them

Why does the scope get set around radio dashboards so often?

Because the people in the room when private cellular is scoped are network people, and network people can see what is missing from a network point of view. So the requirement becomes better visibility of reference signal power, interference and resource block utilisation, and a project gets funded to build a nicer version of what the network management system already shows.

That is not the gap. Celona, Athonet, Nokia Digital Automation Cloud and Druid Raemis already deliver credible platforms with real service quality visibility, and Celona in particular has put serious effort into making it intelligible. Building another view of the same metrics duplicates work somebody has done better.

The gap is that none of those platforms know your site, and none of them can. They cannot know that aisle seven is the one that matters because that is where the autonomous vehicles turn, or that gate lane cameras must not drop between six and eight because that is peak inbound, or that the crane on berth three carries a contractual availability target. Their alerts are correct and severity is defined by network impact rather than by production impact.

Scope the operations layer instead: the registry, the site model, onboarding and decommissioning, policy by device class, and assurance expressed in plant vocabulary. That is the $95,000 to $210,000, fourteen to twenty week first release in our delivery experience, and none of it competes with your platform vendor.

What goes wrong when the device inventory and asset register are reconciled?

You find out how far apart they already are, and it is usually further than anyone in the meeting expects.

The core knows subscribers by international mobile subscriber identity. The plant knows equipment by fleet number, by department, by whoever signed for it. Those lists are maintained by different teams for different reasons and they start diverging within a month of go live. By the time an operations layer is being built, there are active SIMs with no matching asset, assets with two SIMs recorded against them because one was replaced and never removed, and devices issued to a department that no longer exists after a reorganisation.

The failure is treating reconciliation as a data cleanse to be finished before the system goes live. It never finishes, because new discrepancies arrive weekly through workshops, replacements and transfers.

What works is making the mismatch a permanent, owned exception queue rather than a one time project. A device active in the core with no matching asset record is an item somebody works, not a row in a report. Ask any prospective developer what their system does with that case, because the answer separates a registry from a spreadsheet with a login. Then get the label printing right, because a physical label tying the asset to the record is what keeps the two aligned in the field where the reconciliation actually happens.

Why do the core provisioning and session data integrations break after launch?

Three ways, and the third is the one that hurts.

The first is version drift. A core platform upgrade changes a provisioning interface or a session record field, and the operations layer keeps running against the old assumption. Contract tests that assert the shape of every interface, run on a schedule rather than only at build time, catch this in a day instead of a quarter.

The second is volume. Session data at a site with a few hundred devices is manageable. The same feed at a site with thousands of sensors is a different engineering problem, and a design that worked in pilot starts dropping records or falling behind. Size for the device population you will have in two years, not the one in the pilot.

The third is multi vendor drift across sites. It happens more often than anyone plans, usually because a second site was procured separately or an acquisition arrived with its own deployment. Now you have two cores with two provisioning models and two session record formats, and an operations layer written against one of them. Build the integration behind an internal interface from the first site even when there is only one core, so the second vendor is an adapter rather than a rewrite. That decision costs almost nothing in week two and saves a project in year two.

What happens when decommissioning, spectrum records and the safety boundary are not covered?

These three get cut from scope together, because all three are about what happens after the exciting part.

Decommissioning is the half everyone skips. Onboarding gets a workflow because somebody is waiting for a device. Nothing is waiting when a vehicle goes to the workshop or a handheld is retired, so the SIM stays active, the policy stays applied, and your device count drifts upward forever. Build it as the mirror of onboarding with the same approvals, and add a periodic review that flags SIMs with no session activity over a defined period.

Spectrum and radio estate records fail quietly. Depending on your market the arrangement may be shared spectrum with an automated coordination service, locally licensed spectrum, or leased operator spectrum, and each carries obligations around registered installation details, antenna heights, power levels and coordination status. Those details live with the integrator in a design document and an email thread. When a radio moves during a yard reconfiguration, reality and record separate, and the first check is an audit or an interference complaint.

The safety boundary is the one to raise before a developer does. Any operations layer at a site with safety functions needs an explicit written statement of what it can and cannot influence, and if network state feeds anything with a safety function the verification burden rises substantially. A developer who does not raise that unprompted is one to be careful with.

Should you build custom or configure what you already own?

Stay with your platform and integrator if you have one site, a stable device population in the low hundreds, and a managed service contract where the integrator genuinely answers the phone at 5:50am. That is a legitimate arrangement, buying an operations layer would be premature, and you should spend the money on coverage instead.

Keep the platform either way. Celona, Nokia Digital Automation Cloud, Athonet and Druid Raemis are doing the hard radio and core work, and Betacom and Federated Wireless are credible on the managed service and spectrum side. An operations layer reads from them and sits above them. Nothing here argues for replacing a working core.

Start building once two of these describe your site. Private cellular carries production or safety critical traffic and an outage stops work. More than one device class with genuinely different requirements shares a single flat policy. You are rolling out to a second or third site. Your device registry and your asset register disagree. Operations cannot interpret the network alerts they get, so they escalate instead of acting. Or you cannot report network performance in the terms your business case was written in.

The tipping point is the second site or the first production stoppage attributed to connectivity, whichever comes first. At that moment you stop being a network project and start being an operator, and operators need a back office.

How do hidden costs get into the quote?

Site count is the first, and it is priced as replication when it is often not. Different cores or radio vendors between sites mean different adapters, and different site layouts mean the zone modelling workshop repeats with different people.

Operational technology integration is the second and the largest. A terminal operating system, a mine dispatch system and a manufacturing execution system each have their own integration realities and, more importantly, their own change windows. You cannot deploy against them whenever you like, so calendar time is set by their release cycles rather than by your sprint length.

Safety related requirements are the third, because verification burden rises steeply the moment network state touches anything with a safety function. Automated remediation is the fourth, since closing the loop means the system is allowed to change the network, and that needs control design, approval paths and rollback rather than a feature flag.

The fifth is the workshop time itself. Naming zones the way people actually talk about them takes operations staff off their jobs, and a quote that assumes their availability without having asked is a schedule risk wearing a fixed price.

What separates a build that works from one that fails here?

The successful builds start with the registry and the site model on one site, and neither requires touching network configuration. Almost every later capability depends on knowing which device is which asset and where the named zones are, so getting those two right first makes everything downstream cheap. Builds that start with assurance dashboards produce another screen nobody acts on.

The second marker is whether alerts read in plant vocabulary. Degraded session quality in north stack affecting stevedoring handhelds, twenty minutes before shift change, is actionable by a supervisor at 5:50am. A resource block utilisation figure is not, however accurate it is. Ask to see a sample alert written the way it will actually appear.

The third is whether policy is a property of the device class in the registry rather than a network configuration. That moves the decision to operations, who know which devices are production critical, and it lets the system detect drift by comparing intended policy against what the core is actually enforcing.

Then the questions that separate private cellular experience from enterprise networking experience. Ask which core platforms they have integrated with by name and which interfaces they used for subscriber provisioning and session data. Ask how they would map a cell to a physical zone, and listen for whether they ask about survey data and how the plant names its own areas rather than reaching for coordinates. Ask how they keep the system out of the safety path. And settle ownership of the code, the repository, the infrastructure accounts and the site model in writing before kickoff, because that model is operational knowledge about your own facility.