Private 5G and Private LTE Operations Software: Translating Radio Metrics Into Which Vehicle Dropped, Where, and Whether the Shift Can Start

Why private cellular arrives without the operations layer

A container terminal deploys private LTE across the yard to carry traffic for straddle carriers, handheld terminals, gate cameras and a fleet of maintenance tablets. The core comes from one vendor, the radios from another, the SIMs from a third, and a systems integrator ties it together. Coverage surveys are done. Acceptance testing passes. Everyone shakes hands.

Six weeks later, on a Tuesday at 5:50am, three handhelds in the north stack area cannot attach. The shift starts at six. The terminal has a network management system that shows radio KPIs: reference signal power, interference levels, resource block utilisation per cell. What it does not show is that those three devices belong to the stevedoring team working north stack, that they were fine yesterday, and that a reefer container stack changed height on Monday. The night shift supervisor is looking at a screen full of numbers that mean nothing to him and calling the integrator's support line, which opens at nine.

That is the actual gap in private cellular. The radio side has real vendors with real products. The operations side assumes there is a carrier behind it, and there is not. A mobile operator has decades of back office: device registries, provisioning workflow, care tooling, field operations processes. A port does not, and nobody sold it one, because it was not in the network scope.

Problem 1: nobody knows which device is which asset

The core knows subscribers by IMSI. The plant knows assets by fleet number, by department, by the person who signed for them. Those two lists are maintained separately, usually in a spreadsheet on the IT side and a maintenance system on the operations side, and they diverge within a month of go-live.

The consequence shows up in every incident. Somebody reports a problem with a vehicle, and the first twenty minutes go to establishing which SIM is in it. When a device is retired or a vehicle goes to the workshop, the SIM stays active because nobody told the network. When a new handheld is issued, someone provisions it with whatever policy was last used, because there is no rule that says a stevedoring handheld gets a different treatment from a maintenance tablet.

What a custom build does: one registry where a SIM, a device, an asset and an owning department are the same record. Onboarding becomes a workflow rather than a favour: request, approve, assign policy by device class, provision into the core, record it, and produce a label. Decommissioning is the same in reverse, and it is the half everyone skips. That registry is the foundation, and it is worth building even if you build nothing else.

Problem 2: the platforms report in radio terms and the plant thinks in places

Celona, Athonet, Nokia Digital Automation Cloud and Druid Raemis all deliver credible private cellular platforms, and Celona in particular has put real effort into making service quality intelligible. Betacom and Federated Wireless approach it from the managed service and spectrum side. None of them, and this is not a criticism of their scope, know your site.

They cannot know that aisle 7 in the high bay is the one that matters because that is where the autonomous vehicles turn, or that the gate lane cameras must not drop between 6am and 8am because that is peak inbound, or that the crane on berth 3 is the one with the contractual availability target. Their metrics are correct and their alerts are correctly severe, but they are expressed in a vocabulary the person on shift does not speak, and severity is defined by network impact rather than by production impact.

What a custom build does: put a site model over the network data. Physical zones with names people use, mapped to cells and sectors. Device groups that mirror crews and equipment types. Service expectations expressed per zone and per device class, with time windows that match the shift pattern. Then an alert reads as a degraded session quality in north stack affecting stevedoring handhelds, twenty minutes before shift change. That is actionable by a supervisor. A resource block utilisation figure is not.

Problem 3: SIM and slice policy is set once and never revisited

Private deployments almost always start with a single flat policy because that is the fastest way to get to acceptance. Then more device types arrive: cameras that push heavy uplink, sensors that transmit almost nothing, tablets that someone will use for video calls, vehicle controllers whose latency requirement is the reason the network exists at all. All of them share the same treatment, and the vehicle controllers compete with someone streaming a training video.

Slicing and quality-of-service policy exist to solve this, and the platforms support them. The reason they go unused is that nobody owns the policy decision after go-live. It is a network configuration, so it sits with IT, who do not know which devices are production critical, while operations, who do know, cannot see the configuration.

What a custom build does: make policy a property of the device class in the registry rather than a network configuration. Operations defines what a vehicle controller is and what it needs, the system applies the corresponding slice and policy on provisioning, and any change is a reviewed request with a record. Drift becomes visible, because the system can compare intended policy against what the core is actually enforcing and report the difference.

Problem 4: spectrum and compliance records live in an email thread

Depending on where you deploy, the spectrum arrangement varies: shared spectrum with an automated coordination system in some markets, locally licensed spectrum in others, leased operator spectrum elsewhere. Each carries obligations. Registered installation details, antenna heights and power levels, coordination status, and a record of what was deployed when.

In practice these details live with the integrator, in a design document, in an email thread, and in whatever portal the spectrum coordination service provides. When a radio is moved during a yard reconfiguration, or a new one is added for a building extension, the record and reality separate quietly. The first time anyone checks is usually during an audit or after an interference complaint.

What a custom build does: hold the deployed radio estate as records with location, configuration, coordination status and change history, and require a change record when anything physical moves. This is unexciting and it is exactly the kind of thing that costs real money when it is missing. It also gives you a defensible position if a neighbouring operation raises an interference issue.

Problem 5: nobody can prove the network is meeting its purpose

Private cellular gets funded on a business case: autonomous vehicle uptime, gate throughput, elimination of a wireless technology that kept dropping. After go-live, nobody reports against that case in the terms it was written in. The network team reports availability. The business case was about production.

The two are connected by data you already have. Session records tell you when a specific vehicle controller lost connectivity, for how long, and in which zone. Joined to shift schedules and equipment usage, that becomes minutes of production affected, by area, by cause. That is a report an operations director can act on, and it is what determines whether the second site gets funded.

What a custom build does: connect network events to production context and report in production units. It also gives you the evidence to argue with a vendor about coverage in a specific area, because a claim backed by session data from named devices over ninety days is different from a complaint.

What this costs and how long it takes

Across projects Digital Heroes has delivered, a private cellular operations layer runs $95,000 to $210,000 across 14 to 20 weeks. That covers the unified SIM, device and asset registry, onboarding and decommissioning workflow with approvals, policy and slice assignment by device class, a site model mapping cells to named zones, session and coverage assurance with alerting in plant vocabulary, and reporting against production context. Extending into multi-site rollout with per-site variation, spectrum and radio estate records with change control, integration with maintenance management and physical access systems, and closed-loop remediation runs $250,000 to $550,000 phased across 9 to 15 months.

What drives price up in this category: the number of sites, especially where core and radio vendors differ between them, which happens more often than anyone plans. Integration with operational technology systems, because a terminal operating system, a mine dispatch system or a manufacturing execution system each have their own integration realities and their own change windows. Safety-related requirements, if network state feeds anything with a safety function, which raises the verification burden substantially. And any requirement for automated remediation, since closing the loop means the system is allowed to change the network and that needs careful control design.

What keeps price down: starting with the registry and the site model on one site. Almost every later capability depends on knowing which device is which asset and where the zones are, and neither requires touching the network configuration.

Build versus buy, and when buying is right

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 and buying an operations layer would be premature.

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

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

How to choose a developer for private cellular operations work

Ask them how they would map a cell to a physical zone, and listen for whether they ask about site layout, survey data and how the plant names its own areas. A developer who intends to use coordinates alone has not stood in a facility where the areas people talk about are not the ones on the drawing.

Ask what they would do about a device that is active in the core but has no matching asset record. The right answer is that it is an exception queue with an owner, not a report nobody reads.

Ask which core platforms they have integrated with by name and what interfaces they used for subscriber provisioning and session data. This is the question that separates people who have done private cellular from people who have done enterprise networking.

Ask how they would keep the system out of the safety path. Any operations layer touching a site with safety functions needs a clear statement of what it can and cannot influence, and a developer who does not raise that unprompted is one to be careful with.

Ask who owns the code, the repository and the infrastructure accounts before kickoff, in writing. At Digital Heroes the client holds the repository and the site configuration data from the outset. Send us your site layout, your device inventory and a week of your current network alerts, and we will show you which of those alerts a supervisor could have acted on.