5G RedCap: Filling the Gap Between NB-IoT and Full 5G

There's a hole in the middle of the 5G device landscape, and it's wider than most people realise.

At one end, NB-IoT and eMTC serve devices sending a few hundred bytes a day — smart meters, parking sensors — with multi-year battery life and throughput measured in tens of kilobits per second.

At the other, full 5G NR serves smartphones and fixed wireless: hundreds of megabits, 100 MHz carriers, four receive antennas, and a bill of materials to match.

Between them sits a large category with genuinely awkward requirements. A smartwatch needs several megabits, not kilobits — but doesn't need a smartphone modem or its power budget. An industrial sensor with a camera needs 10–20 Mbps. A surveillance camera needs 2–5 Mbps continuously, for years, at a price point that makes a full NR modem absurd.

RedCap (Reduced Capability NR), introduced in 3GPP Release 17, is the device class built for that middle.

---

What actually gets reduced

RedCap is not a new radio technology. It's NR with specific capabilities relaxed, which is the key to understanding both what it costs and what it doesn't.

Bandwidth

The big one. A full NR device supports up to 100 MHz in FR1. RedCap caps at 20 MHz in FR1 and 100 MHz in FR2.

This cascades through the entire design: narrower RF filters, lower ADC/DAC sampling rates, less baseband processing, smaller memory, lower clock speeds. Bandwidth reduction alone accounts for a large share of the total complexity saving.

It's also where bandwidth parts earn their keep. A RedCap device operates within a 20 MHz BWP on a wider carrier — the network doesn't need separate spectrum, just a suitably configured BWP.

Receive antennas

Full NR devices support four receive antennas in most FR1 bands. RedCap allows one or two.

Each antenna needs its own RF chain, and the physical separation for diversity gain is a real constraint on a wristwatch. Fewer antennas means smaller, cheaper, less power-hungry devices.

The cost is honest and unavoidable: fewer antennas means less diversity gain and reduced MIMO rank. Roughly 3 dB of link budget goes with dropping from two receive antennas to one, which translates directly into coverage. Release 18 adds coverage recovery techniques partly to address this.

Duplex

RedCap permits half-duplex FDD (Type A). The device transmits or receives, never both simultaneously.

That removes the duplexer — a bulky, expensive component — and simplifies the RF front end substantially. The cost is throughput, since transmit and receive time-share, which is fine for asymmetric traffic and unhelpful for anything symmetric.

Processing

Relaxed peak data rate requirements, smaller maximum transport block sizes, and relaxed processing timelines all reduce baseband complexity and memory.

Realistic results: roughly 65% of full NR complexity with one receive antenna, or around 75% with two. Meaningful, though worth noting it's not the order-of-magnitude reduction NB-IoT achieved.

---

Power: eDRX and RRC_INACTIVE

Complexity reduction cuts active power. Battery life comes from not being active.

RedCap relies on two mechanisms:

Extended DRX (eDRX) stretches paging cycles far beyond normal DRX — up to hours in RRC_IDLE. A sensor checking for downlink data every few minutes rather than every 1.28 seconds saves enormous energy.

RRC_INACTIVE keeps the UE context at the anchor gNB, so resuming costs a lightweight procedure rather than full connection setup. For a device sending short bursts periodically, the signalling saving dominates the energy budget. (See RRC states in 5G for how this works.)

Release 18 adds eDRX in RRC_INACTIVE, combining both — the configuration that gets RedCap toward multi-year battery life on suitable duty cycles.

---

Where it fits against the alternatives

Two points worth drawing out.

RedCap does not replace NB-IoT. They're an order of magnitude apart in both capability and cost. A water meter that transmits 50 bytes monthly for ten years on a coin cell should use NB-IoT. RedCap would be wasteful and wouldn't last.

RedCap is closest in spirit to LTE Cat-1/Cat-4 — the workhorse category for trackers, POS terminals, and cameras. That's the real migration target. As operators refarm LTE spectrum, RedCap is what those devices move to.

eRedCap in Release 18 pushes further down: 5 MHz bandwidth, single antenna, targeting devices where even RedCap is more than needed — closing the gap toward eMTC territory from above.

---

The three target markets

Wearables — smartwatches, health monitors, AR glasses. Need several Mbps for sync and voice, must fit a small enclosure, and battery life is the primary product constraint.

Industrial sensors — machine monitoring, quality inspection, asset tracking. Often deployed in private 5G networks where slicing, deterministic QoS, and time-sensitive networking matter. This is where RedCap's inheritance from full NR pays: a RedCap device is a real 5G device with real QoS support, which an NB-IoT device is not.

Video surveillance — 2–5 Mbps continuous upstream, mains-powered so battery matters less, but unit cost matters enormously at fleet scale.

---

What RedCap is not

Not "mini 5G" or a cut-down protocol. RedCap devices use the same NR physical layer, the same protocol stack, the same 5G Core procedures. They support network slicing, the 5G QoS model, and standard security. The reductions are to device capability, not to the system.

Not automatically cheap to deploy. Networks need Release 17 support, and cells must broadcast the initial access configuration RedCap devices need — including separate initial BWP configuration in some cases. It's a software upgrade on most modern equipment, but it isn't free.

Not a coverage improvement. Fewer antennas and narrower bandwidth mean worse link budget than a full NR device in the same conditions. Release 18's coverage recovery mechanisms exist because this is a genuine deployment concern, particularly for devices at cell edge or deep indoors.

Not a direct NB-IoT competitor. Different capability class, different price point, different battery expectation.

---

What the reductions actually cost

Each RedCap reduction buys cost and power, and each takes something away. Being specific about the trade is the difference between choosing RedCap sensibly and being surprised by it.

Bandwidth. 20 MHz in FR1, 100 MHz in FR2, against 100 and 400 for a full device. This caps peak throughput, but it also reduces frequency diversity — a narrowband device sees a less averaged channel and is more exposed to frequency-selective fading.

Receive antennas. One or two, against four. Halving the receive branches costs roughly 3 dB of combining gain, which translates directly into coverage. A RedCap device at the cell edge is genuinely worse off than a smartphone standing beside it, and link budget analysis has to account for it.

MIMO layers. One or two rather than four, which caps spectral efficiency independently of bandwidth.

Duplex. Half-duplex FDD is permitted, meaning the device never transmits and receives simultaneously. This saves the duplexer — a real cost and size saving — at the price of scheduling flexibility, because the scheduler must now avoid overlapping grants.

Modulation. 256QAM downlink support becomes optional.

Coverage recovery

Because the antenna and bandwidth reductions cost coverage, RedCap is usually deployed alongside compensating techniques. PUSCH repetition trades throughput for reliability by sending the same data across multiple slots. Larger message sizes in msg3 and adjusted power control help the uplink, which is typically the limiting direction for a small battery-powered device.

The honest summary is that RedCap devices need slightly denser deployment than smartphones for equivalent service, and planning that assumes otherwise produces coverage holes that only affect the IoT fleet.

---

How the network identifies a RedCap device

A RedCap device must be recognised before it is scheduled, because scheduling it like a full-capability UE will fail. Identification happens early — during random access, before RRC connection setup.

The device signals its reduced capability in msg1 or msg3, depending on configuration. Networks may configure separate PRACH resources for RedCap, so the choice of preamble itself carries the information. Alternatively the indication rides in msg3, later but requiring no dedicated resources.

Once identified, the network can apply RedCap-specific handling: a separate initial BWP sized within the device's bandwidth, appropriate scheduling constraints, and separate access control.

That last point matters more than it looks. A cell serving thousands of meters alongside human subscribers needs to shed IoT load without affecting phone calls, and cell barring for RedCap allows exactly that — a cell can accept normal devices while turning RedCap away.

Bandwidth parts do the heavy lifting

A RedCap device cannot receive a 100 MHz carrier, but the cell still operates one. Bandwidth parts reconcile this: the device is configured with a BWP no wider than its capability, positioned inside the wider carrier.

There is a constraint that catches people out. The initial BWP, used during random access before any dedicated configuration exists, must be reachable by a RedCap device. If the cell's initial BWP is wider than 20 MHz, RedCap devices cannot complete initial access at all, and the network must configure a separate narrower one for them.

---

eRedCap and where this is going

Release 18 added eRedCap, pushing the reductions further: a 5 MHz baseband bandwidth option, and peak rates around 10 Mbps rather than 150.

The motivation is that Release 17 RedCap landed closer to the smartphone end of the range than some segments needed. A wearable benefits from RedCap's capability; a smart meter does not need it, and the remaining cost gap against LTE Cat-1bis kept those devices on legacy technology.

eRedCap narrows that gap, and it matters for a reason beyond cost: LTE networks will eventually be refarmed. Devices deployed today with fifteen-year lifetimes need a 5G-native path, and the low end of the IoT market had none until eRedCap.

---

The mental model

RedCap = NR with reduced device capability. Same protocol, same core, relaxed requirements.

Four reductions: 20 MHz bandwidth, 1–2 Rx antennas, half-duplex FDD, relaxed processing. Roughly 65% of full NR complexity.

Bandwidth parts are what let a 20 MHz device work on a 100 MHz carrier.

eDRX + RRC_INACTIVE deliver the battery life, not the complexity reduction.

It targets LTE Cat-1/Cat-4 devices, not NB-IoT.

eRedCap (R18) goes narrower again: 5 MHz, single antenna.

RedCap matters strategically because it's how 5G reaches the device categories that would otherwise stay on LTE indefinitely. Operators can't refarm LTE spectrum while millions of Cat-1 devices depend on it — and RedCap is the answer to that problem as much as it is a device class.

---

Further reading

• RRC states in 5G — RRC_INACTIVE and why it matters for IoT
• 3GPP TR 38.875 — Study on support of reduced capability NR devices
• 3GPP TS 38.306 — UE radio access capabilities
• 3GPP TS 38.331 — RRC specification, RedCap-specific configuration