Study on support of reduced capability NR devices (Release 17)V1.1.0

Note: this page is a summary of 3GPP TS 38.875, for details please check the TS directly.

Table of content:

  1. Introduction
  2. UE complexity reduction features
    1. Reduced number of UE Rx/Tx antennas
    2. UE bandwidth reduction
    3. Half-duplex FDD operation
    4. Relaxed UE processing time
    5. Relaxed maximum number of MIMO layers
    6. Relaxed maximum modulation order
    7. Combinations of UE complexity reduction features
  3. UE power saving features
    1. Reduced PDCCH monitoring
    2. Extended DRX for RRC Inactive and/or Idle
    3. RRM relaxation for stationary devices
  4. UE identification and access restrictions
  5. Conclusions and recommendations
    1. UE complexity reduction
    2. UE power saving
    3. Reduced capability signaling framework
    4. Identification and access restriction

Introduction

The usage scenarios that have been identified for 5G are enhanced mobile broadband (eMBB), massive machine-type communication (mMTC), and Ultra-Reliable and Low Latency communication (URLLC). Yet another identified area is time sensitive communication (TSC). In particular, mMTC, URLLC and TSC are associated with novel IoT use cases that are targeted in vertical industries. It is envisaged that eMBB, mMTC, URLLC and TSC use cases may all need to be supported in the same network.

Rel-16 introduced support for Time-Sensitive Networking (TSN) and 5G integration for TSC use cases:

  1. connected industries: 5G connectivity can serve as catalyst for next wave of industrial transformation and digitalization, which improve flexibility, enhance productivity and efficiency, reduce maintenance cost, and improve operational safety. Devices in such environment include e.g. pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, actuators, etc. The requirements for these services are higher than LPWA (i.e. LTE-MTC/NB-IoT) but lower than URLLC and eMBB.
  2. smart city: The smart city vertical covers data collection and processing to more efficiently monitor and control city resources, and to provide services to city residents. Especially, the deployment of surveillance cameras is an essential part of the smart city but also of factories and industries.
  3. wearables: smart watches, rings, eHealth related devices, and medical monitoring devices etc. One characteristic for the use case is that the device is small in size.

As a baseline, the requirements for these three use cases are:

  • Generic requirements:
    • Device complexity: Main motivation for the new device type is to lower the device cost and complexity as compared to high-end eMBB and URLLC devices of Rel-15/Rel-16. This is especially the case for industrial sensors.
    • Device size: Requirement for most use cases is that the standard enables a device design with compact form factor.
    • Deployment scenarios: System should support all FR1/FR2 bands for FDD and TDD.
  • Use case specific requirements:
    • Industrial wireless sensors: Reference use cases and requirements are described in TR 22.832 and TS 22.104: Communication service availability is 99.99% and end-to-end latency less than 100 ms. The reference bit rate is less than 2 Mbps (potentially asymmetric e.g. UL heavy traffic) for all use cases and the device is stationary. The battery should last at least few years. For safety related sensors, latency requirement is lower, 5-10 ms (TR 22.804)
    • Video Surveillance: As described in TR 22.804, reference economic video bitrate would be 2-4 Mbps, latency > 500 ms, reliability 99%-99.9%. High-end video e.g. for farming would require 7.5-25 Mbps. It is noted that traffic pattern is dominated by UL transmissions.
    • Wearables: Reference bitrate for smart wearable application can be 5-50 Mbps in DL and 2-5 Mbps in UL and peak bit rate of the device higher, up to 150 Mbps for downlink and up to 50 Mbps for uplink. Battery of the device should last multiple days (up to 1-2 weeks).

The intention is to study a UE feature and parameter list with lower end capabilities, relative to Release 16 eMBB and URLLC NR to serve the three use cases mentioned above.


UE complexity reduction features

Introduction to UE complexity reduction features

The following UE complexity reduction techniques have been studied:

The following UE complexity reduction techniques for higher layers have been discussed in RAN2:

  • Reduction of the maximum number of DRBs which UE needs to mandatorily support.
  • Reduction of L2 buffer size. According to the calculation in TS 38.306, with peak data rate reductions, L2 buffer requirements for RedCap UEs are implicitly reduced accordingly. Benefits and feasibility of further reduction requires evaluation in normative phase if it is to be considered.
  • SN in PDCP and RLC is 18-bits, and the size could be reduced depending on which features RedCap UEs support, if a clear benefit in such reduction is identified.
  • The gain of relaxing RRC processing delay requirements was not studied and requires further evaluation in normative phase if it is to be considered.

These UE complexity reduction techniques for higher layers have not been explicit objectives during the study and would require further evaluation during the normative phase if they are to be considered.

Reduced number of UE Rx/Tx antennas

The evaluation of cost/complexity reduction has been performed with respect to a reference NR UE. Number of Tx antenna is assumed to be 1 for both RedCap and reference NR UE. Number of Tx antennas is summarized in below table:

FR1 FDDFR1 TDDFR2 TDD
NR Ref2Rx4Rx2Rx
RedCap1Rx2Rx1Rx1Rx

When the number of UE Rx branches is reduced, the maximum number of DL MIMO layers is reduced correspondingly. Two sets of evaluation results are presented below. The first set concerns the estimated cost reduction from reducing the number of Rx branches without taking the reduced maximum number of downlink MIMO layers into account, whereas the second set considers both the reduced number of Rx branches and the corresponding reduction of the maximum number of DL MIMO layers.

Cost reductionContributors of cost reduction
FR1 FDD (2->1)FR1 TDD (4->2)FR1 TDD (4->1)FR2 TDD (2->1)RFBB
reduce RX w/o reduce MIMO layer~26%~31%~46%~31%Antenna array (only FR2), Filters, Transceiver (including LNAs, mixer, and local oscillator)ADC/DAC, FFT/IFFT, Post-FFT data buffering, Receiver processing block, Synchronization/cell search block
reduce RX w/ reduce MIMO layer~37%~40%~60%~40%above + LDPC decoding, HARQ buffer, MIMO specific processing blocks

The reduction of number of UE Rx branches, relative to that of the reference NR device, may be beneficial in terms of reducing the device size in FR1. It is unclear whether the reduction of number of UE Rx branches, relative to that of the reference NR device, may be beneficial in terms of reducing the device size in FR2.

PerformanceImpact
Coveragedegradation of downlink performance is expected, which may affect the coverage. The amount of degradation depends on the number of Rx branches
Network capacity and spectral efficiencyA loss in network capacity and spectral efficiency is expected.
Data rate
  • Reduction from 2 Rx branches to 1 Rx branch decreases the downlink peak rate by ~50%.
  • Reduction from 4 Rx branches to 2 Rx branches decreases the downlink peak rate by ~50%.
  • Reduction from 4 Rx branches to 1 Rx branch decreases the downlink peak rate by ~75%.
Latency and reliabilitylimited impact on the latency in most cases. However, if the UE is near the cell edge, the latency can increase. Nevertheless, the latency requirements of RedCap use cases can be sufficiently fulfilled, in both FR1 and FR2.
The reliability requirements for the RedCap use cases can still be fulfilled with reduced number of UE Rx branches. However, in some cases, the reliability can only be maintained at the cost of downlink spectral efficiency loss.
Power consumptionThe instantaneous power consumption in the RF and the baseband modules of the UE is expected to be reduced due to the use of fewer RF chains and the reduction in the complexity of multi-antenna processing. However, downlink reception time may be longer for large payloads due to reduced spectral efficiency.
PDCCH blocking rateIn order to compensate for the performance degradation resulting from a reduced number of UE Rx branches, higher aggregation levels may need to be used. This can lead to increase in PDCCH blocking rate if the amount of PDCCH resources is not increased.

UE bandwidth reduction

FR1FR2
NR ref100 MHz200 MHz
RedCap20 MHz50 MHz or 100 MHz

For the baseline UE bandwidth capability of RedCap UEs, the same maximum UE bandwidth in a band applies to both RF and baseband. It is also primarily assumed that this maximum UE bandwidth applies to both data and control channels and that this maximum UE bandwidth is assumed for both DL and UL.

Cost reductionContributors of cost reduction
FR1 FDD (100->20 MHz)FR1 TDD (100->20 MHz)FR2 (200->100 MHz)FR2 (200->50 MHz)Baseband
~32%~33%~16%~23%ADC/DAC, FFT/IFFT, Post-FFT data buffering, Receivwer processing block, LDPC decoding, HARQ buffer

Although the results from most sourcing companies do not show PA cost reduction from bandwidth reduction, some sourcing companies indicate that PA cost can be reduced due to Tx bandwidth reduction from 100 MHz to 20 MHz in FR1.

PerformanceImpact
CoverageThe impact on the coverage of downlink and uplink channels would not be large, although a small loss may be observed due to reduced frequency diversity.
For PDCCH coverage, one important aspect is whether the larger aggregation levels (AL), e.g. 8 and 16, can be supported after bandwidth reduction. In FR1, UE bandwidth 20 MHz is enough for supporting AL 16 for any CORESET#0 configuration. In FR2, UE bandwidth 100 MHz is also enough for supporting AL 16 for any CORESET#0 configuration. However, reducing the UE bandwidth to 50 MHz in FR2 will have impact on PDCCH coverage when CORESET#0 is configured to have 69.12 MHz bandwidth. The loss is assessed to be ~1.5-3.0 dB. Reducing the UE bandwidth to 50 MHz will have impact on PBCH coverage if the SSB is configured with 240 kHz SCS. The loss is assessed to be within 1 dB. Furthermore, reducing the UE bandwidth to 50 MHz may also impact the coverage of initial access messages if CORESET#0 is configured to have 69.12 MHz bandwidth.
Network capacity and spectral efficiencyBandwidth reduction in FR1 will not have a significant impact on capacity and spectral efficiency, although there may be some minor degradation due to the loss in frequency selective scheduling gain.
Bandwidth reduction in FR2 may be associated with more noticeable loss in capacity and spectral efficiency if analog beamforming is being used. In this case, the loss will be larger for 50 MHz UE bandwidth than for 100 MHz UE bandwidth.
Data rateBandwidth reduction results in a reduction in the achievable peak data rate. However, all the bandwidth options (20 MHz in FR1, and 50 MHz or 100 MHz in FR2) considered in the RedCap study are enough for meeting the peak data rate requirements for the RedCap use cases, at least when the bandwidth reduction is not combined with other UE complexity reduction techniques, except in some TDD configurations.
Latency and reliabilityAll the latency and reliability requirements for the RedCap use cases can be satisfied by all the bandwidth options (20 MHz in FR1, and 50 MHz or 100 MHz in FR2)
In FR2, UE bandwidth reduction may result in a longer SSB/SIB1 acquisition time for certain configurations for SSB/CORESET multiplexing patterns 2 and 3. To minimize the SSB/SIB1 acquisition time, it may be beneficial to support an FR2 RedCap UE bandwidth of 100 MHz.
Power consumptionThe instantaneous power consumption in the RF and the baseband modules of the UE is expected to be reduced due to the use of fewer RF chains and the reduction in the complexity of multi-antenna processing. However, downlink reception time may be longer for large payloads due to reduced spectral efficiency.
PDCCH blocking rateIf CORESET is configured according to the RedCap UE capability and shared by both RedCap and non-RedCap UEs, this may result in increased PDCCH blocking rate. In that case, the impact of an FR2 RedCap UE bandwidth of 50 MHz would be greater than for 100 MHz.

Half-duplex FDD operation

Half-duplex operation allows the UE to receive and transmit on different frequencies, but not at the same time. Half-duplex mode allows for removing a duplexer and instead use a switch and an additional filter.

The RedCap study includes both HD-FDD operation Type A and Type B, as defined in LTE, where study of Type A is prioritized.

Cost reductionContributors of cost reduction
Type AType BRF
~7%~10%duplexer/switch block. Baseband has nearly no saving
PerformanceImpact
CoverageIf there are no stringent requirements on latency and data rate, then HD-FDD will not result in coverage loss, otherwise a coverage loss can be expected.
Network capacity and spectral efficiencyminor impact on spectral efficiency and capacity.
Data rateThere is minor impact from HD-FDD operation on instantaneous data rates for uplink or downlink, but similarly to TDD, HD-FDD reduces user throughput compared to FD-FDD, especially in case of simultaneous downlink and uplink traffic, and it may be challenging to meet the peak data rate requirements in downlink and uplink simultaneously.
Latency and reliabilityHD-FDD introduces longer latency than FD-HDD, especially in case of simultaneous downlink and uplink traffic, but the latency and reliability requirements of RedCap use cases can still be fulfilled at least for one direction (downlink or uplink).
Power consumptionThe lower insertion loss of an HD-FDD UE may enable a higher power efficiency in the transmit chain and reduce power consumption. Furthermore, compared to the reference NR modem, half-duplex operation means some components can work in a reduced power state until required. However, on the other hand, HD-FDD may have a negative impact on UE average power consumption because the UE will be active for a longer time before being able to return to a lower power light sleep or deep sleep state. The impact on power consumption of HD-FDD depends on implementation and traffic characteristics.
PDCCH blocking rateHD-FDD operation may potentially reduce the available PDCCH monitoring occasions when the UE is transmitting rather than receiving.

Relaxed UE processing time

In the RedCap study item, relaxed UE processing time is considered in terms of more relaxed N1 and N2 values (as defined in TS 38.214) compared to those of UE processing time capability 1. In the study, for the purpose of evaluation, the relaxed UE processing time in terms of N1 and N2 are assumed to be doubled compared to those of capability 1, i.e.,

SCSNR RefRedCap
N1N2N1N2
15 kHz8101620
30 kHz10122024
60 kHz17233446
120 kHz20364072

In the study, for the purpose of evaluation, relaxed CSI computation time was also considered, assuming doubled Z and Z' compared to the values defined in TS 38.214 clause 5.4.

Cost reductionContributors of cost reduction
FR1 FDDFR1 TDDFR2Baseband
Relaxed N1 and N2~6%Receiver processing block, LDPC decoding, DL control processing & decoder, UL processing block
Relaxed CSI computation time~5%~4.5%6%DL control processing & decoder, MIMO specific processing blocks

Relaxed UE processing time in terms of N1 and N2 potentially reduces UE complexity by allowing a longer time for the processing of PDCCH and PDSCH and preparing PUSCH and PUCCH. Whether the relaxed UE processing time in terms of N1 and N2 may reduce the cost/complexity in the 'DL control processing & decoder' block depends on the UE implementation.

PerformanceImpact
Coverageno
Network capacity and spectral efficiencyno or minor
Data rateNo impact on instantaneous peak data rate is expected from a more relaxed UE processing time in terms of N1 and N2, but the UE throughput may be reduced if the HARQ round trip time is extended. The throughput requirements identified for the RedCap use cases are still expected to be fulfilled.
Latency and reliabilityFor downlink transmission, relaxed N1 value impacts how fast HARQ-ACK feedback can be sent after the reception of PDSCH. For uplink transmission, relaxed N2 value impacts how fast PUSCH can be scheduled with respect to the UL grant.
Power consumptionmay allow for processing with lower clock frequency and lower voltage which may help reducing the UE power consumption.
PDCCH blocking rateno

Relaxed maximum number of MIMO layers

When the number of UE Rx branches is reduced, the maximum number of DL MIMO layers is reduced correspondingly. Two sets of evaluation results are presented below. The first set concerns the estimated cost reduction from reducing the number of Rx branches without taking the reduced maximum number of downlink MIMO layers into account, whereas the second set considers both the reduced number of Rx branches and the corresponding reduction of the maximum number of DL MIMO layers.

Cost reductionContributors of cost reduction
FR1 FDD (2->1 layer)FR1 TDD (4->2 layer)FR1 TDD (4->1 layer)FR2 (2->1 layer)Baseband
~12%~11%~17%~11%Receiver processing block, LDPC decoding, HARQ buffer, MIMO specific processing block
PerformanceImpact
Coverageno
Network capacity and spectral efficiencySince reducing the maximum number of MIMO layers reduces the peak data rate, it degrades the network capacity and spectral efficiency. Especially, the reduction of maximum number of MIMO layers mainly degrades the spectral efficiency for UEs in good channel conditions.
Data rate
  • Reduction from 2 layers to 1 layer decreases the downlink peak rate by ~50%.
  • Reduction from 4 layers to 2 layers decreases the downlink peak rate by ~50%.
  • Reduction from 4 layers to 1 layer decreases the downlink peak rate by ~75%.
Latency and reliabilityReducing the number of MIMO layers does not impact the latency and reliability significantly. The reduction of the maximum number of MIMO layers is only expected to affect the achievable latency for UEs in good channel conditions. The latency requirements of most RedCap use cases can still be sufficiently fulfilled.

Relaxed maximum modulation order

ULDL
FR1FR2FR1FR2
NR ref64QAM64QAM256QAM64QAM
RedCap16QAM16QAM64QAM16QAM
Cost reductionContributors of cost reduction
UL FR1 (64QAM->16QAM)UL FR2 (64QAM->16QAM)DL FR1 (256QAM->64QAM)DL FR2 (64QAM->16QAM)RFBB
~2%~6%Power amplifier (UL), TransceiverUL: ADC/DAC, UL processing block
DL: ADC/DAC, Receiver processing block, LDPC decoding, HARQ buffer
PerformanceImpact
Coverageno
Network capacity and spectral efficiencyreduce spectral efficiency due to reduced peak data rate.
Data rate
  • Reduction from 256QAM to 64QAM decreases the downlink peak rate by ~25%.
  • Reduction from 64QAM to 16QAM decreases the downlink peak rate by ~33%.
Despite this reduction in peak data rate, the UE will be able to sufficiently fulfil the peak data rate requirements for the RedCap uses cases.
Latency and reliabilitymay increase the latency slightly. Nevertheless, all the latency and reliability requirements for the RedCap use cases can be satisfied.
Power consumptionreduce power consumption of the RF and baseband modules marginally during transmission and reception.

Combinations of UE complexity reduction features

Estimated relative device cost and estimated relative device cost reduction for UE complexity reduction technique(s) for FR1 FDD:

FR1 FDD UE complexity reduction technique(s)RF cost metricBB cost metricTotal cost metricRF reductionBB reductionTotal reduction
20 MHz (instead of 100 MHz)97.7%48.4%68.1%2.3%51.6%31.9%
1 layer (instead of 2 layers)100.0%79.3%87.6%0.0%20.7%12.4%
1 layer, 1 Rx (instead of 2 layers, 2 Rx)74.2%55.9%63.2%25.8%44.1%36.8%
HD-FDD type A (instead of FD-FDD)83.9%99.4%93.2%16.1%0.6%6.8%
HD-FDD type B (instead of FD-FDD)77.3%99.2%90.4%22.7%0.8%9.6%
Double N1 and N2100.0%90.5%94.3%0.0%9.5%5.7%
DL 64QAM (instead of DL 256QAM)97.8%91.8%94.2%2.2%8.2%5.8%
UL 16QAM (instead of UL 64QAM)97.1%98.3%97.8%2.9%1.7%2.2%
20 MHz, 1 layer, 1 Rx67.5%25.8%42.5%32.5%74.2%57.5%
20 MHz, 1 layer, 1 Rx, HD-FDD type A53.2%25.6%36.6%46.8%74.4%63.4%
20 MHz, 1 layer, 1 Rx, DL 64QAM, UL 16QAM64.2%24.3%40.2%35.8%75.7%59.8%
20 MHz, 1 layer, 1 Rx, double N1 and N267.5%22.9%40.7%32.5%77.1%59.3%
20 MHz, 1 layer, 1 Rx, DL 64QAM, UL 16QAM, double N1 and N264.6%21.7%38.9%35.4%78.3%61.1%
20 MHz, 1 layer, 1 Rx, DL 64QAM, UL 16QAM, HD-FDD type A, double N1 and N250.2%21.4%32.9%49.8%78.6%67.1%
20 MHz, 2 layers, 2 Rx, HD-FDD type A81.3%46.0%60.1%18.8%54.0%39.9%
20 MHz, 2 layers, 2 Rx, double N1 and N297.6%42.6%64.6%2.4%57.4%35.4%

Estimated relative device cost and estimated relative device cost reduction for UE complexity reduction technique(s) for FR1 TDD:

FR1 TDD UE complexity reduction technique(s)RF cost metricBB cost metricTotal cost metricRF reductionBB reductionTotal reduction
20 MHz (instead of 100 MHz)96.4%46.7%66.6%3.6%53.3%33.4%
2 layers (instead of 4 layers)100.0%81.1%88.7%0.0%18.9%11.3%
1 layer (instead of 4 layers)100.0%71.9%83.2%0.0%28.1%16.8%
2 layers, 2 Rx (instead of 4 layers, 4 Rx)68.0%55.4%60.4%32.0%44.6%39.6%
1 layer, 1 Rx (instead of 4 layers, 4 Rx)51.3%33.0%40.3%48.7%67.0%59.7%
Double N1 and N2100.0%90.1%94.1%0.0%9.9%5.9%
DL 64QAM (instead of DL 256QAM)96.2%92.1%93.7%3.8%7.9%6.3%
UL 16QAM (instead of UL 64QAM)96.9%98.4%97.8%3.1%1.6%2.2%
20 MHz, 1 layer, 1 Rx50.6%18.6%31.4%49.4%81.4%68.6%
20 MHz, 1 layer, 1 Rx, DL 64QAM, UL 16QAM47.1%17.5%29.3%52.9%82.5%70.7%
20 MHz, 1 layer, 1 Rx, double N1 and N250.6%16.2%30.0%49.4%83.8%70.0%
20 MHz, 1 layer, 1 Rx, DL 64QAM, UL 16QAM, double N1 and N247.1%15.3%28.1%52.9%84.7%71.9%
20 MHz, 2 layers, 2 Rx66.8%27.8%43.4%33.3%72.2%56.6%
20 MHz, 2 layers, 2 Rx, DL 64QAM, UL 16QAM61.8%26.1%40.4%38.2%73.9%59.6%
20 MHz, 2 layers, 2 Rx, double N1 and N266.8%24.9%41.7%33.3%75.1%58.3%
20 MHz, 2 layers, 2 Rx, DL 64QAM, UL 16QAM, double N1 and N261.8%23.7%38.9%38.2%76.3%61.1%

Estimated relative device cost and estimated relative device cost reduction for UE complexity reduction technique(s) for FR2:

FR2 UE complexity reduction technique(s)RF cost metricBB cost metricTotal cost metricRF reductionBB reductionTotal reduction
100 MHz (instead of 200 MHz)99.5%69.4%84.4%0.5%30.6%15.6%
50 MHz (instead of 200 MHz)99.0%54.0%76.5%1.0%46.0%23.5%
1 layer (instead of 2 layers)100.0%77.8%88.9%0.0%22.2%11.1%
1 layer, 1 Rx (instead of 2 layers, 2 Rx)64.9%55.7%60.3%35.1%44.3%39.7%
Double N1 and N2100.0%88.9%94.4%0.0%11.1%5.6%
DL 16QAM (instead of DL 64QAM)97.8%91.0%94.4%2.2%9.0%5.6%
UL 16QAM (instead of UL 64QAM)97.9%98.4%98.1%2.2%1.6%1.9%
100 MHz, 1 layer, 1 Rx64.8%40.3%52.5%35.2%59.7%47.5%
100 MHz, 1 layer, 1 Rx, DL 16QAM, UL 16QAM61.6%37.0%49.3%38.4%63.0%50.7%
100 MHz, 1 layer, 1 Rx, double N1 and N264.4%35.5%50.0%35.6%64.5%50.0%
100 MHz, 1 layer, 1 Rx, DL 16QAM, UL 16QAM, double N1 and N261.6%32.9%47.2%38.4%67.1%52.8%
100 MHz, 2 layers, 2 Rx, DL 16QAM, UL 16QAM95.2%63.8%79.5%4.8%36.2%20.5%
100 MHz, 2 layers, 2 Rx, double N1 and N299.4%62.4%80.9%0.6%37.6%19.1%
100 MHz, 2 layers, 2 Rx, DL 16QAM, UL 16QAM, double N1 and N295.2%57.8%76.5%4.8%42.2%23.5%

UE power saving features

Introduction to UE power saving features

The following UE power saving techniques have been studied:

In addition, RAN2 has studied the impact of introducing RedCap UEs on UE power consumption in general and has observed that power consumption of RedCap UEs may be impacted because of paging false alarm and unnecessary SIB1 reading. Paging false alarm and unnecessary SIB1 reading are not specific to RedCap UEs and are discussed in Rel-17 Power Saving WI. Enhancements introduced by Rel-17 Power Saving WI should also be applicable to RedCap UEs.

Reduced PDCCH monitoring

Scheme #1 Reduced maximum number of Blind Decoding (BD) per slot in connected mode

In Rel-15 and Rel-16 NR, the number of BDs per slot is configurable up to the limits defined for different SCS configurations, as summarized in table below. Scheme #1 reduces the maximum number of BDs in a slot. In Rel-15 and Rel-16 specifications, the total number of different DCI sizes configured to monitor is up to 4 with up to 3 different DCI sizes with C-RNTI. Two alternatives were studied under Scheme #1, which includes:

  • Alt.1a: reduced maximum number of BDs per slot with additionally reduced DCI size budget, and
  • Alt.1b: reduced maximum number of BDs per slot without reduced DCI size budget
Blind decoding limits in NR.
SCS [kHz]153060120
Max #BD per slot (in NR)44362220
Scheme #2 Extending the PDCCH monitoring gap to X slots (X>1) in connected mode

In Rel-15/16 NR, the range of PDCCH monitoring periodicity is configurable, which is in a range of a few symbol (s) to 2560 slots subject to UE capability. Scheme#2 is to extend the minimum separation between two consecutive PDCCH monitoring occasions, spans or slots with configured PDCCH candidates to be X slots, where X>1.

Scheme #3 Dynamic adaptation of PDCCH BD parameters in connected mode

In Rel-15/16, the parameters of PDCCH monitoring is configured by RRC signalling on a per search space set basis. Scheme #3 is to dynamically adapt PDCCH BD parameters e.g. maximum number of PDCCH candidates per PDCCH monitoring occasion and minimum time separation between two consecutive PDCCH monitoring occasions.

The evaluation of cost/complexity reduction has been performed with respect to a reference NR UE. Number of Tx antenna is assumed to be 1 for both RedCap and reference NR UE. Number of Tx antennas is summarized in below table:

Freq RangeSchedulingN RxBD reductiontraffic model
instant messageheartbeat 200ms inactivity timerheartbeat 80ms inactivity timerVoIP
FR1 (30k SCS)Same-slot1 Rx25%2.81%1.56%1.33%2.59%
50%5.82%3.25%2.92%4.74%
2 Rx25%3.05%1.65%1.49%2.85%
50%6.59%3.72%3.42%5.66%
Cross-slot1 Rx25%2.58%1.66%1.60%2.29%
50%4.26%2.48%2.34%3.20%
2 Rx25%3.08%1.95%1.69%2.28%
50%5.7%3.51%3.21%4.45%
FR2 (120k SCS)Same-slot1 Rx25%4.20%1.72%1.28%3.81%
50%8.60%3.69%2.58%7.43%
2 Rx25%4.52%2.13%1.99%4.27%
50%8.98%4.14%3.88%8.27%
Cross-slot1 Rx25%3.19%1.30%1.24%3.27%
50%6.17%2.60%2.48%6.33%
2 Rx25%3.43%1.05%0.92%3.38%
50%6.59%2.11%1.84%6.52%
Note: the saving number is the average of different companies' evaluation results.

Extended DRX for RRC Inactive and/or Idle

In LTE connected to EPC, the UE may be configured with an extended DRX (eDRX) cycle. The UE may operate in eDRX only if the UE is configured by NAS and the cell indicates support for eDRX in System Information (note that there is no System Information indication for NB-IoT). In RRC_IDLE, the eDRX cycle has the maximum value of 2621.44 seconds (43.69 minutes). For NB-IoT the maximum value of eDRX cycle is 10485.76 seconds (2.91 hours). Hyper SFN (H-SFN) is broadcasted in System Information and incremented by one when SFN wraps around. The Paging Hyperframe (PH) refers to the H-SFN in which the UE starts to monitor for paging during a Paging Time Window (PTW), see e.g. [TS 36.300].

RAN2 has studied the following topics related to extended DRX for RRC_IDLE and RRC_INACTIVE:

  • Analysis of UE power saving
  • Analysis of upper and lower bound of extended DRX cycles
  • Analysis of mechanisms for extended DRX

Analysis of UE power saving

In summary, one source finds that an eDRX cycle of 10485.76 seconds (2.91 hours) can result in power saving between 34-80% for a high SINR case and between 56-91% for a low SINR using an RRC_IDLE DRX cycle (with equal PTW length) from 2.56 seconds down to 320 ms. One source provides a plot of possible UE battery lifetime against eDRX cycle length. The battery lifetime for a UE with a 2-minute eDRX cycle compared to the same device with 10.24 seconds eDRX cycle is shown to result in between 0.38 – 340% improvements for RRC_IDLE and 1-419% improvements for RRC_INACTIVE, respectively. The evaluation has been performed for various use cases and inter-arrival times from 100 ms up to 5 minutes.

From RAN2 perspective, extended DRX is beneficial for UE power consumption and can be specified and configured for RedCap UEs so that eDRX cycles can be used in RRC_IDLE and in RRC_INACTIVE states. RAN2 sees a benefit extending the eDRX cycle in RRC_INACTIVE beyond 10.24 seconds for RedCap UEs for the following reasons:

  • It is very beneficial to have eDRX cycles > 10.24 seconds in RRC_INACTIVE to effectively support the use of Rel-17 SDT (small data transmission) e.g. for use cases with periodic uplink data with periodicity > 10.24 seconds. TS 22.104 provides such use cases, e.g. some industrial wireless sensors need to transfer small packets and have strict battery lifetime requirements, while not being sensitive to DL traffic delay.
  • Based on the results in Annex E.1, there is a clear power saving gain vs eDRX in RRC_IDLE at least for eDRX cycles in the range from 10.24 seconds up to couple of minutes, where the UE in eDRX in RRC_INACTIVE additionally benefits from less signaling. Based on these results, lifetime of several years would not be achievable in some cases (e.g. 1-minute inter-arrival time) if only RRC_IDLE can be used, because of the signaling overhead.
  • Signaling reduction is an additional benefit from network point of view – there is need for less RRC signaling.

The potential issues with eDRX extension beyond 10.24 seconds for RRC_INACTIVE are:

  • Impact on CN procedures (e.g. NAS retransmission), thus SA2/CT1 must be consulted on the feasibility.
  • Potential handling of different eDRX cycles > 10.24 seconds and/or PTWs, one for IDLE and the other for INACTIVE.
  • It needs to be studied which node decides and configures the eDRX cycle for RRC_INACTIVE.

Analysis of upper and lower bound of extended DRX cycles

For the upper bound, the eDRX cycle should support up to 10485.76 seconds, since the upper limit of the H-SFN (10 bits) already is 10485.76 seconds, and 5GC already supports eDRX values up to 10485.76 seconds for NB-IoT and LTE-MTC connected to 5GC. Although little power saving gain has been observed beyond 2621.44 seconds (simulation results show that the gain is saturated at around 40 minutes, see Annex E), there is no reason to artificially limit the range without technical concern, e.g., unless RAN4 indicates such eDRX value requires UE to perform RRM on serving cell outside PTW.

Shorter values than 5.12 seconds for the DRX cycles, such as 2.56 seconds, have also been studied. For the lower bound of the eDRX cycle, one motivation to support down to 2.56 seconds is that at least some RedCap UEs should be able to support the reception of emergency broadcast services (e.g. ETWS primary notification) within the required delay budget of 4 seconds while still saving power. This is not possible with 5.12 seconds eDRX cycle lengths. However, other solutions exist allowing RedCap UEs to receive emergency broadcast services without requiring eDRX to support lower cycle values than legacy LTE (5.12 seconds), while also saving power:

  • Solution 1: For RedCap UEs, if the NAS configures the UE with a 2.56 seconds DRX UE-specific paging cycle, the RedCap UE follows this DRX cycle even when the RAN paging cycle or default paging cycle is shorter.
  • Solution 2: gNB can configure 2.56 seconds default broadcasted DRX cycle for those RedCap UEs that need to receive emergency broadcast services and a shorter UE-specific RAN paging cycle can be configured for UEs with tighter latency requirements (e.g. smartphones).
  • Other solutions also exist that do not consider the power saving aspects for UEs receiving emergency broadcast services. For example, a simple solution is that RedCap UEs that need to receive emergency broadcast services do not request to be configured with eDRX, and no specific handling/configuration is required for those UEs. However, such RedCap UEs do not benefit from any specific eDRX power saving. Alternately, a RedCap UE could request an eDRX configuration while still monitoring for ETWS and CMAS in between the paging occasions.

There are different mechanisms to extend the DRX cycle beyond 10.24 seconds, which is discussed in clause 8.3.4 of TS 38.875.

RRM relaxation for stationary devices

RAN2 recommends that irrespective of RRC state, it is under network control whether to enable or disable RRM relaxation functionality for RedCap UEs.

RAN2 has studied different types of classification of potential RedCap UEs' mobility states, e.g. possibility to introduce a stationary mobility state. Considering the mobility of a RedCap UE, the stationarity property would not be limited to fixed or immobile UEs, but UEs which are considered stationary can also have low mobility, i.e., be slightly moving. In addition, another mobility option for "confined mobility" has been studied (see details in Enhancement 6 of triggering criterion in 8.4.1.1).

RAN2 has studied different enhancements to triggering RRM measurement relaxation and potential RRM relaxation methods for RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED. RRM relaxation for neighboring cell measurements for RRC_IDLE and RRC_INACTIVE is discussed in clause 8.4.2 and RRM relaxation for neighboring cells for RRC_CONNECTED in clause 8.4.3.

Analysis of UE power saving

  • 3GPP R2-2009620 presents plotted results for cases where the DRX cycle is 1.28 seconds, the number of intra- and inter-frequency cells is 8 with an SSB periodicity of 20 ms. The results are presented with the average power consumption plotted against how often the UE measures. The results show that power consumption does not change significantly for measurement relaxation beyond one hour (one-hour relaxation is the maximum possible in Rel-16).
  • 3GPP R2-2100459 shows the power saving gain for serving cell RRM relaxation in idle and connected mode. The simulation results show that 3.6%~13.4% power saving gain is observed when 4 times RRM relaxation for serving cell is adopted by high SINR for idle/inactive UE. Meanwhile, the results from 3GPP TR 38.840 show that by increasing measurement period 4 times for RRC_CONNECTED UEs, 11.1% - 26.6% power saving gains are observed, at the cost of an increase of handover failure rate from 0% to 0.26% for stationary or low mobility (e.g., 3 km/h) case.
  • 3GPP R2-2101257 shows the average power consumption and power saving gain when further expand the measurement interval from using three times scaling factor to stopping measurement for 1 hour. The result shows that for DRX cycle =1280 ms, stopping measurement for 1 hour can achieve power saving gain of 25.17% compared to 3-times relaxation.
  • 3GPP R2-2101257 shows the time reduction and power saving gain when the time duration for detecting/measuring SSBs can be reduced by reducing the number of measured SSBs. The power saving gain is 13.54% and 16.25% respectively if the time for SSBs detection/measurement is reduced by 62.5% and 75%.

UE identification and access restrictions

RedCap UEs need to be identified in order to ensure the network can provide services properly in the cell, e.g., to schedule messages and to possibly restrict the UE's access to the network.

The necessity on when RedCap UE needs to be identified depends on when the network needs to have information of the UE type in order to properly schedule the UE e.g. during the initial access.

Feasibility, necessity, pros and cons for the following schemes for identification of RedCap UEs have been studied:

  • Option 1: During Msg1 transmission
    • E.g., via separate initial UL BWP, separate PRACH resource, or PRACH preamble partitioning
  • Option 2: During Msg3 transmission
  • Option 3: Post Msg4 acknowledgment.
    • E.g., during Msg5 transmission or part of UE capability reporting
  • Option 4: During MsgA transmission
    • E.g., via separate initial UL BWP, or in MsgA preamble part via separate PRACH resource or PRACH preamble partitioning, or in MsgA PUSCH part

Conclusions and recommendations

UE complexity reduction

Based on the analysis of the UE complexity reduction techniques, the following is recommended for a RedCap UE:

  • Maximum UE bandwidth:
    • Maximum bandwidth of an FR1 RedCap UE during and after initial access is 20 MHz
    • Whether an FR1 RedCap UE can optionally support a maximum bandwidth larger than 20 MHz after initial access can be discussed during the WI phase or at RAN plenary.
    • Maximum bandwidth of an FR2 RedCap UE during and after initial access is 100 MHz
  • Number of Rx branches:
    • For FR1 FDD or FR2 bands where a non-RedCap UE is required to be equipped with a minimum of 2 Rx branches, the minimum number of Rx branches supported by specification for a RedCap UE is 1. The specification also supports of 2 Rx branches for a RedCap UE.
    • For FR1 TDD bands where a non-RedCap UE is required to be equipped with a minimum of 4 Rx branches, the minimum number of Rx branches supported by specification for a RedCap UE is N, where N is to be down-selected during the WI phase or at RAN plenary between the following alternatives:
      • Alt 1: N=2
      • Alt 2: N=1, where N=2 is also supported
  • Number of DL MIMO layers:
    • For a RedCap UE with 1 Rx branch, the maximum number of DL MIMO layers is 1.
    • For a RedCap UE with 2 Rx branches, the maximum number of DL MIMO layers is M, where M is to be down-selected during the WI phase or at RAN plenary between the following options (where different options may be selected for FR1 FDD, FR1 TDD, and FR2, respectively):
      • Option 1: M=1, where M=2 is also supported
      • Option 2: M=2
  • Half-duplex FDD operation:
    • HD-FDD operation type B is not supported for RedCap FR1 FDD UEs in Rel-17.
    • Decide at RAN plenary whether to have support FD-FDD or HD-FDD operation type A or both by specification for an FR1 FDD RedCap UE.
  • Relaxed UE processing time:
    • Decide at RAN plenary whether to support relaxed UE processing time in terms of N1 and N2 by specification for a RedCap UE.
  • Relaxed maximum modulation order:
    • Support of 256QAM in DL is optional (instead of mandatory) for an FR1 RedCap UE.
    • No other relaxations of maximum modulation order are supported by specification for a RedCap UE.

UE power saving

  • reduced PDCCH monitoring
  • extended DRX in RRC_INACTIVE and/or RRC_IDLE. the following are recommended from RAN2 perspective, where feasibility is to be confirmed with SA2 and/or CT1:
    • The applicable parts of eDRX mechanisms for LTE, including use of H-SFN, PH and PTW are expected to be re-used for RedCap UEs.
    • It is recommended that for eDRX cycles below and equal to 10.24 seconds PTW and PH is not used and that common design for handling eDRX cycle equal to 10.24 seconds in RRC_IDLE and RRC_INACTIVE is specified.
    • It is recommended eDRX cycles in RRC_IDLE are extended up to 10485.76 seconds, unless RAN4 indicates such eDRX value requires UE to perform RRM on serving cell outside PTW.
    • It is recommended eDRX cycles in RRC_INACTIVE are extended > 10.24 seconds.
  • RRM relaxation for stationary UEs
    • It is recommended that enabling or disabling RRM relaxation should be under network's control.
    • RAN4 should be consulted on feasibility of any RRM relaxation methods which are to be defined.
    • For RRC_CONNECTED, it is recommended that UEs which are fixed or immobile are considered with higher priority compared to UEs which are slightly moving.
    • Irrespective of RRC state, serving cell RRM relaxation for RedCap UEs is not recommended to be specified.

Reduced capability signaling framework

  • At least for device type identification and possibly for constraining the use of reduced capabilities, the network needs to know whether the UE is RedCap UE or not.
  • As a baseline, the existing UE capability framework is used to indicate the capabilities of RedCap UEs.
    • The capabilities for RedCap UEs can be categorized as mandatory capabilities, which all RedCap UEs support, and possible optional capabilities, signaled explicitly.
    • The final categorization of capabilities into the studied categories depends on the exact capabilities applicable to RedCap UEs, to be defined during the WI phase.
    • The network should be able to control that the RedCap UEs are only used for the intended use cases

Identification and access restriction

  • RedCap early indication in Msg1, Msg3, MsgA, or in a later message have been studied
  • The necessity of early indication depends on the need for the network to know whether the UE accessing the system is a RedCap UE during the initial access, e.g. depending on the need of coverage recovery, different scheduling of RedCap UEs, or additional access restrictions.
  • Different mechanisms for access control of RedCap UEs in RAN have been studied
    • It is recommended to specify a system information indication to indicate whether a RedCap UE can camp on the cell or not.
    • Unified access control (UAC) should apply to RedCap UEs and one option is that UAC can differentiate between RedCap and non-RedCap UEs.
    • It is possible to use RRC connection reject if the network knows the UE is a RedCap UE, however, preferably access control should happen earlier.