What is REDCAP (Reduced Capability) in NR 3GPP R17 Release?

3GPP NR Release 17

3GPP NR releases 17 comes with a lot of new enhancements in R16 features and added new features like 5G NR light Redcap (Reduced Capability) feature, NTN, Spectrum Expansion, and Coverage Enhancement, which can be considered

As good use cases for end users and the wireless industry. Below is the snapshot from 3GPP Release 17 major feature enhancement.

One of the major features of R17 is Redcap (Reduced Capability) feature is known as an indispensable piece of cake for the 5G Internet of Things where we need less capability, less bandwidth, and long battery life. It’s also called the NR light version; it is a part of NR(5G) only but with different capabilities. 5G NR light Redcap (Reduced Capability) feature brings a lot of new opportunities and enhancement of IoT devices, industrial use cases, and medical equipment, and helps to make the smart city.

NR light Redcap devices have small in size but have long battery life, and the throughput of Redcap devices makes them a good choice for many mobile consumer applications as well, such as high-end smartwatches, health monitors, broadband access for entry-level devices like tablets and smartphones, and boundless augmented reality (AR) glasses.

Due to the designed optimizations, Redcap NR-Light devices can efficiently support 150 Mbps downlink and 50 Mbps in the uplink. As we know eMBB NR use case supports 100mhz bandwidth we can achieve downlink and uplink throughput in Gigabytes 10 Gpbs, but Redcap NR light devices are capable of less throughput and only support 20MHZ bandwidth for FR1 and 100MHZ throughput for FR2.

Let’s discuss the use case of 5G NR light Redcap feature:

In the R17 version, Redcap mainly supports the following use cases:

Industrial sensors: Industrial pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, actuators, etc.

Surveillance Cameras: Applications in Smart Cities, Factories and Other Industrial Sites.

Wearable devices: smart watches, electronic health-related equipment, medical monitoring equipment, AR/VR glasses, etc.

In the R18 version, Redcap will further reduce the complexity of the terminal, support a wider range of rates, and may increase the ability to support positioning, sideline protocols, and unlicensed spectrum to support more use cases.

NR Light Redcap and NR(5G) Difference in Capabilities

Also Read:- What is NCD-SSB and CD-SSB in REDCAP NR R17?

Some high-layer 5G NR light Redcap UE capabilities:

-5G NR light Redcap UEs can support 16DRBs (as normal NR UE) but mandatory support for REDCAP UE is 8DRBs only as per 3GPP Specs R17.

-REDCAP UEs can optionally support 18-Bit PDCP/RLC sequence numbers but mandatory support is 16 Bit PDCP/RLC sequence numbers as per 3GPP Specs R17.

– REDCAP UEs can support Automatic Neighbor Relation (ANR) but it’s not mandatory as per 3GPP specs R17.

-REDCAP UE does not support CA and DC.

– REDCAP UEs mandate to support DCI format 0_0/0_1 and support for DCi 2_0/2_1 is optional.

-The number of RX branches for REDCAP is implicitly indicated by the corresponding capability parameter maxNumberMIMO-LayersPDSCH in the exiting UE capability framework.

What are the Key Technologies?

There are two main key technologies on which REDCAP mainly focused i.e., eDRX (Extended DRX in RRC idle and inactive state), Optimization of PDCCH Monitoring Adaptation, and RRM Measurement Relaxation for neighbor cells both energy-saving technologies that can extend battery life in R17.

eDRX (Extended DRX in RRC idle and inactive state)

In NR(5G) we can save maximum UE Power via DRX cycle in RRC_IDLE and RRC_INACTIVE states 2.56 seconds. With the help of the Redcap eDRX mechanism, which, as the name implies, is an extended DRX mechanism, which extends the DRX cycle in the RRC_IDLE state to 10485.76 seconds (about 3 hours) and extends the DRX cycle in the RRC_INACTIVE state to 10.24 seconds, so that the network sleeps time increase, more power efficient, and longer battery life.

Optimization of PDCCH Monitoring Adaptation

With the help of PDCCH Monitoring Adaptation can save the UE power DCI-based power saving adaption in Connected mode which includes PDCCH skipping and SSSG Search Space Switching.

RRM Measurement Relaxation for neighbor cells

In R16 NR 5G RRM measurement relaxation mechanism is designed for the non-cell-edge and low-speed mobile scenarios. When the low-rate condition is met for a certain period of time or the low-rate and non-cell-edge conditions are met at the same time, the device is allowed to relax adjacent cell measurements.

For example, by increasing the RRM measurement period to reduce the number of neighboring cell measurements and the number of cell measurements, thereby reducing terminal power consumption.

In the R17 version, RRM measurement relaxation was introduced as the optional feature for 5G NR light Redcap UEs which can be enabled by the network. RRM the relaxation time is further extended for Redcap in RRC IDLE/Inactive states.

In the RRC-IDLE and RRC_INACTIVE states, the network will frequently perform RRM (radio resource management) measurements to ensure that the terminal resides in the best available cell. The RRM measurement mainly measures the RSRP and RSRQ values ​​of the serving cell and neighboring cells.

The RRM measurement, while ensuring the best possible connection quality for the endpoint, will drain the battery even when there is no data transmission between the endpoint and the network.

As off now we discuss what is R17, what new enhancement is R17, what is REDCAP, REDCAP UEs capability, key technologies, and all. Now let’s discuss the other important aspects of the REDCAP like are important changes in SIB1 IEs, RRC Setup, and RRC reconfiguration, UE capability Information for the UE synchronization process what is the Call flow for the REDCAP.

Also Read:-  NCD SSB (non-Cell defining SSB) important IE’s for REDCAP UE.

How do we know that UEs support 5G NR light Redcap feature?

Identify Redcap (Reduced Capability) feature UE there are different ways to find out one of the most known methods is to check UE Capabilities. If NR UE supports, the REDCAP then UE Capability Information we get the REDCAP support IE’s

REDCAP UE Capabilities

Below the 3GPP snapshot, we can see that snapshot of REDCAP UE Capabilities.

Another way to identify the REDCAP UE on initial access is via the RACH procedure.

Early Message Identification RACH MSG 1 based

The UE already provides early identification during the random-access procedure that it is a REDCAP UE. For REDCAP UE have separate initial UL BWP, separate PRACH resource, or PRACH preamble partitioning. Under REDCAP InitialuplinkBWP have RACH config common where we can define the REDCAP-specific PRACH resources and preambles.

If both initialuplinkBWP and initialuplinkBWP-redcap are defined under SIB1 and have RACH config common parameters if the UE is REDCAP then it will prefer the intialuplinkBWP-redcap and send the MSG1 based on the RACH parameters defined under REDCAP BWP.

How to guarantee that a RACH occasion associated with the best SSB falls within the 5G NR light Redcap UE bandwidth?

• Option1: Proper RF-retuning for REDCAP
• Option2: Separate initial UL BWP for REDCAP UEs
• Option3: gNB configuration (e.g restriction on existing PRACH configuration on FDM-ed Ros, or always restricting the initial Ul BWP to within RedCap UE bandwidth
• Option 4: Dedicated PRACH configuration(e.g ROs) for RedCap UEs. 

Below 3GPP 38.331 17.2.0 snapshot mentioned the detailed RACH parameters.

LCID Based Identification RACH Msg3 transmission CCCH

In any case, if UE did not provide an early identification message MSG1 then identification will provide in MSG3 based on a REDCAP-specific LCID value of CCCH.

For REDCAP UE LCID is 35 and for Normal NR UE LCID is 52. If MSG3 we can see LCID is 35 then UE selected the REDCAP-based resources.

Two-Step RACH for 5G NR light Redcap feature

On MSGA in case of Two-step Rach procedure transmission via separate initial UL BWP, or in MsgA preamble part via separate PRACH resource or PRACH preamble partitioning, or in MsgA PUSCH part.

Initial BWP:

• Sharing the same SSB and CORESET#0 between REDCAP and non-REDCAP UEs is supported when the bandwidth is no wider than the REDCAP UE bandwidth.
• The initial DL BWP (derived based on MIB/SIB) for REDCAP UEs can be the same as the initial DL BWP for non-REDCAP UEs at least when the initial DL BWP is no wider than the Redcap UE bandwidth.
• The initial UL BWP(derived based on SIB) for REDCAP UEs can be the same as the initial UL BWP for non-REDCAP UEs at least when the initial Ul BWP is no wider than the REDCAP UE bandwidth.

Separate Initial Downlink/Uplink BWP for REDCAP:

Due to the reduced UE bandwidth for both FR1 and FR2, as per 3GPP specs for REDCAP, we have separate initial BWPs for Downlink and Uplink.

-InitialDownlinkBWP-RedCap-r17

-InitialUplinkBWP-RedCap-r17

Redcap Initial DL/UL BWP is defined under the NR SIB1, and the content of the initial DL/UL BWP is the same as a normal initial DL/UL BWP.

DL Initial Access for 5G NR light Redcap

InitialDownlinkBWP-RedCap-r17

• The bandwidth of the initial DL BWP for REDCAP UEs is not expected to exceed the maximum REDCAP UE bandwidth.
• The bandwidth and location of the initial DL BWP for REDCAO UEs can be the same as the bandwidth and location of the MIB-configured initial DL BWP for non-REDCAP UEs
• A SIB-configured initial DL BWP for non-RedCap UEs with a wider bandwidth than the maximum RedCap UE bandwidth is possible.
• A separate initialDownlinkBWP-Redcap-r17 for REDCAP UEs can be configured in SIB.
  • It can be used for during initial access
    • It can be used for initial access.
    • It is no wider than the maximum RedCap UE bandwidth.
• If InitialDownlinkBWP-Redcap-r17 IE is present, then 5G NR light Redcap UEs would prefer to use REDCAP BWP instead of IntialDownlinkBWP and if InitialDownlinkBWP-Redcap-r17 is not present under SIB1 then REDCAP UEs use the normal IntialDownlinkBWP but it cannot exceed the REDCAP UE maximum bandwidth i.e. 20MHZ for FR1 and 100MHZ for FR2.

Reference: 3GPP Specification 38.331 17.2.0

Under InitialDownlinkBWP-Redcap-r17 have similar IEs to normal InitialDownlinkBWP.

UL Initial Access for 5G NR light Redcap feature

InitialUplinkBWP-RedCap-r17

• If the initial UL BWP for non-REDCAP UEs is configured to be wider than the RedCAP UE bandwidth:
  • A separate initial UL BWP no wider than the REDCAP UE maximum bandwidth is configured for REDCAP UEs
  • So, the RACH Occasion associated with the best SSB falls within the REDCAP UE bandwidth.
  • So, the PUCCH for MSG4/MSGB HARQ feedback and PUSCH for MSG3/MSGA fall within the REDCAP UE bandwidth during initial access.
• A separate initialDownlinkBWP-Redcap-r17 for REDCAP UEs can be configured in SIB.
  • It can be used for during and after initial access.
    • It is no wider than the maximum RedCap UE bandwidth.

• If InitialUplinkBWP-Redcap-r17 IE is present, then Redcap UEs would prefer to use REDCAP BWP instead of IntialUplinkBWP and if InitialUplinkBWP-Redcap-r17 is not present under SIB1 then REDCAP UEs use the normal IntialUplinkBWP but it cannot exceed the REDCAP UE maximum bandwidth i.e. 20MHZ for FR1 and 100MHZ for FR2.

Reference: 3GPP Specification 38.331 17.2.0

SIB1 Consideration:

SIB1 contains the minimum system information for UEs to complete the initial access.

Most of the cell common information contained in SIB1 can be expected to be shared RedCap UEs and non-RedCap UEs

Whether or not the SIB1 PDSCH can be shared between RedCap UE and normal may be decided by the network to provide a flexible implementation.

Other important IEs for REDCAP under SIB 1:

CellBarredRedCap1Rx Value barred means that the cell is barred for a Redcap UE with 1 Rx branch, as defined in TS 38.304 [20]. This field is ignored by non-Redcap UEs.

CellBarredRedCap2Rx Value barred means that the cell is barred for a Redcap UE with 2 Rx branches, as defined in TS 38.304 [20]. This field is ignored by non-Redcap UEs.

Feature Priorities Indicates priorities for features, such as Redcap, Slicing, SDT, and MSG3-Repetitions for Coverage Enhancements. These priorities are used to determine which FeatureCombinationPreambles the UE shall use when a feature maps to more than one FeatureCombinationPreambles, as specified in TS 38.321 [3]. A lower value means a higher priority. The network does not signal the same priority for more than one feature. The network signals a priority for all features that map to at least one FeatureCombinationPreambles.

halfDuplexRedCap-Allowed The presence of this field indicates whether the cell supports half-duplex FDD Redcap UEs.

IntraFreqReselectionRedCap Controls cell selection/reselection to intra-frequency cells for Redcap UEs when this cell is barred or treated as barred by the Redcap UE, as specified in TS 38.304 [20]. If not present, a Redcap UE treats the cell as barred, i.e., the UE considers that the cell does not support Redcap.

Reference 3GPP 38.331 V 17.2.0

If you like This article then please comment will write more articles.