Picture a private 5G dashboard on a Monday morning. One core, two radios, one site. Nine SIMs provisioned, zero connected. No traffic, no data used. The backhaul looks great: under 8 ms of latency, no packet loss, a little over 200 Mbps down. Two critical alerts.
Is the network down? Not exactly. The core is up. The internet link is healthy. The SIMs exist. The two radios are offline because neither has a spectrum grant from the SAS, so neither is allowed on air. Nothing can attach, so nothing shows up as connected.
That one screen says a lot about private 5G. The radios get the attention because you can see them on a mast. The core is the part that decides who gets on, what they can reach, and how fast. When something goes wrong, finding the answer usually takes both.
What a Private 5G Core Actually Does
Every private 5G network has the same basic shape.
The path every packet takes
Device with a SIM → radio on the mast → 5G core → your plant network, your cloud apps, or the internet.
The radios handle the air. Everything after that is the core. On a carrier network the core sits in a carrier data center you'll never see. On a private network it is a server you own, or one someone runs for you, and it usually sits on site.
It decides who gets on.
Only devices with SIMs the network issued can attach. The core holds the subscriber list, checks each SIM when it tries to connect, and refuses anything it doesn't recognize. A phone on a carrier plan that walks past the mast gets nothing. This is the biggest security difference from site Wi-Fi. There is no shared password to leak, and you shut a lost device out by disabling one SIM.
It decides where traffic goes.
Each device lands in a lane. Carriers have called this an APN for years, and 5G calls it a DNN. A lane has its own rules: which network it reaches, which addresses it hands out, and what it is allowed to talk to. Cameras go in one lane, tablets in another, SCADA telemetry in a third. On your side each lane maps to a VLAN, so the segmentation you already run in OT carries straight over.
It decides who gets priority.
Quality of service lives in the core. A crane camera can get a guaranteed uplink rate. A push-to-talk group can get priority over a contractor's software update. A guest device can be capped. On public LTE, every device competes with everyone else on the tower. On a private network, you set the order.
It hands traffic to the rest of the world.
The part of the core that forwards packets connects to your network and the internet over a link the standard calls N6. In practice that link is your backhaul: fiber if the site has it, satellite and cellular if it doesn't. When a crew says "5G is slow," the problem is often here, not on the radio.
The acronyms, in one place
If you are reading a vendor datasheet, these are the pieces of a 5G core you will see named:
AMF (access and mobility)
Handles devices attaching, moving between radios, and detaching.
AUSF and UDM (authentication and subscriber data)
Hold the SIM records and check that a device is who it claims to be.
SMF (sessions)
Sets up each device's data session and puts it in the right lane.
PCF (policy)
Holds the QoS and priority rules.
UPF (user plane)
Actually moves the packets, and connects out over N6 to your network and the internet.
You don't need to memorize them. It is worth knowing that the UPF is where the traffic goes and the rest is control, because that split decides what keeps working when a link drops.
Why It Breaks Down
Most private 5G trouble isn't a broken radio. It is a gap between pieces that are owned, monitored, and explained by different people.
- The radio and the core are separate systems. Radio status, spectrum grants, and radio alarms live in the radio vendor's management system. Subscribers, sessions, and usage live in the core. If nobody looks at both, "nine SIMs, zero connected" turns into a day of finger-pointing.
- Spectrum is a dependency the core can't see. On CBRS, a radio can't transmit until the SAS grants it spectrum. A healthy core with no grants is a network nobody can join, and the core's own screens will look fine the whole time.
- The core gets treated as set-and-forget. SIMs are provisioned once and never cleaned up. Lanes created for a pilot are never removed. QoS stays at defaults because nobody owns it. Six months later the network works, but nobody can tell you who is on it or why.
- Backhaul gets blamed last. A user reports slow uploads. The radio looks fine, so the ticket goes to the device team. The real problem is a saturated link between the core and the internet, and nobody was watching latency or packet loss.
- A cloud-hosted core adds a dependency you didn't plan for. Some offerings run the core in a vendor cloud. That works until the site loses its internet link, and with it the ability to authenticate devices on its own local network.
None of these is exotic. They are what happens when a network is bought as hardware and nobody is assigned to run the part in the middle.
What Actually Works
Three habits separate a private network you can run from one you just own.
Keep the core on site
Put the core next to the radios, so authentication, lane assignment, and local traffic keep working when the backhaul doesn't. Traffic that never needs to leave the site shouldn't depend on an internet link. That includes cameras recording to an on-site NVR, push-to-talk between crews, and sensor data going to a local historian. On the Mobile Connectivity Unit, the core runs on a server in the van's telecom rack, so the network brings its own brain to the site.
Look at the core and the radios in one view
The useful view combines two sources. The core reports subscribers, sessions, traffic, usage, and backhaul health. The radio management system reports radio status, SAS grants, and radio alarms. Side by side, the Monday morning example takes thirty seconds to read: core healthy, backhaul healthy, SIMs provisioned, radios off air, no grants. The fix is a spectrum grant, not a ticket to the device team.
Whoever runs your network should be able to answer these at a glance:
- Is every radio on air, and does each one have a current spectrum grant?
- How many SIMs are provisioned, and how many are actually attached?
- How much data is each lane and each device using, uplink and downlink?
- What are latency, packet loss, and throughput on the backhaul right now?
- Which alerts are open, and who owns each one?
Treat SIMs and lanes as managed inventory
Every SIM is a device, and every device is a SIM. Adding one, disabling one, moving one to a different lane, or changing its speed limit should be a routine change with a record, not a one-off login to a core console. When a tablet goes missing, disabling its SIM in the core is faster and more certain than waiting for the device to check in. We cover the device side of that in managing intrinsically safe devices.
The Core on a Clover IQ Deployment
Every Clover IQ private 5G deployment runs its own core on site, and we operate it as part of the engagement. You don't buy a core license, size a server, or learn a vendor console. Here is what that covers.
Before deployment
SIMs are provisioned against your device list. Lanes and VLANs are mapped to the segmentation plan from the site survey. SAS registration for every radio is done before the van rolls, so spectrum isn't the thing you wait on.
Deployment day
The core comes up with the rest of the network. The one-hour clock includes core initialization, VLAN configuration, and the first device connectivity test.
While it runs
24/7 remote monitoring is part of the monthly engagement, and it treats the core, the radios, and the backhaul as one network. Adding a SIM, disabling a lost device, or giving a camera feed priority is a request to us, not a project for your IT team.
At demob
SIMs are deactivated and the device inventory is reconciled in the deployment report. No live lines left billing, and no core left running in a closet.
Questions from the Field
Do we need our own 5G core, or can we use the carrier's?
If all you need is coverage, a carrier plan may be enough. If you want to decide who gets on, what they can reach, and what gets priority, the core has to be yours, either owned or operated for you on site. Carrier slicing gets closer, but the rules still live on someone else's network. We compare the two approaches in private 5G vs. carrier buildout.
What happens if the internet link goes down?
With an on-site core, the local network keeps working. Devices stay attached, and traffic between devices and on-site systems keeps flowing. Only traffic that needs the internet or a cloud app stops. With a cloud-hosted core, losing the link can mean devices can't attach at all.
Is this the same as standalone vs. non-standalone 5G?
They are related. Non-standalone 5G runs 5G radios on top of a 4G core. Standalone 5G uses a full 5G core. Plenty of private networks on CBRS still run LTE or non-standalone, and that is fine for most industrial traffic. The questions in this post apply either way: who owns the core, where it runs, and who watches it.
Can the core enforce our OT segmentation?
Yes, and it should. Each lane maps to a VLAN, and a device's SIM decides which lane it lands in. A contractor tablet can't reach the SCADA segment because its SIM was never allowed on that lane. Pair this with OT discovery, so you know what you are segmenting before you design the lanes.
What does the SAS have to do with the core?
Nothing directly, and that is the trap. The SAS grants spectrum to radios, not to the core. A core can be completely healthy while every radio sits off air waiting on a grant. That is why radio status and SAS grants belong in the same view as subscribers and traffic.
Straight Talk
Radios are what you see on the mast, so they get most of the attention in a private 5G quote. The core gets a line item and a license count. That is backwards. The core is where security, segmentation, and priority are set, and it is where most troubleshooting starts.
You don't need to become a core engineer to run a private network. You do need someone who owns it: someone who provisions SIMs, keeps lanes clean, watches the backhaul, and can tell a SAS problem from a radio problem from a core problem before your crews notice. If that person isn't on your team, it should be the people you hire to run it.
Book a 30-minute discovery call. Bring your device count, how your OT network is segmented today, and what backhaul the site has. We'll tell you how the core would be set up for your site and who would be watching it.
