NR-Light, now officially terms as Reduced Capability (RedCap) in 3GPP NR Rel 17, is designed to function as LTE M1 /LTE NB IoT. However there are some minor differences between RedCap and LTE counter part, some difference by design and some difference due to the difference of technology between NR and LTE.
- Highlights of RedCap
- LTE vs NR in terms of Reduced Capability
- Legacy 5G vs 5G RedCap in terms of Key KPI
- MAC CE
- UE Capability
- Call Setup Procedure
- RRC Parameters
- Reference
- YouTube
- 3GPP Reference
Highlights of RedCap
RedCap is a reduction, so the useful question is which dimensions were cut and which were left alone. Three were cut : bandwidth, antenna count and modulation order. One that most people expect to see was not, and the list below says so explicitly.
Followings are some of the highlights of Redcap.
- Designed for simplified / low cost device
==> Same goal as LTE counterpart - Narrower bandwidth comparing to regular NR use case (eMBB), but narrowband here means up to 20 Mhz in sub-7 Ghz and 100 Mbps in mmWave
==> Even though it is called narrow band, it is already same as the max bandwidth of single carrier LTE . - Low power is not the scope of RedCap
==> This is different from LTE counter part. It may reduce some power due to narrow bandwidth, but there is no RedCap specific power saving technique . - Half Duplex
(optional)==> RedCap would support ordinary FDD (full duplex FDD) and TDD, but it can support Half Duplex FDD - a single transmit antenna,
- a single receive antenna, with 2 antennas being optional,
- lower-order modulation, with 256-QAM being optional
This is a super simplified summary of the RedCap feature and I would not extend it too much because I found a document about overall feature and usecase of RedCap that is much better than what I might have written here : What is reduced capability (RedCap) NR and what will it achieve?
For the implementation of RedCap, 3GPP release 17 added several features as listed below
- SIB elements decaring the support of RedCap on gNB (e.g, SIB1, SIB4)
- RRC-UE Capability Information : UE is supposed to inform its capability of RedCap support
- RRC Reconfiguration : gNB may configure RedCap (e.g, RLC, PDCP configuration)
- MAC CE : A few additional MAC CE elements for RedCap operation
LTE vs NR in terms of Reduced Capability
There has been LTE equivalent of RedCap which targets mid-tier IoT devices (not as much reduced capability as LTE BL/CE or NB-IoT). Following table shows nice summary and comparision between NR Light(5G RedCap) and LTE Equivalent which would not require any further explanation.
Figure 1. RedCap sits beside LTE Cat-4 on throughput and beside Cat-1bis on coverage. The maximum coupling loss row is the one to notice, because 140 dB is 4 dB worse than Cat-4 rather than equal to it.
- Bandwidth is 20 MHz in all three columns, so the RedCap saving against Cat-4 is not bandwidth.
- Peak data rate is 150/50 Mbps or higher, which matches Cat-4 and is far above Cat-1bis at 10/5 Mbps.
- Duplexing is where the columns differ. RedCap is the only one offering HD-FDD alongside FD-FDD and TDD.
- The Tx and Rx chain and MIMO layer rows are written as ranges, 1 or 2, because the second antenna is optional in RedCap and fixed in the two LTE categories.
- Maximum coupling loss is 140 dB, the same as Cat-1bis and 4 dB below Cat-4.
Source : 5G NR-Light (RedCap): Revolutionizing IoT - Qualcomm
In terms of peak data rate requirement, 5G Redcap with different release (release 17/18) and LTE equivalent are well summarized in Figure 2.
Figure 2. The ladder is drawn on peak data rate alone. Rel-18 RedCap sits below Rel-17, so the second iteration reduced the rate further rather than raising it.
- The arrow between Rel-17 RedCap and Rel-18 RedCap points downwards, towards the LTE-M band rather than away from it.
- The Rel-17 RedCap block covers about the same height as LTE Categories 2 to 4, and does not reach the higher LTE categories.
- Legacy NR occupies the whole upper part of the 5G column, and nothing in the 4G column reaches it.
- LTE-M category M1 and NB-IoT category NB1 are drawn as bars spanning both columns, because no 5G equivalent is drawn for them.
Source : RedCap - expanding the 5G device ecosystem for consumers and industries - Whitepaper - Ericsson
Following is short descriptions of the diagram
-
In terms of peak data rate, the 5G Rel-17 RedCap sits in the middle, with a peak data rate requirement that is an improvement over the 4G LTE-M and NB-IoT, but below the higher end of the LTE and Legacy NR. This positioning reflects its role as a compromise solution targeting mid-range IoT and industrial use cases.
-
Rel-17 RedCap and Rel-18 RedCap represent two iterations of Reduced Capability devices, suggesting ongoing development and improvements within the 5G RedCap category.
Legacy 5G vs 5G RedCap in terms of Key KPI
The three legacy 5G categories each optimise one thing and accept the cost on the other two. RedCap is the first that deliberately does not. It is therefore better read as a compromise than as a fourth corner of the same triangle.
The key KPI of 5G/NR RedCap in comparision with legacy NR (eMBB, URLLC, mMTC) is well illustrated as below.
Figure 3. Each solid trace reaches one corner and sacrifices the other two. The dashed RedCap trace reaches no corner at all, and that is the design rather than a shortfall.
- The three axes are high data rate at the top, low latency at the lower right, and low cost and long battery life at the lower left.
- eMBB, drawn in orange, extends furthest towards high data rate.
- URLLC, in green, is the trace that reaches furthest towards low latency.
- mMTC, in blue, reaches the low cost and long battery life corner and stays close to the origin on the other two axes.
- RedCap is the dashed trace, and it is the only one that covers ground on all three axes without reaching any corner.
Source : RedCap - expanding the 5G device ecosystem for consumers and industries - Whitepaper - Ericsson
This chart compares 5G NR RedCap against other 5G NR technologies across three axes: high data rate, low latency, and low cost/long battery life. NR RedCap aims to offer a balance among the three measured attributes, without excelling in any particular one
-
High Data Rate: eMBB leads significantly, with RedCap following at a lower level.
-
Low Latency: URLLC has the highest performance, while RedCap offers moderate low latency capabilities.
-
Low Cost and Long Battery Life: mMTC shows the greatest strength, suggesting it's optimized for cost efficiency and battery life. RedCap again has moderate performance, indicating it is designed to be cost-effective while still delivering reasonable data rates and latency.
-
Balance of Attributes: RedCap does not lead in any specific category but provides a balance, which can be ideal for applications that need moderate performance across the board rather than excelling in just one aspect.
MAC CE
RedCap does not add a new MAC control element, so the heading promises more than the change delivers. What it adds is LCID codepoints. A RedCap UE announces itself by sending its CCCH on a different logical channel identity. The network therefore learns the device class from the MAC subheader of Msg 3, rather than from any dedicated signalling.
Figure 4. Only the uplink table changes. The same 48 bit CCCH takes codepoint 35 from a RedCap UE and 52 from any other, so one field separates the two device classes before any capability has been exchanged.
- Four tables from 38.321 are shown : LCID for DL-SCH, LCID for UL-SCH, and the two octet eLCID tables for each direction.
- Three rows are outlined, and all three sit in the UL-SCH table. The downlink table has no RedCap specific row.
- Codepoint 35 is a 48 bit CCCH, called CCCH in 38.331, sent by a RedCap UE.
- Codepoint 36 is a 64 bit CCCH, called CCCH1 in 38.331, sent by a RedCap UE.
- Codepoint 52 is the same 48 bit CCCH sent by any UE that is not RedCap.
RedCap adds codepoints, not control elements : the change lives in the LCID table of 38.321, and the MAC PDU format itself is unchanged.Only the uplink direction is affected : the gNB has nothing to signal back at MAC level, because it already knows from Msg 1 which BWP the UE used.35 and 52 carry identical content : both are a 48 bit CCCH, and the only difference is what the codepoint says about the sender.Identification happens in Msg 3 : the LCID is in the MAC subheader, so the device class is known before any RRC capability exchange.
UE Capability
UE can notiffy gNB on whether it support RedCap and which specific feature it supports via the specific IEs in UE Capability Information message as listed below.
Following is based on
UE-NR-Capability-v1700 ::= SEQUENCE {
... -- the other Release 17 capability groups are not RedCap related
redCapParameters-r17 RedCapParameters-r17 OPTIONAL ,
...
}
RedCapParameters-r17::= SEQUENCE {
-- R1 28-1: RedCap UE
supportOfRedCap-r17 ENUMERATED {supported} OPTIONAL,
supportOf16DRB-RedCap-r17 ENUMERATED {supported} OPTIONAL
}
BandNR ::= SEQUENCE {
... -- the band fields before the RedCap group are not RedCap related
-- R1 28-1a: RRC-configured DL BWP without CD-SSB or NCD-SSB
bwp-WithoutCD-SSB-OrNCD-SSB-RedCap-r17 ENUMERATED {supported} OPTIONAL,
-- R1 28-3: Half-duplex FDD operation type A for (e)RedCap UE
halfDuplexFDD-TypeA-RedCap-r17 ENUMERATED {supported} OPTIONAL,
...
}
UERadioPagingInformation-v1700-IEs ::= SEQUENCE {
ue-RadioPagingInfo-r17 OCTET STRING (CONTAINING UE-RadioPagingInfo-r17) OPTIONAL,
inactiveStatePO-Determination-r17 ENUMERATED {supported} OPTIONAL,
numberOfRxRedCap-r17 ENUMERATED {one, two} OPTIONAL,
halfDuplexFDD-TypeA-RedCap-r17 SEQUENCE (SIZE (1..maxBands)) OF FreqBandIndicatorNR OPTIONAL ,
nonCriticalExtension UERadioPagingInformation-v1800-IEs OPTIONAL
}
components:
- Maximum FR1 RedCap UE bandwidth is 20 MHz;
- Maximum FR2 RedCap UE bandwidth is 100 MHz;
- Support of RedCap early indication based on Msg1, MsgA (if UE indicated
support of twoStepRACH-r16) and Msg3 for random access;
- Separate initial UL BWP for RedCap UEs;
- It includes the configuration(s) needed for RedCap UE to perform random
access
- Enabling/disabling of frequency hopping for common PUCCH resources
- Separate initial DL BWP for RedCap UEs;
- It includes CSS/CORESET for random access
- For separate initial DL BWP used for paging, CD-SSB is included
- For separate initial DL BWP only used for RACH, SSB may or may not be
included
- For separate initial DL BWP used in connected mode as BWP#0 configuration
option 1, CD-SSB is included
- 1 UE-specific RRC configured DL BWP per carrier;
- 1 UE-specific RRC configured UL BWP per carrier;
- UE-specific RRC-configured DL BWP with CD-SSB or NCD-SSB;
- NCD-SSB based measurements in RRC-configured DL BWP.
A RedCap UE shall set the field to supported.
Call Setup Procedure
There can be variations of call setup procedure between gNB(Network) and a redcap UE, but a most typical procedure can be illustrated as below. A few key points are :
RedCap Indicators : The UE's use of the RedCap BWP and specific LCIDs in the PUSCH message signal to the network that it's a RedCap device. This indication is usually notified by Msg 1 and Msg 3 during RACH procedure.Tailored Configuration : The gNB tailors the RRC configuration to the RedCap UE's capabilities, optimizing resource utilization. Usually this tailored configuration is based on the contents of UE capability information message.
Figure 5. Two of the exchanges identify the device, and both happen before any RRC message. Everything from Msg 1 onwards stays inside the RedCap specific BWP.
- The two arrows marked as the RedCap indicators are Msg 1, sent on the RedCap BWP, and Msg 3, carrying MAC CE LCID 35 or 36.
- The bracket on the right spans Msg 1 through RRC Reconfiguration, so everything after SIB1 runs inside the RedCap specific BWP.
- SIB1 carries three fields : redCap-ConfigCommon-r17, initialDownlinkBWP-RedCap-r17 and initialUplinkBWP-RedCap-r17.
- UE Capability Information carries bwp-WithoutCD-SSB-OrNCD-SSB-RedCap-r17 and redCapParameters-r17.
- The RRC Reconfiguration is drawn in both directions, because the tailored configuration depends on what the capability message reported.
Followings are breakdown of the procedure (
RedCap Supportability Announcement (SIB1):
- The gNB (base station) broadcasts System Information Block 1 (SIB1) to inform UEs about the network's support for RedCap devices.
- SIB1 includes:
redCapConfigCommon-r17 : Common RedCap configurations.initialDownlinkBWP-RedCap-r17 : Initial downlink bandwidth part (BWP) for RedCap.initialUplinkBWP-RedCap-r17 : Initial uplink BWP for RedCap.
Initial Access (Msg 1, Msg 2, Msg 3, Msg 4):
- The RedCap UE initiates access using the designated RedCap BWP:
Msg 1 : The UE sends a Physical Random Access Channel (PRACH) preamble for initial access. If UE send this via RedCap dedicated BWP, the gNB assumes that it is RedCap UE that attempt the attach.Msg 2 : The gNB responds with a Physical Downlink Shared Channel (PDSCH) message, scheduling the UE for uplink transmission.Msg 3 : The UE transmits a Physical Uplink Shared Channel (PUSCH) message with specific MAC CE LCIDs (Logical Channel IDs), 35 or 36, to indicate it's a RedCap device.Msg 4 : In case of contention with other UEs, a PDSCH message with contention resolution is used.
Radio Resource Control (RRC) Setup:
- After successful initial access, the RRC connection setup begins:
RRC: UE Capability Enquiry : The gNB requests the UE's capabilities.RRC: UE Capability Information : The UE responds with its supported features, including RedCap specific BWPs and parameters (bwp-WithoutCD-SSB-OrNCD-SSB-RedCap-r17, redCapParameters-r17).RRC: RRC Reconfiguration : Based on the UE's capabilities, the gNB configures the radio resources (BWPs, scheduling, etc.) for the RedCap UE.
RRC Parameters
The listings below cover the four places RedCap reaches into RRC. The cell announces support in SIB1 and SIB4, and the UE declares what it can do. The initial bandwidth parts get RedCap specific copies, and RLC and PDCP gain a longer sequence number option. Every RedCap field is highlighted, and the rest of each listing is context.
Following is based on
SIB1-v1700-IEs ::= SEQUENCE { hsdn-Cell-r17 ENUMERATED {true} OPTIONAL, -- Need R uac-BarringInfo-v1700 SEQUENCE { uac-BarringInfoSetList-v1700 UAC-BarringInfoSetList-v1700 } OPTIONAL, -- Cond MINT sdt-ConfigCommon-r17 SDT-ConfigCommonSIB-r17 OPTIONAL, -- Need RredCap-ConfigCommon-r17 RedCap-ConfigCommonSIB-r17 OPTIONAL , -- Need R featurePriorities-r17 SEQUENCE { redCapPriority-r17 FeaturePriority-r17 OPTIONAL, -- Need R slicingPriority-r17 FeaturePriority-r17 OPTIONAL, -- Need R msg3-Repetitions-Priority-r17 FeaturePriority-r17 OPTIONAL, -- Need R sdt-Priority-r17 FeaturePriority-r17 OPTIONAL -- Need R } OPTIONAL, -- Need R si-SchedulingInfo-v1700 SI-SchedulingInfo-v1700 OPTIONAL, -- Need R hyperSFN-r17 BIT STRING (SIZE (10)) OPTIONAL, -- Need R eDRX-AllowedIdle-r17 ENUMERATED {true} OPTIONAL, -- Need R eDRX-AllowedInactive-r17 ENUMERATED {true} OPTIONAL, -- Cond EDRX-RCintraFreqReselectionRedCap-r17 ENUMERATED {allowed, notAllowed} OPTIONAL , -- Need S cellBarredNTN-r17 ENUMERATED {barred, notBarred} OPTIONAL, -- Need S nonCriticalExtension SIB1-v1740-IEs OPTIONAL } RedCap-ConfigCommonSIB-r17 ::= SEQUENCE { halfDuplexRedCapAllowed-r17 ENUMERATED {true} OPTIONAL, -- Need R cellBarredRedCap-r17 SEQUENCE { cellBarredRedCap1Rx-r17 ENUMERATED {barred, notBarred}, cellBarredRedCap2Rx-r17 ENUMERATED {barred, notBarred} } OPTIONAL, -- Need R ... } SIB4 ::= SEQUENCE { interFreqCarrierFreqList InterFreqCarrierFreqList, lateNonCriticalExtension OCTET STRING OPTIONAL, ..., [[ interFreqCarrierFreqList-v1610 InterFreqCarrierFreqList-v1610 OPTIONAL -- Need R ]], [[interFreqCarrierFreqList-v1700 InterFreqCarrierFreqList-v1700 OPTIONAL -- Need R ]], ... -- the v1720, v1730 and v1760 groups are not RedCap related [[interFreqCarrierFreqList-v1800 InterFreqCarrierFreqList-v1800 OPTIONAL -- Need R ]], [[ interFreqCarrierFreqList-v1900 InterFreqCarrierFreqList-v1900 OPTIONAL -- Need R ]] } InterFreqCarrierFreqInfo-v1700 ::= SEQUENCE { interFreqNeighHSDN-CellList-r17 InterFreqNeighHSDN-CellList-r17 OPTIONAL, -- Need R highSpeedMeasInterFreq-r17 ENUMERATED {true} OPTIONAL, -- Need RredCapAccessAllowed-r17 ENUMERATED {true} OPTIONAL , -- Need R ssb-PositionQCL-Common-r17 SSB-PositionQCL-Relation-r17 OPTIONAL, -- Cond SharedSpectrum interFreqNeighCellList-v1710 InterFreqNeighCellList-v1710 OPTIONAL -- Cond SharedSpectrum2 } InterFreqCarrierFreqInfo-v1800 ::= SEQUENCE { ... -- the Rel-18 carrier and aerial fields are not RedCap relatedeRedCapAccessAllowed-r18 ENUMERATED {true} OPTIONAL , -- Need R ... } PosSI-SchedulingInfo-r16 ::= SEQUENCE { posSchedulingInfoList-r16 SEQUENCE (SIZE (1..maxSI-Message)) OF PosSchedulingInfo-r16, posSI-RequestConfig-r16 SI-RequestConfig OPTIONAL, -- Cond MSG-1 posSI-RequestConfigSUL-r16 SI-RequestConfig OPTIONAL, -- Cond SUL-MSG-1 ..., [[posSI-RequestConfigRedCap-r17 SI-RequestConfig OPTIONAL -- Cond REDCAP-MSG-1 ]], [[ posSI-RequestConfigMSG1-Repetition-r18 SI-RequestConfigRepetition-r18 OPTIONAL, -- Cond MSG-1 posSI-RequestConfigSUL-MSG1-Repetition-r18 SI-RequestConfigRepetition-r18 OPTIONAL, -- Cond SUL-MSG-1posSI-RequestConfigRedCap-MSG1-Repetition-r18 SI-RequestConfigRepetition-r18 OPTIONAL -- Cond REDCAP-MSG-1 ]] } DownlinkConfigCommon ::= SEQUENCE { frequencyInfoDL FrequencyInfoDL OPTIONAL, -- Cond InterFreqHOAndServCellAdd initialDownlinkBWP BWP-DownlinkCommon OPTIONAL, -- Cond ServCellAdd ..., [[initialDownlinkBWP-RedCap-r17 BWP-DownlinkCommon OPTIONAL -- Need R ]] } DownlinkConfigCommonSIB ::= SEQUENCE { frequencyInfoDL FrequencyInfoDL-SIB, initialDownlinkBWP BWP-DownlinkCommon, bcch-Config BCCH-Config, pcch-Config PCCH-Config, ..., [[ pei-Config-r17 PEI-Config-r17 OPTIONAL, -- Need RinitialDownlinkBWP-RedCap-r17 BWP-DownlinkCommon OPTIONAL -- Need R ]], ... -- the v1800 and r19 groups are not RedCap related } FeatureCombination-r17 ::= SEQUENCE {redCap-r17 ENUMERATED {true} OPTIONAL , -- Need R smallData-r17 ENUMERATED {true} OPTIONAL, -- Need R nsag-r17 NSAG-List-r17 OPTIONAL, -- Need R msg3-Repetitions-r17 ENUMERATED {true} OPTIONAL, -- Need R msg1-Repetitions-r18 ENUMERATED {true} OPTIONAL, -- Need ReRedCap-r18 ENUMERATED {true} OPTIONAL , -- Need R spare2 ENUMERATED {true} OPTIONAL, -- Need R spare1 ENUMERATED {true} OPTIONAL -- Need R } PUCCH-ConfigCommon ::= SEQUENCE { pucch-ResourceCommon INTEGER (0..15) OPTIONAL, -- Cond InitialBWP-Only pucch-GroupHopping ENUMERATED { neither, enable, disable }, hoppingId INTEGER (0..1023) OPTIONAL, -- Need R p0-nominal INTEGER (-202..24) OPTIONAL, -- Need R ..., [[ nrofPRBs INTEGER (1..16) OPTIONAL, -- Need R intra-SlotFH-r17 ENUMERATED {fromLowerEdge, fromUpperEdge} OPTIONAL, -- Cond InitialBWP-RedCapOnlypucch-ResourceCommonRedCap-r17 INTEGER (0..15) OPTIONAL , -- Cond InitialBWP-RedCap additionalPRBOffset-r17 ENUMERATED {n2, n3, n4, n6, n8, n9, n10, n12} OPTIONAL -- Cond InitialBWP-RedCapOnly ]], [[ p0-nominal-SBFD-r19 INTEGER (-202..24) OPTIONAL -- Need R ]] } SI-SchedulingInfo-v1700 ::= SEQUENCE { schedulingInfoList2-r17 SEQUENCE (SIZE (1..maxSI-Message)) OF SchedulingInfo2-r17,dummy SI-RequestConfig OPTIONAL } UplinkConfigCommon-v1700 ::= SEQUENCE {initialUplinkBWP-RedCap-r17 BWP-UplinkCommon OPTIONAL -- Need R } UplinkConfigCommonSIB-v1700 ::= SEQUENCE {initialUplinkBWP-RedCap-r17 BWP-UplinkCommon OPTIONAL -- Need R } PDCP-Parameters ::= SEQUENCE { ... -- the original members and the r16 group are not RedCap related [[longSN-RedCap-r17 ENUMERATED {supported} OPTIONAL , udc-r17 SEQUENCE { ... } OPTIONAL ]], ... -- the r18 group is not RedCap related } RLC-Parameters ::= SEQUENCE { am-WithShortSN ENUMERATED {supported} OPTIONAL, um-WithShortSN ENUMERATED {supported} OPTIONAL, um-WithLongSN ENUMERATED {supported} OPTIONAL, ..., [[ extendedT-PollRetransmit-r16 ENUMERATED {supported} OPTIONAL, extendedT-StatusProhibit-r16 ENUMERATED {supported} OPTIONAL ]], [[am-WithLongSN-RedCap-r17 ENUMERATED {supported} OPTIONAL ]], ... -- the r18 and r19 groups are not RedCap related }
Reference
- What is reduced capability (RedCap) NR and what will it achieve? - Ericsson (2021)
- RedCap - expanding the 5G device ecosystem for consumers and industries - Whitepaper - Ericsson
- 5G NR-Light (RedCap): Revolutionizing IoT - Qualcomm (2022)
- Study on support of reduced capability NR devices (Release 17) - NR Explained
YouTube
- Beginners: Introduction to NR-Light a.k.a. NR-Lite
- 5G NR-Light will serve sensors, wearables, and IoT
3GPP Reference
The four contributions below are the ones that opened the topic, all from the Release 17 package proposal stage. They are worth reading together, because each vendor argued for a different reduction and the final feature is the intersection of what they asked for.
- RP-190831 : Key directions for Release 17 (Nokia)
- RP-190844 : NR-Lite for Rel-17 Qualcomm views (Qualcomm)
- RP-191047 : NR-Lite for Industrial Sensors and Wearables (Ericsson)
- RP-191175 : Motivation for NR-lite: IoT over NR (SamSung)