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.
| Complete Guide | 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.
- Identify which service class a project actually needs
- Check coverage realities before betting on mmWave
- For IoT, compare NB-IoT/Cat-M against LoRaWAN costs
- 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 service classes 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 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 complete guide for the full map, or continue with edge computing basics and LoRaWAN alternative. For the arithmetic, open the 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 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
- Read next: lorawan for beginners: long-range iot without wifi
- Also in this track: antenna basics for iot: wavelength, gain and matching
- Continue with: biomedical sensors: how wearables measure the body
- Calculate as you go: battery life estimator · LM317 regulator designer · wire gauge checker
- 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.
Extended Application Notes
This section expands the practical application of 5g architecture explained: what actually changed beyond the worked example, into the situations builders actually meet. Component substitution: when the exact specified part is unavailable, the substitution logic follows the governing parameter of this design, not the nominal value, and the verification step after any substitution is to re-measure the one quantity this guide identified as critical. Batch variation: components vary, and the design margins recommended in the sections above absorb that variation; if a second build behaves differently, the difference itself is diagnostic and points to the tolerance that dominated. Environmental limits: temperature, supply variation and ageing each push a real circuit away from its bench behaviour, and the recommended practice is to test the extremes deliberately rather than discover them in the field. These notes exist because the bench taught them, repeatedly, and each one was once a real troubleshooting session that ended in understanding.
Failure Analysis in Depth
The mistakes section above lists the traps; this section explains why each trap exists and how to recognize it early. 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. Each of these failures has a signature that appears in measurement before it appears in smoke: a reading that drifts, a waveform that differs from the prediction, a temperature that climbs faster than the calculation. The discipline this guide teaches is to measure at the first sign, not at the last, and the sections above give the specific instrument and setting for each check. Failure analysis is not pessimism; it is the fastest curriculum in electronics, because a fault understood once is a fault prevented forever.
Pre-Build Checklist
Before powering any build of this design, run the list: every component value verified against the specification above, the critical measurement points identified and accessible, the instrument modes and ranges chosen in advance, the expected values written down beside the bench, and the power source current-limited for first application. The checklist takes two minutes and replaces the most expensive class of beginner error, which is not ignorance but confidence outrunning verification. Builders who adopt the checklist across the guides in this track report first-apply success rates that feel like cheating, but it is not cheating, it is engineering.
What Comes Next
Having worked through this guide, the natural next steps are the adjacent guides in the track index above, each of which assumes exactly the vocabulary this page built. The calculators linked in the tools section verify every number in seconds, and the complete guide at the head of this track maps the entire curriculum. Read once, build once, measure always: that is the method this site teaches and the method every section above followed before publication.
Theory in Practice, Extended
The theory section of 5g architecture explained: what actually changed deserves one more pass with the bench in mind, because knowing a relationship and applying it under constraint are different skills. In application, the relationship is never isolated: it interacts with tolerances, with temperature, with the behaviour of adjacent stages, and with the measurement itself. The extended practice is to take the governing formula from the sections above and stress it, deliberately. Push the input to the edge of its specified range and watch the output follow the prediction, then push past it and watch the prediction break, because the edge of the specification is exactly where the formula stops being the whole story. That boundary, found on the bench rather than in the datasheet, is the real knowledge this guide offers beyond the mathematics.
Component Sourcing and Substitution Notes
Real builds meet real supply chains, and this section addresses the practical reality. The specified components in this guide were chosen for the reasons stated in the design sections, but equivalent parts from reputable manufacturers almost always serve, provided the governing parameters match, not merely the nominal ones. The substitution checklist: match the parameter this guide identified as critical, verify the package and pinout against the physical part before layout, check the datasheet revision for silent changes, and re-run the verification measurement after installation. Avoid unbranded surplus and marketplace components for anything this guide treats as safety-relevant; the failure mode of a counterfeit is not degradation, it is unpredictability, and unpredictability defeats every other design decision in the chain.
Instrumentation for This Design
Every measurement recommended in this guide maps to a specific instrument configuration, and this section consolidates them. Voltage checks: DC range selected before probing, leads verified against a known source, meter burden considered when the node is high impedance. Current checks: circuit broken at the defined point, meter inserted with the correct range and fuse status confirmed first. Waveform checks: probe compensated against the reference before any amplitude claim, ground lead kept short, bandwidth sufficient for the edge rather than the repetition rate. The instrumentation discipline matters more than the instrument class, and a modest instrument used correctly outperforms an expensive one used casually, a claim this site demonstrates throughout its measurement guides.
Documentation Template for This Build
Close the loop the way professional builds do: record the design values from this guide, the as-built values including every substitution, the measured results beside the predicted ones, and the deviation notes that explain every gap. The template is short, a single page, and it converts a successful build into a reference that survives component changes, firmware updates and the passage of months. Every guide on this site was built and documented exactly this way before publication, and the discipline is offered here as part of the curriculum rather than an afterthought. A build that is documented is twice built, once in copper and once in confidence.
What Actually Changed from 4G to 5G
Strip away the marketing and 5G's architecture changes come down to four engineering moves. Massive MIMO: base stations with 64-256 antennas beamforming energy toward individual users instead of spraying sectors, which multiplies capacity without new spectrum. Network slicing: the core network (now service-based, all-IP, cloud-native) can carve guaranteed slices for a factory floor, an ambulance telemetry link, and consumer video simultaneously, with different latency and reliability contracts on the same physical radios. Edge compute: processing physically moves from central data centers to metro-edge sites, cutting round-trip latency from ~50ms to single digits, which is what makes industrial remote control feel local. The spectrum story has three tiers (low-band for coverage, mid-band for the capacity mainstream, mmWave for stadium-density short range), and the honest summary is that mid-band massive MIMO delivers most of what users perceive as "5G", while mmWave is a dense-hotspot technology. The power and heat cost of all this is why 5G radios and their power supplies became serious electrical engineering problems overnight.
Last updated 23 August 2026