eMBB vs URLLC vs mMTC
These three are the usage scenarios ITU-R drew up for IMT-2020 (5G), and 3GPP built the system to hit them. eMBB (Enhanced Mobile Broadband) chases peak data rate and capacity — the smartphone and fixed-wireless story. URLLC (Ultra-Reliable Low-Latency Communications) trades raw throughput for tight latency and very high reliability, aimed at things that break if a packet is late: factory control, V2X, remote operation. mMTC (Massive Machine-Type Communications) goes the other way — tiny, cheap, battery-frugal devices in huge numbers, each sending a little data once in a while.
They pull in different directions, so no single radio configuration is best at all three. The point of 5G isn't to pick one. Network slicing lets an operator run logically separate networks over the same physical infrastructure — an eMBB slice, a URLLC slice, an mMTC slice — each tuned to its own targets.
| Aspect | eMBB | URLLC | mMTC |
|---|---|---|---|
| Design goal | Maximise data rate and capacity per user and per cell | Hit a deadline every time — latency bound + reliability | Connect a huge number of cheap, low-power devices |
| Peak / target data rate | IMT-2020 targets 20 Gbit/s down, 10 Gbit/s up (peak); 100+ Mbit/s user-experienced | Low — enough for control/sensor payloads, not bulk data | Very low — bytes to kilobytes per message |
| Latency target | A few ms or so — not the headline metric | IMT/3GPP target is ~1 ms user-plane (a design target, not a guarantee) | Latency-tolerant — seconds or longer is fine |
| Reliability target | Standard — best-effort throughput is acceptable | 99.999% packet success (the "five-nines" 3GPP target) for a given payload/latency | Modest per device; deep coverage matters more than per-packet reliability |
| Device density | Normal smartphone/CPE densities | Moderate — relatively few high-value endpoints | IMT-2020 targets up to 1,000,000 devices per km² |
| Power / battery | High power draw; charged daily | Usually mains-powered (factory gear, vehicles, infrastructure) | Years on a coin cell — PSM and eDRX let the modem sleep most of the time |
| Example use cases | Video streaming, AR/VR, fixed wireless access, large file transfer | Factory automation, remote surgery, V2X, smart-grid protection | Smart meters, environmental and asset sensors, agriculture, logistics tags |
| Standardised slice type (SST) | SST = 1 | SST = 2 (V2X is a separate standardised value, SST = 4) | SST = 3 (3GPP also defines further values for MIoT and other slice types) |
| Spectrum / bandwidth needs | Wide channels, often mmWave (FR2) and mid-band carrier aggregation | Mid-band for coverage + capacity; short slots (mini-slots) to cut delay | Narrow channels in low band for reach and building penetration |
| Air-interface tactics | High-order MIMO, 256-QAM, big bandwidth parts | Mini-slots, grant-free/configured-grant uplink, PDCP duplication, lower coding rates | Small grants, long sleep cycles, coverage enhancement / repetitions |
| Mobility | Full mobility, including high-speed handover | From fixed (factory) to very high speed (V2X) — handover must hold the latency budget while moving | Mostly stationary or nomadic; many devices barely move |
| QoS handling (5QI) | Non-GBR 5QIs for elastic, best-effort throughput | Delay-critical GBR 5QIs with tight packet delay budget and error-loss targets | Non-GBR, delay-tolerant — small infrequent transfers |
Why ITU split 5G into these three
Earlier mobile generations were judged mainly on speed. ITU-R recognised for IMT-2020 that the next wave of demand was too varied for one yardstick. A streaming phone wants gigabits. A robot arm on a production line doesn't need much data at all, but a late command can stop the line or hurt someone. A water meter sends a few bytes a day and has to last a decade on one battery.
So the requirements were grouped into three usage scenarios — eMBB, URLLC, mMTC — and 3GPP turned each into concrete numbers and features. Treat them as design targets that shaped the standard, not as boxes every product falls neatly into. Plenty of real deployments sit between two corners.
The trade-offs you can't dodge
The three pillars sit at corners of a triangle, and you generally can't max out all of them on the same connection at the same time.
- Latency vs throughput. Cutting latency means short transmission slots and sending before you've gathered much data. That's the opposite of packing a fat slot full of bits for peak rate.
- Reliability vs efficiency. Hitting 99.999% often means sending the data twice (PDCP duplication), using a conservative coding rate, or reserving resources up front — all of which waste capacity an eMBB slice would rather keep.
- Battery vs responsiveness. An mMTC device sleeps for hours so it can run for years. A sleeping modem can't answer in 1 ms. You pick one.
Knowing which corner an application lives in tells you what to optimise — and what to give up.
How one network serves all three: slicing
5G's answer to the trade-offs is to stop forcing a single configuration. With network slicing, an operator carves the same gNBs, transport, and 5G Core into logically isolated end-to-end networks, each with its own policies and resource share.
A device asks for a slice using an S-NSSAI, whose SST flags the slice type — 1 for eMBB, 2 for URLLC, 3 for mMTC in the original 3GPP set. The core (via the NSSF) steers it to a slice tuned for that job: an eMBB slice with wide bandwidth and high-order MIMO, a URLLC slice with mini-slots and duplication, an mMTC slice optimised for coverage and sleep. Inside each slice, 5QI values set the per-flow latency and loss targets so the radio and core treat traffic the way that slice needs.
The bottom line
eMBB, URLLC, and mMTC aren't competitors you choose between — they're the three design targets ITU-R set for 5G, each pulling the radio in a different direction (data rate, latency/reliability, device count and battery life). No single configuration wins all three at once. The reason 5G is built around network slicing is exactly this: one physical network can run an eMBB slice, a URLLC slice, and an mMTC slice side by side, each tuned to its corner of the triangle. So the real question isn't "which pillar?" — it's "which slice does this application need, and what is it willing to trade away?"
Frequently asked questions
- What are the 3 types of 5G?
- The three are ITU-R usage scenarios for IMT-2020: eMBB (Enhanced Mobile Broadband) for high data rate and capacity, URLLC (Ultra-Reliable Low-Latency Communications) for tight latency and very high reliability, and mMTC (Massive Machine-Type Communications) for huge numbers of low-power IoT devices.
- What's the difference between eMBB and URLLC?
- eMBB optimises for throughput — gigabit speeds and capacity for video, AR/VR, and fixed wireless. URLLC gives up most of that data rate to meet a strict latency bound (a ~1 ms user-plane target) with five-nines (99.999%) reliability, for things like factory control, V2X, and remote operation. eMBB cares how much you can move; URLLC cares whether each packet arrives on time, every time.
- Which 5G pillar is for IoT?
- mMTC is the pillar for massive IoT — many cheap, battery-powered sensors and meters sending small, infrequent messages, with density targets up to a million devices per km² and battery life measured in years. Note that latency-critical IoT (a robot, a vehicle) belongs to URLLC instead, not mMTC.
- Can one network do all three?
- Yes — that’s the whole point of network slicing. A 5G operator runs logically separate slices over the same physical gNBs, transport, and core, each tuned to one scenario. A device requests a slice via its S-NSSAI (the SST field flags eMBB, URLLC, or mMTC), so a single network can serve all three at once without one degrading the others.
- Are 1 ms and 99.999% guaranteed in real networks?
- No. Those are the URLLC design targets from ITU and 3GPP for specific conditions and payloads — they describe what the standard is built to achieve, not a blanket promise. Real latency and reliability depend on the deployment, spectrum, coverage, and how the URLLC slice is configured.
Related terms
Go deeper than eMBB vs URLLC vs mMTC — free for 7 days.
Learn eMBB vs URLLC vs mMTC and the full 5G/6G stack with interactive lessons, labs and a TelcoMentor AI coach. Start a free 7-day Pro trial — no credit card.
- No credit card
- Full Pro access
- 21 verifiable certs
- TELCOMA since 2009
Get weekly 5G/LTE engineering deep-dives
One technical breakdown every Tuesday — plus first access to new tools and lessons. No spam, no marketing, just engineering. Unsubscribe in one click.