Procirel5G Architecture Explained: What Actually Changed
5G is not just “4G but faster” — it is a radio and core network redesigned around three different promises. Enhanced mobile broadband, massive IoT, and ultra-reliable low latency. Understanding which of the three a use case needs explains every technology choice inside it.
> At a glance: 9 minute guide · part of the IoT and ESP32 complete guide track · worked example, quick-reference table and field notes included.
## The three service classes
eMBB delivers multi-gigabit broadband to people. mMTC (massive machine-type communication) connects millions of low-power devices per square kilometre. URLLC targets millisecond latency with five-nines reliability for industry and vehicles. No single radio serves all three — 5G is a family of profiles.
## The radio side: massive MIMO and mmWave
Base stations deploy dozens of antennas, beamforming signals precisely to each user — capacity multiplies without new spectrum. Millimetre-wave bands add enormous bandwidth at short range, demanding dense small cells. Sub-6 GHz carries the coverage burden.
## The core: virtualised and sliced
The 5G core is software running on standard compute, with network functions virtualised. Its signature feature is slicing: logically isolated networks on shared infrastructure — one slice tuned for IoT telemetry, another for latency-critical control, each with its own guarantees.
| Pillar | Target | Enabling tech |
| — | — | — |
| eMBB | Multi-Gbps broadband | mmWave, massive MIMO |
| mMTC | Millions of devices/km² | NB-IoT class protocols |
| URLLC | ~1 ms, 99.999 % | Edge cores, grant-free access |
| Slicing | Isolated virtual nets | Virtualised 5G core |
## How to apply this in your build
Work through the sequence below. Each step assumes the previous one passed. The numbers that need arithmetic are covered by the linked tools at the end of this guide.
1. Identify which service class a project actually needs
2. Check coverage realities before betting on mmWave
3. For IoT, compare NB-IoT/Cat-M against LoRaWAN costs
4. Design for edge compute where latency is the product
### Worked example
A factory uses one physical 5G network but three slices. Broadband for AR maintenance, mMTC-style monitoring for thousands of sensors, URLLC for robot coordination — same infrastructure, three service contracts. Cross-check with the Frequency & Wavelength and the result should agree to within rounding.
> Practical note from the bench. Honest engineering question for every 5G pitch: which of the three pillars does this need? Most projects need exactly one — and often LoRaWAN or WiFi at a tenth the cost.
## Who this guide is for
First-time readers get a single focused topic instead of a textbook chapter, with every term defined where it first appears. Returning readers use it as a reference. The table, the worked example and the mistake list answer the questions that come up mid-build. If you teach, the structure (theory, application, example, failure modes) maps cleanly onto a lab session.
## Prerequisites and preparation
Before starting. Identify which service class a project actually needs and check coverage realities before betting on mmwave. Keep the [Frequency & Wavelength](/tools/frequency-wavelength) open, every number in the worked example is reproducible. Total time including the bench steps: about 7 to 9 minutes.
## Common mistakes to avoid
Each of these has cost real hardware on someone’s bench, usually ours:
– Believing “5G” on a box means the low-latency profile
– Ignoring that mmWave needs line of sight
– Planning massive IoT on a slice designed for phones
## Key takeaways
– The three service classes — the foundation of this guide; revisit it if any measurement here surprises you.
– The radio side: massive MIMO and mmWave — the foundation of this guide. Revisit it if any measurement here surprises you.
– The core: virtualised and sliced — the foundation of this guide. Revisit it if any measurement here surprises you.
### Quick reference card
| Aspect | Where to find it in this guide |
| — | — |
| Core theory | The three service classes |
| Application steps | How to apply this in your build |
| Worked numbers | Worked example |
| Failure modes | Common mistakes to avoid |
## How this fits the IoT and ESP32 complete guide track
This guide is one stop in a structured path. Start from the [IoT and ESP32 complete guide](/tutorial/iot-esp32-complete-guide) pillar page for the full map, or continue with [edge computing basics](/tutorial/what-is-edge-computing) and [LoRaWAN alternative](/tutorial/lorawan-tutorial-beginners). For the arithmetic, open the [Frequency & Wavelength](/tools/frequency-wavelength).
## Frequently asked questions
Does 5G replace WiFi for IoT?
No — they partition by economics: high-density sensor telemetry suits licensed low-power WANs. High-throughput local traffic stays on WiFi.
What is network slicing physically?
Software separation: the same radios and core route different traffic classes with independent configuration and guarantees.
Is there a calculator for this?
Yes, the [Frequency & Wavelength](/tools/frequency-wavelength) run the formulas from this guide instantly, client-side, no signup.
## Related guides and tools
– The complete iot, sensors & esp32 guide: [IoT, Sensors & ESP32 complete guide](/tutorial/iot-esp32-complete-guide)
– Read next: [lorawan for beginners: long-range iot without wifi](/tutorial/lorawan-tutorial-beginners)
– Also in this track: [antenna basics for iot: wavelength, gain and matching](/tutorial/antenna-basics-tutorial)
– Continue with: [biomedical sensors: how wearables measure the body](/tutorial/biomedical-sensor-guide)
– Calculate as you go: [battery life estimator](/tools/battery-life) · [LM317 regulator designer](/tools/lm317-regulator) · [wire gauge checker](/tools/wire-gauge-awg)
– From here, the natural continuation is the next guide in the track index. It assumes exactly the vocabulary this page built and adds the next layer of practice.
## Verification routine
Component substitution is a legitimate experiment as long as it is deliberate. Swap one part, predict the effect, measure, and record. That single habit converts a parts bin into a teaching lab and makes every future guide in this track faster to absorb.
The fastest way to internalise this topic is to change one variable deliberately and predict the result before measuring. Wrong predictions are the curriculum, they show exactly which mental model needs revisiting, and the bench grades honestly.
## Formulas and checks from this guide
Verification checklist for this track: watch RSSI before blaming code, measure supply current during radio bursts. Confirm MQTT topics against the broker log. Wireless bugs are usually power or signal problems wearing a software disguise.
Bookmark this page against your next build in the track. The checklist above is the same one used across 23 guides in this series.
## Notes from the bench
Location, then device, then measurement. Document the tree before flashing the first device.
Measure current during transmit bursts. Sags under load are power problems, no firmware fixes those.