5G RedCap for Industrial IoT: Reduced Capability Devices, Power and Deployment Guide

Most industrial plants run two cellular worlds side by side. Low-power sensors sit on LTE-M or NB-IoT, where a coin cell lasts years but a camera frame cannot be sent. Gateways, cameras and handhelds sit on full 5G NR or Wi-Fi, where throughput is generous but the modem is expensive, hot and hungry. The middle band, roughly 2 to 100 Mbps at a sensible price, has been poorly served for a decade.

5G RedCap, short for Reduced Capability and informally called NR-Light, was standardised in 3GPP Release 17 to fill that gap, and Release 18 added eRedCap to reach even lower in cost and power. In 2026 the technology is no longer a paper exercise: RedCap devices ship, operators run it on standalone cores, and plants are testing it for inspection cameras and wireless gateways.

You will leave with a precise view of what RedCap removes from the NR device, how the power-saving states work, where eRedCap fits against LTE-M, NB-IoT and Cat-1bis, and a decision framework for private and public networks.

What this covers: the Release 17 and 18 feature set, a reference architecture for plant deployment, an eDRX power walk-through, a comparison matrix against LTE-M, NB-IoT, Cat-1bis and full NR, and the failure modes that catch teams out.

Context and Background

Cellular IoT before 2020 was split into two broad families. Massive machine-type communications were served by LTE-M (Cat-M1, 1.4 MHz channel) and NB-IoT (180 kHz channel), both introduced in Release 13. Ericsson describes both as designed for coverage extension and battery life of ten years or more using eDRX and Power Saving Mode (PSM), with NB-IoT peak rates around 200 kbps in half-duplex operation. These are excellent for meters and trackers. They are unusable for video or for a gateway aggregating many Modbus and OPC UA streams.

Above them sat LTE Cat-1, Cat-1bis, Cat-4 and in recent years full 5G NR modems, whose design target was smartphones. A baseline Release 15 NR device must handle up to 100 MHz of bandwidth in the sub-6 GHz range (FR1), two to four receive branches, up to four downlink MIMO layers, and 256QAM. That requirement drives silicon area, radio front-end count, memory and power draw.

3GPP began studying the gap in 2020. The study concluded that three use case families needed something in between: industrial wireless sensors, video surveillance and wearables. The Release 17 overview paper on RedCap, published on arXiv, records the working targets for the first group as 2 to 4 Mbps, 100 ms latency, 99.99% availability and multi-year battery life. Video surveillance was set at 2 to 25 Mbps with 500 ms latency, and wearables at 5 to 50 Mbps downlink with days-to-weeks battery.

The resulting design principle is subtraction. RedCap is not a new radio; it is the same NR air interface with a deliberately reduced device profile, so it shares the network, the spectrum and the core with ordinary 5G devices. That matters commercially, because an operator or a plant that already runs a 3GPP Release 20 5G-Advanced roadmap does not need a separate network for it, only a gNB software feature and a standalone core.

On the market side, Ericsson reported that the first RedCap products appeared in 2024, that more than ten service providers were trialling it and that commercial service had launched in two markets at the time of its mobility report article. A later industry roundup in August 2025 counted 34 operators in 24 countries investing, with AT&T claiming nationwide RedCap coverage across its standalone footprint reaching over 200 million people. These figures come from vendor and trade sources and move quickly, so treat them as a snapshot.

Two points from the standard shape every deployment decision. First, RedCap and eRedCap are tied to 5G standalone (SA) operation, since the capability signalling and the access control are defined for the 5G core. Second, the plain 3GPP framing is that RedCap complements, rather than replaces, LTE-M and NB-IoT: Ericsson places those two as the lowest tier for massive IoT and RedCap as the “broadband IoT” tier with complexity comparable to LTE categories 2 to 4, while eRedCap aligns with LTE Cat-1 and Cat-1bis.

The RedCap Reference Architecture: What Is Removed and What Remains

In short: RedCap cuts device complexity by limiting bandwidth to 20 MHz in FR1, reducing receive branches to one or two, limiting downlink MIMO layers to match, relaxing downlink 256QAM to optional, and allowing half-duplex FDD. 3GPP estimates this reduces modem cost by roughly 65% in FR1 versus a Release 15 NR device. eRedCap in Release 18 goes further, capping peak rates near 10 Mbps.

Figure 1: Feature reduction path from baseline NR to RedCap in Release 17 and eRedCap in Release 18, with the legacy LTE categories each tier replaces.

The figure shows the lineage as a chain of subtractions. Each arrow is a capability the device no longer needs to implement, and each omission maps to a physical saving in the modem or the radio front end. The long-description version: baseline NR feeds RedCap through bandwidth, antenna, modulation and duplex reductions, and RedCap feeds eRedCap through a peak-rate cap, an optional 5 MHz processing path and a longer inactive-state sleep cycle. RedCap targets customers leaving LTE Cat-4 and Cat-6 modules, and eRedCap targets Cat-1 and Cat-1bis.

Bandwidth, antennas and layers

The headline change is the bandwidth cap. According to the 3GPP technology page and the Ericsson explainer, maximum UE bandwidth falls from 100 MHz to 20 MHz in FR1 and from 200 MHz to 100 MHz in FR2 (millimetre wave). A narrower channel shrinks the analogue-to-digital converters, filters and baseband processing, and lowers sampling rates, which in turn cuts power.

The second change is receive diversity. Baseline NR devices require two to four receive branches. RedCap permits a minimum of one in FR1, and a single branch supports a single downlink MIMO layer, while two branches support two layers. Fewer branches mean fewer low-noise amplifiers, mixers and filters, and fewer antennas to fit into a small device, which is why RedCap is attractive for sensor housings and wearables.

The cost is link performance. Dropping receive diversity costs downlink sensitivity, so a one-branch device sees a smaller effective coverage area on the downlink than a two-branch peer in the same cell. The Release 17 study quantified coverage recovery needs and found them small in most scenarios, with a notable exception in FR2 downlink, where the answer depended on transmit power assumptions of 23 dBm versus 12 dBm. In practice, plant engineers should treat one-branch RedCap as a link budget item, not as a free feature.

Modulation and duplex

Downlink 256QAM in FR1 is mandatory for baseline NR and optional for RedCap, while 64QAM remains required in the FR1 uplink and in FR2. Dropping 256QAM reduces the dynamic range needed from the receiver and its error vector magnitude requirements, and it caps spectral efficiency. Half-duplex FDD, the other optional relaxation, removes the duplexer in paired-spectrum bands, saving cost and board area at the price of not transmitting and receiving simultaneously.

The cost estimate and the peak rate puzzle

The 3GPP Release 17 analysis reports modem complexity reductions of about 65% for FR1 FDD, about 58 to 71% for FR1 TDD depending on receive branches, and about 48% for FR2. The same overview paper summarises it as roughly 65% for FR1 and 50% for FR2. Ericsson adds a more intuitive phrasing: the simplest RedCap modem is about one third the complexity of the simplest ordinary 5G NR modem. These are modem-complexity estimates from the study, not retail price ratios. Module price depends on volume, RF front-end choices, certification and margin.

Peak data rates are where published numbers disagree, and the disagreement is instructive. The Release 17 overview paper states roughly 85 Mbps downlink and 90 Mbps uplink for FR1 frequency-division duplex with 15 kHz subcarrier spacing, and roughly 60 Mbps downlink and 20 Mbps uplink for FR1 TDD at 30 kHz spacing with a 3:1 slot pattern. Ericsson’s later blog gives ranges: 85 to 225 Mbps downlink and 90 to 120 Mbps uplink in FDD, and 50 to 130 Mbps downlink and 35 to 45 Mbps uplink in TDD. Module vendor pages cite figures up to 226 Mbps downlink and 120 Mbps uplink for the best case.

The apparent contradiction dissolves once you note that peak rate depends on receive branches, modulation, subcarrier spacing and, for TDD, the uplink-downlink ratio. The lower numbers describe the simplest one-branch device, and the higher ones describe a two-branch device with 256QAM. The widely repeated “150 Mbps downlink, 50 Mbps uplink” shorthand is a rounded mid-range of that spread, not a single specification value; I could not tie that exact pair to a primary 3GPP source in this research pass, so do not quote it as a spec. For plant design, size on what your chosen module actually reports in its datasheet.

The network side

A RedCap device attaches like any NR UE. It indicates its reduced capability during random access so the gNB can apply the right resource allocation and can optionally bar RedCap devices from cells that do not support them. The Release 17 design also defines separate initial bandwidth part configurations for RedCap, so a 20 MHz device can camp in a carrier of 100 MHz. The network can therefore control RedCap load separately from eMBB traffic, which matters when thousands of sensors share a cell with a handful of high-throughput users.

Figure 2: A plant deployment in which RedCap sensors and cameras connect through a gNB to a standalone core with local user plane breakout feeding an edge gateway and digital twin.

The architecture reads left to right. Field devices carry a RedCap module and talk NR over the air interface to the gNB. The standalone core, drawn below, handles registration and session management and signals RedCap capability. The user plane function sits locally so traffic breaks out onto the plant network, where an edge gateway translates to OPC UA or MQTT for the historian and digital twin. Local breakout is the architectural choice that keeps latency and data residency inside the fence.

Why subtraction beats a new radio

The design choice deserves defending. A purpose-built low-power wide-area radio would have required a new network element, new spectrum planning and new device certification. By constraining the device and not the network, 3GPP kept RedCap inside the existing NR ecosystem. Scheduling, mobility, network slicing, security and the core service-based architecture are inherited. The price is that RedCap inherits NR’s overhead, so it will not reach the battery profile of NB-IoT, which is the reason eRedCap and eDRX exist.

Release 18 eRedCap and the Power Model

Release 18 introduced enhanced RedCap, written eRedCap, under work item NR_redcap_enh (identifier 970080) as described in 3GPP TS 21.918, the Release 18 description document. Complexity study material sits in TR 38.865. The objectives are narrow and specific: restrict peak data rate in both downlink and uplink to 10 Mbps, allow processing capacity of about 25 resource blocks at 15 kHz subcarrier spacing or 12 at 30 kHz (roughly 5 MHz), and extend eDRX in RRC inactive state.

Those three changes aim at one competitor, LTE Cat-1bis, which delivers up to 10 Mbps downlink and 5 Mbps uplink on one receive antenna. If a plant runs thousands of Cat-1bis modules for telematics, metering concentrators or simple cameras, eRedCap is the migration path to 5G SA without paying for RedCap-class silicon.

What eRedCap actually changes

eRedCap devices are restricted to FR1; there is no millimetre wave profile. The 3GPP objective document mentions both one-receive and two-receive eRedCap UEs, so a single antenna is common but not a mandated floor the way some summaries imply. Industry sources also note that the maximum RF bandwidth stays at 20 MHz while the baseband data-channel processing may be limited to about 5 MHz, which is why the same device can sit in a 20 MHz carrier while processing a narrower allocation.

Neither RedCap nor eRedCap supports carrier aggregation or dual connectivity, according to the Ericsson blog. For industrial users this has a practical meaning: a RedCap module will never exceed one carrier’s worth of throughput, and the network cannot bond a second carrier to rescue a poor link.

eDRX: the main power lever

A device that wakes less often burns less energy, and cellular standards govern wake-up with discontinuous reception (DRX). Conventional connected-mode and inactive-mode DRX cycles are short, a few seconds at most. Extended DRX (eDRX) stretches the cycle so a device that reports once an hour need not monitor paging every second.

Release 17 RedCap defined extended DRX in both RRC idle and RRC inactive states. According to the Release 17 overview, idle-state cycles extend to approximately three hours while the inactive state tops out at about 10.24 seconds. The Release 17 paper reports battery lifetime improvement of roughly 10 to 70 times depending on data inter-arrival interval, a range that depends strongly on traffic assumptions and should be read as a scenario result, not a product guarantee.

Release 18 raised the inactive-state cycle to 10,485.76 seconds, approximately 2.9 hours, matching idle. Why does inactive matter? In RRC inactive, the gNB keeps the device’s context so a resume is much faster and lighter than a full re-attach from idle. A sensor that wakes every few minutes benefits from sleeping deeply and still resuming in one round trip.

Figure 3: Device power state flow with the sleep options chosen by the expected time to the next report.

The decision logic in the figure is the part practitioners control through configuration. If the next report is seconds away, standard DRX keeps latency low. If it is minutes to hours away, a long eDRX cycle in inactive state keeps the context at the gNB and avoids signalling storms. If it is hours away and the application tolerates a slower resume, idle with eDRX is acceptable.

A worked, illustrative battery sketch

The numbers below are illustrative, chosen to show the shape of the calculation, not measured values for any module. Assume a sensor that sends a 200-byte report every 10 minutes. Without long sleep, paging monitoring dominates: if the receiver wakes for about 1 ms of every 1.28 s paging cycle, that is roughly 0.08% duty cycle in receive mode at a nominal receive current. With an eDRX cycle of 163.84 s the same monitoring occurs 128 times less often, and the monitoring term nearly vanishes. The transmit burst then dominates, and the lifetime depends on report size, repetition and link quality.

The lesson is that the achievable lifetime is a function of three things the product team can influence: the sleep cycle length, the number of reports, and the coverage condition at the cell edge, where repetitions or higher power inflate each burst. A RedCap module in a good-coverage plant with a 10-minute interval can therefore approach multi-year behaviour, while the same module streaming video cannot.

Relaxed measurements

Release 17 also introduced radio resource management relaxation. When a device is stationary and not at the cell edge, the network may let it reduce neighbour-cell measurements. Fixed industrial sensors are the ideal case: they rarely move, so most of their measurement energy is avoidable. A plant with fixed devices should confirm that the gNB vendor enables the relaxation, since it is network-controlled.

Where the power story stops

RedCap and eRedCap do not match NB-IoT’s coverage extension or its minimal wake-up energy. LTE-M and NB-IoT include mechanisms for deep coverage (Ericsson cites more than 15 dB of enhancement for Cat-M1 and about 20 dB for NB-IoT) and PSM, which lets a device be unreachable for long periods. Cat-M1 and NB-IoT have run in the field since 2016 and 2017 and are mature. Anyone promising ten-year coin-cell life on eRedCap should be asked for a measured, module-specific trace.

Comparing RedCap With LTE-M, NB-IoT, Cat-1bis and Full NR

The industrial buyer’s real question is which radio to specify for each class of endpoint. The answer depends on payload, latency, mobility, coverage, battery life and the network a site can reach. Figures below combine what was verified this run with clearly marked approximations.

Attribute	NB-IoT	LTE-M (Cat-M1)	LTE Cat-1bis	eRedCap (Rel-18)	RedCap (Rel-17)	Full NR eMBB
Channel bandwidth	180 kHz	1.4 MHz	up to 20 MHz	about 5 MHz processing, 20 MHz RF	20 MHz FR1	100 MHz FR1
Peak rate	about 200 kbps	order of 1 Mbps (approximate)	10 Mbps DL, 5 Mbps UL	about 10 Mbps DL and UL	85 to 225 Mbps DL FDD	Gbps class
Core network	LTE or 5GC	LTE or 5GC	LTE	5G SA	5G SA	5G SA or NSA
Relative module cost	lowest	low	low to medium	low to medium, early	medium	highest
Battery profile	best	very good	good	very good	moderate	poor
Mobility and voice	limited	good, VoLTE	good	NR mobility	NR mobility	full
Best fit	meters, trackers	wearables, asset tags	telematics, POS	upgraded Cat-1bis fleets	cameras, gateways	handsets, URLLC

The Cat-M1 peak is shown as approximate because the Ericsson source I fetched did not state it; the order-of-1-Mbps figure matches common vendor documentation, but treat it as unverified here. The other entries come from Ericsson, Telit, 3GPP and vendor material cited in this article.

Figure 4: Selection flow by payload, latency and network availability, with the Cat-1bis fallback when 5G SA or modules are missing.

Reading the matrix

The first discriminator is data rate. If a device sends under 100 kbps and must survive in basements or remote pumps, NB-IoT remains the answer. If it moves, needs voice or wants about a megabit, LTE-M is the match. Above that, the choices tighten.

The second discriminator is the network. RedCap and eRedCap assume 5G standalone. If a site is covered by a public LTE network or an NSA-only footprint, a RedCap module will not attach. Telit’s guidance on eRedCap is blunt on this point: ecosystem maturity and operator support vary, and module availability and global roaming may lag behind Cat-1bis. For multi-country fleets, that single factor often decides.

The third discriminator is determinism. RedCap shares the NR scheduler but does not by itself deliver ultra-reliable low-latency behaviour. The stated Release 17 target for industrial sensors was 100 ms latency at 99.99% availability, which is fine for monitoring and slow control, not for motion loops. For tighter requirements, read the TSN versus 5G URLLC comparison before assuming a reduced-capability radio can carry a control path.

Cost and silicon reality

Standard cost ratios are not retail prices. Even so, direction matters: a simpler modem means a smaller die, fewer RF chains and lower qualification cost, and the 65% FR1 complexity estimate is why module vendors can offer RedCap at a lower price than full NR modules. For eRedCap, the ABI Research view is more cautious than the vendor optimism. Its insight piece describes chipset sampling in 2026, limited-volume shipments in 2027, mass production in 2028, first devices in early 2029 and price parity with LTE around 2031. It also reports that MediaTek will not pursue eRedCap, that UNISOC and ASR are expected to launch products, and that Qualcomm’s status was unclear.

Other sources are more optimistic: a private-network trade piece says eRedCap modules were expected commercially in 2026. These timelines conflict and I could not reconcile them from primary vendor announcements this run. A defensible planning stance is to treat Release 17 RedCap as deployable today, eRedCap as a 2026 to 2028 pilot item, and any volume eRedCap commitment as contingent on named chipset and module availability.

Deploying RedCap in a Plant: Private 5G, Public Networks and Data Flow

Knowing the device profile is half the work. The other half is deciding where the gNB and the core live, because RedCap behaves differently on a private campus network than on a public one.

Private 5G versus public SA

A private 5G network gives the plant control over the scheduler, the uplink-downlink ratio, the slice configuration and the data path. That control is exactly what RedCap needs to be useful for industrial work. TDD frame configuration, for example, changes uplink capacity sharply: the Release 17 overview quotes about 20 Mbps uplink for one-branch FR1 TDD at a 3:1 downlink-heavy pattern, against about 90 Mbps for FDD. A camera fleet is uplink-heavy, so a private network operator can tune the frame pattern toward uplink, which a public operator will not do for one customer.

Public SA offers coverage without capital outlay. Its limits are the operator’s RedCap feature enablement, the uplink pattern it chose for consumers, and local breakout availability. If your use case is a mobile asset that travels between sites, the public path may be the only workable one, and the matching question becomes roaming support for RedCap, which remains uneven.

The best-documented industrial reference in the sources I checked is a Hyundai and Samsung trial reported in early 2025, in which private 5G RedCap replaced Wi-Fi for vehicle inspection systems at Hyundai’s Ulsan plant, which produces about 6,000 vehicles per day, with an expansion planned for an EV plant in the first half of 2026. This is a trade-press account of a trial, not an independent measurement, so it supports the claim that RedCap is being tried in factories, not any specific performance figure.

Capacity planning with a mixed device population

RedCap devices share cells with eMBB users. The Release 17 study ran system simulations and found eMBB user throughput decreases somewhat for median and lower-percentile users when the fraction of RedCap devices is high, with realistic load ratios such as 50 to 1 producing minimal observable effects. The reason is physical: a 20 MHz device occupies a slice of a wider carrier, and a single-layer device uses resources less efficiently than a two-layer one, since it needs more time to move the same bytes.

For a plant, the planning translation is simple. Estimate the aggregate uplink volume of all cameras and gateways, divide by the effective per-device uplink capacity under your TDD pattern and coverage distribution, and keep headroom. As an illustrative calculation, with 40 cameras each producing a 4 Mbps stream, the cell must sustain 160 Mbps of uplink. A TDD pattern that offers 40 Mbps of uplink to a single one-branch RedCap device does not scale to 160 Mbps across 40 devices in one cell; the aggregate is bounded by carrier capacity and scheduler efficiency. This is why camera densification typically needs more carriers, more cells or a higher uplink share, and why aggregate sizing beats per-device peak rates.

Identity, security and slicing

RedCap devices use the same 5G authentication, SUCI-based identity concealment and user-plane encryption options as other NR devices; reduced capability does not mean reduced security. The device is still a SIM-credentialed endpoint, so lifecycle questions about eSIM provisioning, credential rotation and decommissioning apply to every sensor.

Network slicing can separate sensor telemetry from camera traffic and from enterprise voice. A RedCap sensor slice with a low guaranteed bit rate and a modest latency target costs little, while a camera slice can be given an uplink-oriented resource share. Slicing support depends on the core vendor and the SA release, so confirm it during procurement. For industrial teams new to the topic, the 5G core and slicing capability is often a longer lead-time item than the radio.

Data path into the digital twin

A plant’s digital twin consumes time-series and event data. RedCap contributes in three ways. First, it brings sensors that were previously cabled or Wi-Fi-connected into a managed cellular network with SIM identity. Second, it permits visual data, such as inspection images or low-frame-rate video, to be captured at the edge of the line. Third, it provides a device management path via the core for firmware over-the-air updates.

The edge gateway in Figure 2 is where protocol choices matter. RedCap carries IP; it does not define OPC UA or MQTT. A typical pattern uses MQTT or OPC UA PubSub from the sensor, local breakout at the UPF, and a gateway that normalises to the twin’s information model. Keeping that layer independent of the radio means a later move from RedCap to eRedCap, or from private to public, does not require rewriting the data model.

Where ambient IoT and RedCap meet

Lower still than eRedCap, Release 19 and 20 work on ambient IoT targets battery-free or energy-harvesting tags that backscatter or harvest from a reader. Those devices serve inventory and asset tracking at a different cost and data-rate point than RedCap. The ambient IoT comparison of Release 19 and 20 explains how it complements, rather than competes with, RedCap: ambient tags identify and locate, RedCap devices report and stream.

Within RedCap itself, a trade article reports that Release 19 added three work items: NR non-terrestrial network operation for satellite connectivity, a Power Class 2 RedCap profile for higher uplink transmit power, and RedCap management support in operations and maintenance. Release 20 content is covered in the sibling article on 5G-Advanced and RedCap in Release 20. I verified the Release 19 list from one secondary source only, so confirm against the 3GPP work item list before building roadmaps on it.

Migration from Cat-1bis and Cat-4

Teams with installed LTE fleets face a sequencing question. The Cat-1bis modules that dominate telematics today will outlive many sunset debates, and LTE networks remain in service for years. A pragmatic path is dual-mode modules, which Ericsson notes are easier because eRedCap aligns with Cat-1 and Cat-1bis. A device with an LTE fallback attaches on 5G SA where available and falls back to LTE elsewhere, which removes the roaming risk at the cost of some module price and certification effort.

For Cat-4 and Cat-6 users such as gateways and routers, RedCap is the natural step. The throughput of 85 Mbps and above on a single receive branch is in the Cat-4 range, while power and heat fall compared with a full NR modem. The migration blockers are less about physics than about operator SA footprint, certification and, for private networks, the availability of RedCap-capable gNB software from the radio vendor.

Trade-offs, Gotchas, and What Goes Wrong

The most common failure is assuming RedCap works on any 5G network. A non-standalone network anchored on LTE will not serve a RedCap device. Check the operator’s SA coverage and the RedCap feature flag in the specific market, not the headline 5G map.

The second failure is treating peak rate as a sizing number. As described earlier, the published peaks span a factor of about two to three depending on configuration. A sensor design that quietly depends on the high end will miss on a one-branch TDD device whose uplink may be a few tens of Mbps at best, and far less at the cell edge.

The third is battery expectations. eDRX lowers paging cost, but RedCap still carries NR’s signalling and a larger radio than LTE-M. The result is a lifetime between a Wi-Fi sensor and an NB-IoT tag, and the actual figure depends on measured firmware behaviour. Validate with a power analyser on the real module, including connection setup, not just sleep current.

The fourth is coverage. Single receive branch devices lose downlink sensitivity, and RedCap has no equivalent of the deep-coverage repetition schemes in LTE-M and NB-IoT. Sensors in shielded locations, such as inside cabinets, tanks or basements, may need an indoor small cell or a different radio.

The fifth is ecosystem lag for eRedCap. If the procurement plan names eRedCap modules with a ship date, request a certification status and a named operator list. The ABI timeline suggests volume well after pilots, and a plant that bets a rollout on a 2026 module date takes schedule risk.

The sixth is mixing determinism with reduced capability. RedCap does not carry the ultra-reliable low-latency feature set as a design goal, and Release 17 targets for sensors were 100 ms and 99.99% availability. Closed-loop control, safety functions and motion synchronisation need a different design; see the earlier comparison of wired time-sensitive networking and 5G URLLC.

Finally, a procurement trap: “5G module” on a datasheet often means the full NR profile. Verify that the module declares RedCap capability and the band list the target operator or private spectrum requires, since private-network bands such as local licences vary by country.

Practical Recommendations

Start by classifying endpoints, not technologies. Group devices by payload, report interval, mobility and coverage condition. Most plants find three groups: tiny periodic sensors, gateways and cameras, and a small set of control-critical devices.

Assign radios per group. Keep NB-IoT or LTE-M for the tiny periodic sensors in poor coverage. Use RedCap for gateways, cameras and handhelds where rates of 5 to 100 Mbps are needed. Pilot eRedCap for fleets now on Cat-1bis, but gate volume on named module availability. Keep wired TSN or full NR URLLC for control paths.

Prove the network before the device. Confirm standalone core availability, RedCap feature enablement on the gNB, uplink TDD pattern, and local breakout. Then prove the device with a bench and a field trial, measuring throughput at the cell edge and current draw per report cycle.

Checklist before committing to a RedCap rollout:

• Confirm the operator or private core runs 5G SA and enables RedCap access.
• Obtain module datasheets with measured, not theoretical, peak rates and sleep current.
• Choose the TDD uplink share to match your camera or gateway uplink volume.
• Enable and test RRM relaxation and eDRX settings on the gNB for fixed devices.
• Run a cell-edge test for single-branch devices in the worst-covered location.
• Plan an LTE fallback or dual-mode module where roaming matters.
• Keep the data model independent of the radio through an edge gateway.
• Gate eRedCap volume on certified module and operator support.

Frequently Asked Questions

What is 5G RedCap and how is it different from regular 5G?

RedCap, for Reduced Capability, is a 3GPP Release 17 device profile of 5G NR that cuts complexity for mid-tier IoT. Compared with a baseline NR device it limits FR1 bandwidth to 20 MHz, requires only one receive branch, limits downlink MIMO layers to match, makes downlink 256QAM optional and allows half-duplex FDD. It uses the same network and spectrum, but needs 5G standalone, and 3GPP estimates roughly 65% lower modem complexity in FR1.

What is the difference between RedCap and eRedCap?

eRedCap, standardised in Release 18, is a further reduction aimed at replacing LTE Cat-1 and Cat-1bis. It caps peak rate near 10 Mbps in both directions, allows processing of roughly 5 MHz (about 25 resource blocks at 15 kHz spacing), is limited to FR1, and extends RRC inactive eDRX to 10,485.76 seconds. RedCap in Release 17 offers tens to a couple of hundred Mbps depending on configuration and a shorter inactive eDRX of about 10.24 seconds.

Does 5G RedCap replace LTE-M and NB-IoT?

No. 3GPP and Ericsson position RedCap as a broadband IoT tier above LTE-M and NB-IoT, which stay the choice for very low data rates, deep coverage and the longest battery life. LTE-M and NB-IoT offer coverage enhancement of more than 15 dB and about 20 dB respectively according to Ericsson, plus mature PSM and eDRX. RedCap fits cameras, gateways and wearables, and eRedCap fits fleets now on Cat-1bis.

Can RedCap run on a private 5G network?

Yes, provided the private network runs a standalone core and the radio vendor’s gNB software supports RedCap. Private networks suit RedCap well, since the operator can tune the TDD uplink share for camera traffic and break traffic out locally. A Hyundai and Samsung trial reported in early 2025 used private 5G RedCap at the Ulsan plant for inspection systems in place of Wi-Fi. Confirm band and certification support in your country.

How long can a RedCap device sleep to save power?

Release 17 RedCap supports extended DRX in RRC idle with cycles up to about three hours, and in RRC inactive up to about 10.24 seconds. Release 18 raises the inactive-state limit to 10,485.76 seconds, around 2.9 hours. The Release 17 overview reports battery lifetime gains of 10 to 70 times depending on traffic interval. Actual life depends on report size, coverage and firmware, so measure the specific module.

Is eRedCap commercially available in 2026?

Availability is uncertain and sources disagree. One trade source says eRedCap modules were expected commercially in 2026, while ABI Research projects chipset sampling in 2026, limited shipments in 2027 and mass production in 2028. Telit warns that module availability and roaming may lag Cat-1bis. Treat eRedCap as a pilot item and require named chipset, module and operator support before committing volume.

Further Reading

• 3GPP Release 20 and 5G-Advanced: RedCap for industrial IoT covers the roadmap beyond Release 18.
• Ambient IoT in 3GPP Release 19 versus Release 20 covers the battery-free tier beneath eRedCap.
• TSN versus 5G URLLC for deterministic networking covers when reduced capability is not enough.
• 3GPP: NR RedCap overview, the standards body’s technical summary.
• Ericsson: RedCap and eRedCap and the arXiv paper Toward Smaller and Lower-Cost 5G Devices with Longer Battery Life.

By Riju — about