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

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.

Introduction to UE complexity reduction features

The following UE complexity reduction techniques have been studied:

• Reduced number of UE Rx branches
• UE bandwidth reduction
• Half-duplex FDD operation
• Relaxed UE processing time
• Relaxed maximum number of MIMO layers
• Relaxed maximum modulation order
• Combinations of UE complexity reduction features

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:

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.

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.

UE bandwidth reduction

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.

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.

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.

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.,

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.

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.

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.

Relaxed maximum modulation order

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:

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

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

Introduction to UE power saving features

The following UE power saving techniques have been studied:

• Reduced PDCCH monitoring by smaller numbers of blind decodes and CCE limits
• Extended DRX for RRC Inactive and/or Idle
• RRM relaxation for stationary devices

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

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

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.

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:

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.