All articles

Industrial Operations

Your Celona Network Is Live and Scaling. What Happens When It Affects the Production Floor?

Phillip Smith7 min read

Your Celona Network Is Live and Scaling. What Happens When It Affects the Production Floor?

Published by Phillip Smith, Milewire LLC

A Celona CBRS network is live across 20 warehouse locations.

Automated forklifts, AGVs, scanners, and inventory systems depend on it. The rollout went well. The dashboard looks clean. The business now sees private wireless as part of the production environment, not as a pilot.

Then site 14 has a problem.

An AGV stops mid-route. The application team says the vehicle lost connectivity. The Celona Conductor dashboard appears healthy. The IT team opens a ticket. Nobody can say whether the fault is in the RAN, the EPC, the transport layer, the device, or the application.

The AGV sits idle for four hours while the team emails Celona support and waits for a response.

This is where many industrial private wireless programs discover that deployment success and operational readiness are not the same thing.


Easy To Deploy Does Not Mean Easy To Operate

Celona has done real work to make private cellular easier for enterprises to deploy.

That ease is part of the value. It also creates a trap.

The deployment experience can feel familiar to an IT team that has spent years operating Wi-Fi, switches, and enterprise security tools. A dashboard shows sites, access points, devices, policies, and health indicators. The system feels manageable.

But private cellular is not Wi-Fi.

A handover failure is not the same as a roaming complaint. A coverage shadow may not look like a simple weak signal issue. An interference event, bearer problem, SIM profile issue, or EPC session failure may require cellular knowledge that most enterprise IT teams have never needed.

That does not mean the IT team is weak. It means the technology sits outside its normal operating model.

The problem usually appears during the first production-impacting incident. The team can see that something is wrong, but it cannot isolate where the failure sits. The dashboard may show green while one application path is broken. The device may appear attached while the production workflow still fails.

At that point the team is no longer operating the network. It is waiting on the vendor to interpret it.


The Gap Is Process, Not Architecture

In most Celona environments, the operational gap is not the radio design or the core architecture. The gap is process.

There are no runbooks for cellular-specific failure modes.

The ITSM platform is not configured to distinguish a cellular incident from a Wi-Fi incident, a general network incident, or an application issue. A ticket about an AGV connectivity problem may land in a general helpdesk queue with no clear triage path.

There is no defined escalation procedure that tells the helpdesk what data to collect before contacting Celona support. The ticket may not include device identity, SIM status, serving cell, signal measurements, recent handover behavior, site transport status, affected application, or whether other devices in the same area are impacted.

Without that data, the first support exchange often becomes a slow discovery process.

The vendor asks for information. The operator asks internal teams to find it. The application team blames the network. The network team asks whether the device is healthy. The site team checks whether anything changed on the floor. Hours pass.

This is not a technology failure. It is an operating model failure.

When something breaks, the team improvises. Improvisation works once in a while. It does not scale.


Improvisation Gets Expensive At Scale

At one site, a weak process may be manageable.

At 20 or 50 sites, it becomes a systematic problem.

A firmware issue may cascade across multiple locations. A coverage shadow may affect AGVs at three warehouses with similar floor layouts. A handover degradation may show up only for one device model. A transport problem may look like a cellular issue until someone checks the backhaul path.

If each site handles those issues differently, the organization never builds operational memory.

One site opens a ticket with Celona. Another calls the application vendor. Another reboots devices. Another dispatches a local technician. Another waits until the next shift. The same underlying failure produces five different responses.

That is how downtime becomes normal.

The larger the footprint, the more important it becomes to standardize how incidents are identified, classified, escalated, and reviewed.


What Good Governance Looks Like

Good operational governance in a Celona environment is practical.

It starts with runbooks written for the failure modes the network actually experiences. AGV stopped. Device attached but application unreachable. Poor throughput in a specific aisle. SIM not provisioning. Repeated disconnects after shift change. Site transport degraded. Each runbook should tell the team what to check first, what data to capture, and when to escalate.

It includes ITSM configuration that routes cellular incidents to the right resolver group with the right SLA clock. A production-floor connectivity issue should not sit behind routine desktop tickets.

It includes an escalation procedure that tells the helpdesk exactly what to collect before calling Celona support. That improves the first support interaction and reduces the back and forth that usually burns the first few hours.

It also includes KPI monitoring that catches degradation before it stops an AGV. The team should be looking for trends in attachment failures, throughput drops, handover behavior, coverage complaints, device class issues, and site-level performance.

None of this requires turning an enterprise IT team into a mobile network operator. It requires giving that team a process that matches the network it now owns.

Celona's job is to make the network easy to deploy.

The operator's job is to make it easy to operate.

Those are two different problems. Only one of them ships with the hardware.


Author Bio

Phillip Smith is the founder of Milewire LLC, a private LTE operations advisory firm based in Arlington, Texas. He has over 25 years of hands-on RAN and private LTE engineering experience across AT&T, Verizon, T-Mobile, Ericsson, Nokia, and Celona environments. Milewire LLC is a veteran-owned and minority-owned small business serving utilities, industrial operators, and enterprises running private wireless networks.

Need to discuss private LTE operations?

Share context on your network, vendor model, and operating constraints. We respond within one business day.

Schedule a Discovery Call
Back to articles