Skip to content

5G UE Category

Summary
  • 5G NR does not have a "UE Category" system like LTE's — there's no ue-Category field, no Cat 1/Cat 4/Cat 16 numbering. 3GPP deliberately dropped that model for NR.1
  • Instead, a UE reports detailed capabilities per band and per band combination, and the network (or anyone else) computes the actual peak data rate from those reported parameters using a formula defined in TS 38.306.1
  • The closest thing NR has to a device "tier" is RedCap (Reduced Capability) — a defined complexity class introduced in Release 17, covered in full below — but still not a single enumerated number the way LTE categories were.

Think of it as:

"LTE handed out pre-set trim levels — Cat 4, Cat 6, Cat 16. NR hands you a spec sheet and a calculator instead — except for one device class, RedCap, which got a real bounded tier after all."

If you are confused...

Coming from the LTE UE Category page expecting an NR equivalent table? That's exactly the point of this page — there isn't one, and the section below explains why. The capability signaling itself happens over RRC's UECapabilityEnquiry/UECapabilityInformation, which you've already seen on the RRC page without knowing this is what feeds it.

Why NR Doesn't Have "Cat 1, Cat 4, Cat 16..."

LTE's category numbers started clean but strained hard as data rates grew — Category 8 topped out around 3 Gbps using an 8-layer, massively-aggregated configuration that was never realistic to actually build, and 3GPP kept having to bolt on new categories (9, 10, 11... eventually past 20) just to describe increasingly specific combinations of layers, modulation, and carrier aggregation.2

For NR, 3GPP took a different approach entirely: instead of pre-defining a fixed list of "categories," a UE reports the actual parameters that determine its capability — how many MIMO layers, what modulation order, which bands and band combinations, how much bandwidth — and the peak data rate becomes something anyone can compute directly from those numbers, rather than something you look up in a table by category name.1

How NR Capability Signaling Actually Works

A UE's capabilities are structured around bands and band combinations, not a single number:

  • For each supported band, the UE reports a Feature Set — the specific parameters (max layers, max modulation, bandwidth classes) it supports on that band.
  • For combinations of bands (carrier aggregation, dual connectivity), the UE reports a Feature Set Combination, since capability on band A when aggregated with band B isn't necessarily the sum of each band's standalone capability.1

This is genuinely more information than a single LTE category number ever carried — which is exactly why NR moved to a formula instead of a lookup table. All of this is exchanged the same way any other RRC capability exchange happens: UECapabilityEnquiry from the network, UECapabilityInformation back from the UE.1

Peak Data Rate Formula

TS 38.306 Clause 4.1.2 defines the approximate maximum data rate for a given band or band combination:1

\[ \text{data rate (Mbps)} = 10^{-6} \cdot \sum_{j=1}^{J} \left( v_{Layers}(j) \cdot Q_m(j) \cdot f(j) \cdot R_{max} \cdot \frac{N_{PRB}^{BW(j),\mu} \cdot 12}{T_s^{\mu}} \cdot \left(1 - OH(j)\right) \right) \]
Variable Meaning
\(J\) Number of aggregated component carriers in the band/band combination
\(v_{Layers}(j)\) Max MIMO layers for CC \(j\) (maxNumberMIMO-LayersPDSCH for DL)
\(Q_m(j)\) Max modulation order for CC \(j\) (e.g., 8 for 256-QAM)
\(f(j)\) Scaling factor the UE reports — one of 1, 0.8, 0.75, or 0.4
\(R_{max}\) Fixed at 948/1024
\(N_{PRB}^{BW(j),\mu}\) Number of PRBs for CC \(j\)'s bandwidth at numerology \(\mu\)
\(T_s^{\mu}\) Average OFDM symbol duration: \(10^{-3} / (14 \cdot 2^{\mu})\)
\(OH(j)\) Overhead — 0.14 (FR1 DL), 0.18 (FR2 DL), 0.08 (FR1 UL), 0.10 (FR2 UL)

Table 1. TS 38.306 peak data rate formula variables

There's still a floor

NR isn't purely open-ended at the bottom either — for single-carrier SA operation, a UE must support a data rate no smaller than what this formula gives with \(J=1\) and \(v_{Layers} \cdot Q_m \cdot f\) no smaller than 4. That's the closest thing NR has to a minimum "Cat 1"-style baseline.1

Worked example: a single 100 MHz FR1 carrier, 4-layer MIMO, 256-QAM

Plugging in \(v_{Layers}=4\), \(Q_m=8\) (256-QAM), \(f=1\), \(N_{PRB}=273\) (100 MHz at 30 kHz SCS), \(\mu=1\), and \(OH=0.14\) (FR1 DL):

  • \(T_s^1 = 10^{-3}/(14 \times 2) = 3.571 \times 10^{-5}\) s
  • \(N_{PRB} \times 12 = 273 \times 12 = 3{,}276\) subcarriers
  • \(3{,}276 / T_s^1 = 91{,}728{,}000\)
  • \(\times\ v_{Layers}(4) \times Q_m(8) \times f(1) = 2{,}935{,}296{,}000\)
  • \(\times\ R_{max}\ (948/1024) \approx 2{,}717{,}442{,}000\)
  • \(\times\ (1-0.14) \approx 2{,}337{,}000{,}000\)
  • \(\times\ 10^{-6} \approx \mathbf{2{,}337\ Mbps} \approx \mathbf{2.3\ Gbps}\)

Stack more component carriers (higher \(J\)) or wider FR2 bandwidths on top of this, and this is exactly how vendors get to the multi-Gbps marketing numbers you see for flagship devices — it's this same formula, summed across every aggregated CC.

RedCap: The Closest Thing NR Has to a "Tier"

RedCap (Reduced Capability) is a class of simplified, lower-cost 5G NR device introduced in 3GPP Release 17 — also known by its earlier working name, NR-Light. Unlike everything above, RedCap isn't a formula output — it's a named, bounded device class the way an LTE category number used to be, just scoped to one specific mid-tier IoT use case rather than the entire device landscape.

If you are confused...

RedCap is a great bridge between the two halves of this site. Everything about how a RedCap UE gets on the network — SSB, RACH, RRC — is exactly what's already covered, just with a few RedCap-specific twists described below (especially in Identifying a RedCap UE). And once connected, a RedCap wearable or industrial sensor is precisely the kind of device that would then speak MQTT to report its readings.

Why RedCap Exists

RedCap Positioning Between mMTC and eMBB/URLLC

Figure 1. RedCap Positioning Between mMTC and eMBB/URLLC4

It exists to fill a real gap: Releases 15/16 were built around eMBB (high throughput) and URLLC (ultra-low latency), leaving a wide middle ground of IoT devices poorly served — too demanding for LTE-M/NB-IoT, but massive overkill (and massively over-cost) for a full eMBB modem.3 Three reference use cases drove the design:3

Use Case Data Rate Latency Battery Life
Industrial Wireless Sensors Low (as little as a few kbps, up to ~2 Mbps) Moderate, but often deterministic Very long — years, sometimes non-rechargeable
Video Surveillance Moderate (roughly 2–7.5 Mbps for economy-grade video) Low-ish Often mains-powered, less battery-critical
Wearables Moderate to fairly high (bursty, up to tens of Mbps) Low-ish Days to weeks, small form factor matters a lot

Table 2. RedCap Use Cases

None of these fit cleanly into what already existed: LTE-M/NB-IoT are cheap and efficient but too slow and too high-latency for video or richer wearables; a full eMBB NR modem hits every requirement but at a cost, size, and power budget none of these devices can justify.3

Complexity Reductions

RedCap doesn't change the air interface itself — a RedCap UE is still speaking NR. What changes is how much of the full NR device capability it's required to implement:4

Parameter RedCap Full NR (eMBB)
Max UE bandwidth 20 MHz (FR1), 100 MHz (FR2) Substantially wider (up to 100s of MHz, band-dependent)
Min Rx antenna branches 1 (FR1), 2 (FR2) 2 or 4 (FR1, band-dependent)
Max DL MIMO layers 1 (with 1 Rx branch) or 2 (with 2 Rx branches) Typically 2–4+
Tx antenna branches 1 (no UL MIMO) Can be more than 1
Carrier Aggregation / Dual Connectivity Not supported Supported
Duplex mode Half-Duplex FDD (HD-FDD) allowed in all bands Typically full-duplex FDD or TDD
Peak data rate Up to 226 Mbps DL / 120 Mbps UL Multi-Gbps

Table 3. RedCap Limitations

A RedCap UE doesn't have to use every reduction

These are ceilings, not requirements — a RedCap device only needs to implement the reductions that actually help it. A mains-powered surveillance camera, for example, might keep full-duplex operation since its cost/complexity budget cares more about sustained throughput than about removing a duplexer.5

Half-Duplex FDD deserves a special mention: a normal FDD device needs a duplexer (or equivalent isolation) to transmit and receive at the same time on paired frequencies — one of the more expensive RF components in a device. Allowing HD-FDD everywhere means a RedCap device can simply switch between transmit and receive instead, cutting real bill-of-materials cost.4

Identifying a RedCap UE

Since RedCap and legacy NR UEs share the same cell, the network sometimes needs to know which kind of UE it's talking to as early as possible — for example, to schedule Msg2/Msg4 differently to compensate for a RedCap UE's coverage loss from fewer Rx antennas. 3GPP defined two points where this can happen:56

  1. Msg1 (earliest possible) — if the cell's SIB1 configures a separate pool of PRACH resources (occasions and/or preambles) reserved for RedCap, a RedCap UE selects from that pool for its Msg1 preamble. The gNB now knows it's dealing with a RedCap UE before Msg2 is even sent.
  2. Msg3 (fallback) — if no separate PRACH resources exist, identification happens one step later: a RedCap UE uses a reserved LCID value (35 or 36) in the MAC subheader of its Msg3 CCCH transmission, letting the gNB recognize it from that field alone.
Why does this matter enough to build into RACH itself?

Fewer Rx antennas measurably shrinks a device's downlink coverage — without correction, a RedCap UE could successfully transmit Msg1 but then fail to reliably receive Msg2 or Msg4. Knowing "this is a RedCap UE" as early as possible lets the network apply coverage-recovery techniques (extra repetitions, more conservative MCS, higher aggregation levels) exactly where they're needed, rather than discovering the problem only after the UE was already treated like any other NR device.6

Full, explicit capability information still comes later, the same way it does for any NR UE — via UECapabilityEnquiry/UECapabilityInformation on the RRC message catalog — but by that point the network has typically already been scheduling the UE as RedCap for one or two full round trips.

RedCap vs. the Rest of the Family

NB-IoT / LTE-M RedCap eMBB (full NR)
Positioning Low-end mMTC Mid-tier IoT High-end broadband
Typical data rate Low (kbps range) Moderate (up to ~226/120 Mbps) Very high (multi-Gbps)
Device complexity/cost Lowest Reduced, but NR-native Highest
Introduced Release 13 (LTE) Release 17 (NR) Release 15 (NR)

Table 4. RedCap vs. the Rest of the Family

RedCap isn't meant to replace NB-IoT/LTE-M — some existing low-end use cases are already served perfectly well by those — it's meant to catch everything that needs more than mMTC can offer but doesn't need a full eMBB modem to get it, while still living natively on the NR radio.3

RedCap's Declared Peak Rates

Even RedCap's declared peak rates come from the exact same formula covered above — they're just what you get when you plug RedCap's capped parameters (1–2 layers, 20 MHz max bandwidth, no CA) into it instead of a flagship device's:

Device Class Peak DL Peak UL Introduced
RedCap Up to 226 Mbps Up to 120 Mbps Release 17
eRedCap ~10 Mbps ~10 Mbps Release 18

Table 5. RedCap and eRedCap declared peak rates — the same TS 38.306 formula, just bounded by RedCap's own complexity limits7

Compare that against the worked example above — RedCap's 226 Mbps ceiling versus the ~2,337 Mbps a single unconstrained 100 MHz carrier produces from the identical formula is the entire RedCap story in one number.

eRedCap: Release 18

eRedCap (enhanced RedCap), introduced in Release 18, pushes the complexity reduction further still — a single Rx antenna becomes mandatory (rather than just a minimum), and peak data rate is capped at roughly 10 Mbps in both directions, trading throughput for even lower device cost and power consumption.7 It's aimed squarely at the lower end of RedCap's own target range — cheaper industrial sensors and simpler wearables that don't need RedCap's full headroom.

Power Class

Separately from data rate, NR devices also declare a Power Class — how much transmit power they're capable of, expressed in dBm (FR1, conducted) or EIRP (FR2, radiated). This is a genuinely different capability axis from anything covered above: a high-Power-Class device isn't necessarily higher throughput, just capable of transmitting harder — relevant for coverage and uplink range rather than peak Mbps.8 It isn't covered in depth on this page; see the ShareTechnote link below for the full class breakdown.

Useful Resources

  1. 3GPP. (n.d.). User Equipment (UE) radio access capabilities (Technical Specification TS 38.306). 3rd Generation Partnership Project. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3193 ↩↩↩↩↩↩↩

  2. Devopedia. (n.d.). 5G UE data rate. https://devopedia.org/5g-ue-data-rate ↩

  3. 3GPP. (n.d.). A glimpse into RedCap NR devices. 3rd Generation Partnership Project. https://www.3gpp.org/technologies/nr-redcap-glimpse ↩↩↩↩

  4. Ryu, J. (n.d.). 5G/NR – NR-Light/RedCap. ShareTechnote. https://www.sharetechnote.com/html/5G/5G_NR_Light.html ↩↩↩

  5. Rohde & Schwarz. (n.d.). Reduced capabilities (RedCap) – a new class of 5G devices [White paper]. https://cdn.everythingrf.com/live/RedCap_R_S_WP23_638230922418792637.pdf ↩↩

  6. 3GPP. (n.d.). Study on support of reduced capability NR devices (Technical Report TR 38.875). 3rd Generation Partnership Project. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3646 ↩↩

  7. 3GPP. (n.d.). RedCap/eRedCap – standardizing simplified 5G IoT devices [Partner article, originally published by Ericsson]. https://www.3gpp.org/news-events/partner-news/redcap-gsa-article01 ↩↩

  8. Ryu, J. (n.d.). 5G/NR – Power Class. ShareTechnote. https://www.sharetechnote.com/html/5G/5G_PowerClass.html ↩