RedCap (Reduced Capability)¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain that RedCap is not a "service" but a device category (type) with reduced UE capability.
• Explain that RedCap was created with the aim of filling the gap between eMBB and mMTC/NB-IoT.
• List an overview of the main radio capabilities that are reduced in RedCap (bandwidth, antennas, MIMO, etc.).
• Understand that RedCap is mainly a radio-side (RAN/UE) concept and does not change the 5GC architecture itself.
• Be aware of the existence of the evolved form eRedCap (Rel-18).

Prerequisites¶

It will be easier to read if you have a light grasp of the big picture of mobile networks and the concept of "UE Capability" — how a UE (device) reports its own capabilities to the network. For the context of UE capability negotiation, see Registration; for the context of distinguishing device types in the network, see Network Slicing.

What you'll learn in this chapter¶

• Why — why a "capability-reduced" device category became necessary.
• Basic Concept — understanding RedCap through a familiar analogy.
• Features of RedCap — what is reduced (overview table).
• Comparison with a normal UE — the differences from a full-capability NR UE.
• Impact on the 5GC — how RedCap is handled from the core side (briefly).
• EPC / Release differences — the relationship with LTE's Cat-M/NB-IoT, up to eRedCap.

Why — why RedCap is necessary¶

5G has two extreme ways of being used. On one end is eMBB (enhanced Mobile Broadband, high speed and high capacity), for use cases such as smartphones and high-definition video, where you want to carry as much as possible, as fast as possible. On the other end are mMTC (massive Machine Type Communications) and NB-IoT, for use cases such as water meters, where you want to carry tiny amounts of data occasionally, at ultra-low power and low cost.

In reality, however, there are many devices that fall right in the middle of these two extremes — for example wearables, industrial sensors, video surveillance cameras, and smart-grid equipment. These have mid-tier requirements: "they don't need the high performance of a smartphone, but NB-IoT doesn't have enough capability." Using a full-capability NR UE as-is makes the chip expensive, large, and power-hungry, which is unsuitable for mass-produced IoT.

So in Rel-17, 3GPP defined a device category that intentionally trims the UE's capability to make it low-cost, low-power, and compact. This is RedCap (Reduced Capability). In the early days of standardization it was also called "NR-Light."

Overview¶

The key points of RedCap boil down to the following three.

• A device type, not a service — RedCap does not refer to a "new communication service" but to a category of UE with reduced capability. It is different in nature from a procedure (service) such as VoNR.
• Filling the middle — In terms of performance, cost, and power consumption, it targets the space between eMBB (high performance) and mMTC/NB-IoT (ultra-low speed, ultra-low power).
• Mainly a radio-side concept — What is reduced is mainly the capability of the radio access (RAN/UE). It does not change the architecture of the 5GC (core) itself.

Basic Concept — an explanation for beginners¶

An analogy with car trims¶

RedCap is similar to a car trim (a budget grade).

• eMBB UE = a fully-equipped top grade. The engine and equipment are top-of-the-line, and the price is high (= a high-performance smartphone).
• NB-IoT / mMTC = an ultra-compact kei car. Cheap above all and fuel-efficient, it can only carry a little cargo (= a water meter, etc.).
• RedCap UE = a sufficient standard grade. It omits the equipment of the top grade, but is more broadly usable than a kei car (= wearables, sensors, video surveillance cameras).

It can still drive on the same "road called NR." But RedCap is like a car that has been made cheaper and lighter by deliberately removing equipment it doesn't use. What is removed is mainly "the amount it can carry at once (bandwidth)," "the number of antennas," and "the number of lanes it can run at once (MIMO layers)."

What is "trimmed" is radio capability¶

The important point is that what RedCap trims is mainly the capability of the radio section. From the point of view of the core network (5GC), a RedCap UE registers and connects with the same procedures as a normal UE. The 5GC can identify "this is RedCap" by looking at the received UE capability information, but there is no need to rebuild the core's basic structure.

Features of RedCap — what is reduced¶

The main radio capabilities that are reduced or relaxed in RedCap are as follows. Specific values are defined in the 3GPP specifications (mainly the TS 38.306 / TS 38.331 series), but you must confirm the exact values and clause numbers in the primary specifications (to be confirmed).

Through these reductions, a RedCap UE keeps chip area, cost, and power consumption low while securing higher throughput than NB-IoT and affinity with 5G NR features (such as slicing).

Comparison with a normal UE (full-capability NR UE)¶

They coexist on the same NR network, but it is easier to organize things if you regard RedCap as a category committed fully to being "just sufficient."

Impact on the 5GC — RedCap seen from the core¶

RedCap is mainly a radio-side concept, but there are several touchpoints on the 5GC side as well (the details are largely implementation-dependent, so they are to be confirmed).

• Identification — The 5GC may identify that a UE is RedCap based on the UE capability information obtained at registration and so on (the identification method and scope of use are implementation/configuration-dependent, to be confirmed).
• Distinction in slicing / policy / charging — There is room to bundle groups of RedCap devices with Network Slicing, or to distinguish them from normal UEs in policy or charging (how far to distinguish them is up to the operator's implementation, to be confirmed).
• The architecture is unchanged — There is no need to rebuild the 5GC's NF configuration or reference points themselves in order to support RedCap. It is simply a matter of "accommodating capability-reduced UEs."

In summary, understand RedCap as being of the nature "the existing 5GC accommodates capability-reduced UEs as-is," not "rebuilding the core."

Comparison with EPC (low-capability devices in the LTE era)¶

In the LTE/EPC era there were also categories for low-capability devices. Representative examples are LTE-M (Cat-M1) and NB-IoT. These were mainly for low-speed, low-power IoT. It is easier to understand if you regard RedCap as filling the mid-tier band above these, within the framework of 5G NR (the exact performance boundaries and category correspondence are to be confirmed).

graph LR
    A["eMBB
High speed, high capacity
(smartphone/FWA)"] --- B["RedCap
Mid-tier, cost-saving
(wearable/sensor/video surveillance camera)"]
    B --- C["mMTC / NB-IoT
Ultra-low speed, ultra-low power
(meters, etc.)"]

How to read the diagram: the further left, the higher the performance and cost; the further right, the lower the speed, power, and cost. RedCap is the device type that fills the middle.

Release differences¶

• Rel-17 — Introduced RedCap (Reduced Capability, NR-Light). Defined a mid-tier device category with reduced UE capability.
• Rel-18 — eRedCap (enhanced RedCap) was discussed and introduced, aimed at devices with capability reduced even further (further lower cost and lower peak rate). However, the specific reductions and values are to be confirmed.

3GPP Specification¶

Since RedCap is mainly a radio-side (RAN/UE capability) concept, the references center on the following series. You must confirm the specific clause numbers and values in the primary specifications (to be confirmed).

FAQ¶

Q. Is RedCap a new "service"? A. No. RedCap is a category (device type) of UE with reduced capability. It is different in nature from a "procedure/service" such as VoNR; it is a classification that expresses "what kind of device it is."

Q. Do I need to rebuild the 5GC in order to use RedCap? A. Basically no. What is reduced is mainly the radio-side capability, and the 5GC accommodates RedCap UEs within its existing framework. There is room to distinguish them in slicing, policy, and charging, but that too is implementation-dependent (to be confirmed).

Q. What is the difference from NB-IoT? A. NB-IoT/mMTC are for extreme, ultra-low-speed, ultra-low-power capability-saving devices. RedCap targets a mid-tier band with higher performance than that, suited to wearables, sensors, video surveillance cameras, and so on.

Q. I sometimes see the term "NR-Light" — is it the same as RedCap? A. Yes. "NR-Light" was the name used in the early days of standardization, and the official name is RedCap (Reduced Capability). They refer to the same thing.

Q. What is eRedCap? A. It is enhanced RedCap, discussed and introduced in Rel-18, an evolved form targeting devices with capability reduced even further than RedCap. The details are to be confirmed.

Summary¶

• RedCap (Reduced Capability, NR-Light) is a device category of UE with reduced capability (not a service), introduced in Rel-17.
• The aim is to fill the gap between eMBB and mMTC/NB-IoT. It is for mid-tier IoT such as wearables, industrial sensors, and video surveillance cameras.
• What is reduced is mainly radio capability (bandwidth, number of receive antennas, MIMO layers, modulation order, allowing half-duplex FDD, etc. Specific values are to be confirmed).
• The 5GC architecture itself is not changed. It is identified by UE capability and may be distinguished in slicing/policy/charging (implementation-dependent, to be confirmed).
• In Rel-18, further capability reduction was discussed and introduced as eRedCap (to be confirmed).

Practice — comprehension check and exercises¶

Comprehension check¶

Exercises¶

• Pick three devices around you and, with reasons, try to place each into "eMBB / RedCap / NB-IoT" (e.g., smartwatch → RedCap, water meter → NB-IoT).
• In one or two sentences, try to explain how trimming "bandwidth" or "the number of antennas" in RedCap affects cost, power consumption, and throughput.

Next Step¶

• Network Slicing — learn the context of bundling / distinguishing groups of RedCap devices with slices.
• Registration — learn the context of UE capability negotiation (the clue by which the 5GC identifies RedCap).
• VoNR — a "procedure/service-type" chapter in the same Level 4. Understand it by contrasting it with a device type.