RedCap - expanding the 5G device ecosystem for consumers and industries

The IoT segment served by cellular networks can be divided into Massive IoT, Broadband IoT, Critical IoT, and Industrial Automation IoT, where Broadband IoT is forecasted to constitute 60 percent of the cellular IoT connections by the end of 2028¹. Broadband IoT includes both wide-area and local-area use cases that require higher throughput, lower latency, and larger data volumes than what Massive IoT technologies can support. These use cases include, for example, smart wearables and industrial sensors. In the past, Broadband IoT use cases were often served by 4G long-term evolution (LTE) device categories 1 and 4. The device complexity, and hence the device cost, has so far been too high for 5G New Radio (NR) to be suited to Broadband IoT, which motivated the introduction of reduced capability (RedCap) 5G NR devices in 3GPP Release 17².

Figure 1 illustrates different 4G/5G device types. At the low end, there is the NB-IoT device category (Cat-NB1) and the LTE-M device category (Cat-M1), which both support relatively low data rates suitable for Massive IoT use cases. Since 3GPP Release 15, both NB-IoT and LTE-M fulfill the 5G massive machine-type communications (mMTC) requirements and are therefore components of both 4G and 5G. At the high end, both LTE and NR have device types for high peak rates for demanding use cases. In between the low and the high end, LTE offers several device categories (that is, Cat-1/2/3/4), and RedCap provides corresponding NR-based device types for this mid-range segment.

The simplest RedCap device, that is, a RedCap device with the lowest possible complexity, is expected to reduce the modem complexity by about 65 percent for low- or mid-band (FR1) devices, and by about 50 percent for high-band (FR2) devices, while high enough peak data rates are maintained to still serve more demanding IoT use cases. A RedCap device equipped with more advanced (but not mandatory) capabilities can support much higher peak rates. For example, a RedCap device with two receive antenna branches and downlink multiple-input multiple-output (MIMO) layers can support twice as high downlink peak rates as the simplest RedCap device, since this allows dual-stream transmissions over two MIMO layers.

The other aspect which is needed to fulfill IoT requirements is low energy consumption, and this has been enabled by the introduction of extended discontinuous reception (eDRX) cycles and relaxations for radio resource management (RRM) monitoring (on top of the Release 16 measurement relaxations which can also be supported by RedCap devices). In combination, the introduced features provide a substantial complexity reduction and an extended battery life for RedCap devices which enable NR to efficiently address Broadband IoT use cases ranging from factory automation and Industry 4.0 to low-end augmented reality (AR) and virtual reality (VR) applications.

The introduction of RedCap will enable a single network, i.e., a 5G standalone network consisting of both RAN and core network, to address a variety of use cases for industry digitalization and business transformation. Furthermore, RedCap will help expand the 5G ecosystem and connect significantly more devices to 5G networks. This includes upgrading the LTE-based networks that have been deployed to provide global IoT coverage. With the introduction of RedCap, a smooth migration to NR for supporting such use cases can then be accomplished without the need for network deployments with multiple RATs.

Examples of use cases that will be addressed by RedCap include wearables such as smart watches, wearable medical devices, and low-end AR/VR glasses, video surveillance, industrial sensors, smart grids, and so on (see Figure 2).

These use cases have a huge market potential, worth tens of billions of dollars. For example, the global end-user spending on wearables alone was estimated to be USD 81.5 billion in 2021, an increase of 18 percent compared to 2020, and is estimated to increase to USD 94 billion in 2022, according to Gartner³. For industrial applications, RedCap services can provide robust wireless connectivity and seamless mobility support through 5G networks for industrial devices enabling cost-efficient Industry 4.0 transformation.

Each addressable RedCap use case has its own set of requirements which, compared to regular 5G NR devices, is less demanding in terms of data rates and latency, yet more stringent when it comes to device cost/complexity and power consumption. However, the battery life requirements for RedCap use cases are relatively relaxed compared to those of mMTC use cases. In fact, as illustrated in Figure 3, RedCap is designed to efficiently support use cases whose requirements fall between the more extreme requirements defined for mMTC, ultra-reliable low-latency communications (URLLC), and enhanced mobile broadband (eMBB). However, RedCap devices may also be suitable for moderate (less extreme) mMTC/URLLC/eMBB use cases. For example, when comparing RedCap requirements with eMBB, URLLC, and mMTC use cases, the following can be noted²:

• Latency: The target for URLLC is about 1 ms, while for RedCap use cases it is less than 100 ms for industrial sensors and less than 500 ms for video surveillance. However, these are minimum requirements, and it is worth noting that RedCap devices can in fact achieve much better latency than this.
• Data rates: The target peak rate for eMBB is up to 20 Gbps in downlink and 10 Gbps in uplink, while for the most demanding RedCap use cases (e.g., wearables) it is up to 150 Mbps in downlink and 50 Mbps in uplink.
• Battery life: The target for mMTC is 10 to 15 years battery life, while for RedCap use cases it is a few years for industrial sensors and one to two weeks for wearables. Again, these are minimum requirements, and RedCap devices may be able to achieve a longer battery life.

With RedCap and its evolution, 5G can efficiently address mid-tier Broadband IoT use cases in addition to the three key usage scenarios (eMBB, URLLC, mMTC) using any available 5G spectrum, both time-division duplex (TDD) and frequency-division duplex (FDD), in all (low/mid/high) frequency bands. Our analysis shows that RedCap can sufficiently meet requirements of various Broadband IoT use cases in terms of data rates, latency, battery life, and small form factors. Compared to LTE device category 4, RedCap offers similar data rates with improved latency and potential support for various 5G NR features including enhanced positioning (important for personal trackers), millimeter-wave operations with advanced beamforming support, and network slicing.

Today, many of the targeted use cases for RedCap can be served by low-end LTE devices, which have substantially lower device hardware requirements than the simplest NR device. Therefore, as mentioned in the Introduction, the need to introduce a lower-complexity NR device type with reduced capabilities roughly corresponding to the capabilities of a low-end LTE device has been identified.

The NR modem cost/complexity reduction is accomplished by using the techniques summarized in Table 1 below². In the table, the “Simplest regular 5G device” corresponds to a basic 5G NR device such as a smartphone with only the minimum capabilities that are mandatory to support for such a device, whereas the “Simplest RedCap device” corresponds to a basic RedCap device with only the minimum capabilities that are mandatory to support for a RedCap device, and the “Most advanced RedCap device” corresponds to a RedCap device with the most advanced (but optional) capabilities that can be implemented.

Our analysis shows that, compared to the simplest regular 5G device, the techniques in Table 1 can help to reduce the bill-of-materials cost for the simplest RedCap device by about 65 percent in low/mid (FR1) frequency bands and by about 50 percent in high (FR2) frequency bands. Furthermore, the reduction in the number of receive antenna branches can also help to reduce the physical size of the device.

There can be RedCap devices with capabilities in-between those of the simplest and the most advanced RedCap devices. For example, a RedCap device can support two downlink MIMO layers without supporting 256 quadrature amplitude modulation (QAM) in the downlink. However, a RedCap device cannot support transmit/receive bandwidths larger than 20 MHz for low/mid frequency bands or more than 100 MHz for high frequency bands. Also, it cannot support features and capabilities relating to carrier aggregation, dual connectivity, more than two receive antenna branches, more than two downlink MIMO layers, more than one transmit antenna branch, or more than one uplink MIMO layer.

In addition to those techniques listed in Table 1, a few optional complexity reduction techniques for the higher layers of the radio protocol stack have also been introduced for RedCap devices. These include a reduction in the maximum number of data radio bearers from 16 to 8, a reduction in sequence number length for packet data convergence protocols (PDCP) and radio-link control (RLC) layers from 18 bits to 12 bits, and making automatic neighbor relation functionality an optional capability. The higher-layer complexity reduction techniques mentioned in this paragraph are not expected to impact the peak data rate.

Table 1: Comparison of the simplest regular 5G device with the simplest and the most advanced RedCap device.

Note 1: This capability has not been relaxed for RedCap UEs. It has been included in the table for the sake of completeness.

Note 2: PC 3 in FR2 is associated with handheld devices.

Note 3: PC 7 is a lower power class than PC 3, and therefore, it has lower radiated power and lower reference sensitivity requirements than PC 3. Consequently, RedCap devices supporting PC 7 can be equipped with fewer antenna elements and/or panels than that of devices supporting PC 3.

The complexity reductions in Table 1 would impact the achievable peak data rate, and for the simplest RedCap device, the resulting peak data rates in downlink/uplink are approximately:

• 85/90 Mbps in low (FR1 FDD) bands, assuming 15 kHz subcarrier spacing, and that the device supports full-duplex FDD. The peak rates will be lower for half-duplex FDD devices as they cannot transmit and receive at the same time.
• 50/35 Mbps in mid (FR1 TDD) bands, assuming 30 kHz subcarrier spacing and a downlink/uplink split of 60/40 percent.
• 240/175 Mbps in high (FR2 TDD) bands, assuming 120 kHz subcarrier spacing and a downlink/uplink split of 60/40 percent.

These peak rates are sufficient to fulfill the requirements of most of the intended use cases for RedCap. A more advanced RedCap device can support a higher peak rate, which could be useful for low-end AR/VR use cases. Figure 4 shows a comparison of the maximum achievable peak data rates in different bands for the simplest regular 5G device, the most advanced RedCap device, and the simplest RedCap device.

In principle, the devices can support an even lower peak data rate than those shown in Figure 4 by reporting a down-scaled peak rate using so-called peak rate scaling factor. For example, the RedCap devices are only required to support peak rates in downlink/uplink of approximately 55/60 Mbps (rather than 85/90 Mbps) in FDD bands.

Some of the targeted RedCap use cases have more stringent requirements on device battery life compared to 5G use cases in general. Also, as described earlier, the different RedCap use cases have different device battery life requirements. Therefore, the solutions for device battery life improvement need to account for such diverse requirements. To meet the requirements, RedCap supports reduced device activities in terms of downlink monitoring and mobility measurements, as outlined below.

Extended discontinuous reception mechanism

The key to extend battery life is the discontinuous reception (DRX) mechanism. This is a mechanism where a device turns off its receiver circuitry over periods of time to save power. In 5G, the network can configure a device with DRX cycles that can vary from a few hundred milliseconds to a few seconds (up to 2.56 seconds), depending on the downlink latency requirements. This value range has been extended in Release 17 by introducing eDRX for RedCap devices. The value range for eDRX cycles is up to about 3 hours for devices in Radio resource control (RRC) Idle mode and 10.24 seconds for devices in RRC Inactive mode. This range is the same as for the existing Massive IoT technology NB-IoT and, therefore, the relative power savings could in principle be as large for RedCap as for NB-IoT.

The potential drawback with eDRX is the increased downlink latency since the device cannot respond until the end of the sleep cycle. The device wakes up less frequently when configured with eDRX cycles and is not mandated to monitor paging messages and notifications during the sleep cycles. However, since RedCap use cases do not have as stringent latency requirements as eMBB or URLLC use cases, latency can potentially be traded-off for battery life improvement.

Furthermore, the device cannot stay in a sleep state when there is data activity in the uplink. Therefore, the more frequent the data transmissions are in the uplink, the smaller the improvements are in battery life.

In consequence, the magnitude of improvement in battery life depends on how often the device has something to transmit in the uplink and how much time the device can spend in a sleep state during the sleep cycles. This is demonstrated in Figure 5 where different average uplink data interarrival times (IATs) are illustrated by different curves and one can observe that improvement in battery life increases with the length of the eDRX sleep cycle for RRC Idle mode.

The gain is therefore the biggest for a device with very relaxed downlink latency requirements, such that an eDRX cycle of close to three hours can be configured, and with very infrequent data transmission in the uplink. With the value range considered in these evaluations, the gain is, for example, the largest for a two-hour eDRX cycle with data transmission activity in the uplink on average every three hours, in which case the battery life can be extended by 80 times compared to a non-eDRX case.

In Release 18, the maximal eDRX cycle length in RRC Inactive will also be extended to about three hours⁴ to give a similar gain to that of eDRX in RRC Idle.

RRM measurement relaxation for RedCap devices

To achieve the best performance, both for the device itself and for the network as a whole, it must be ensured that the device connects to the base station with the strongest signal strength. For this reason, devices perform RRM mobility measurements on downlink signals broadcasted by the base station. This consumes energy in the device since the receiver, and sometimes also the transmitter, needs to be kept active. One way to extend device battery life is to relax the requirements to allow RedCap devices to perform the measurements less frequently. For this purpose, it is recommended to apply relaxed cell monitoring (also known as relaxed measurements) which allows the device to measure less often based on the operating scenarios. The operating scenarios are characterized by the mobility and the location of the device in the cell.

In general, all 5G devices can be operated in different activity states, such as the two low activity states (RRC Idle and RRC Inactive) and the high activity state (RRC Connected). In RRC Idle and RRC Inactive states, the relaxed measurements introduced in Release 16 NR for regular 5G devices allow the device to measure less often or in some cases not to measure at all on the neighbor cells when the device is operating under limited mobility or when it is not located at the cell border. The relaxed measurements introduced for RedCap in Release 17 allow even further relaxation and supports new relaxation scenarios compared to the Release 16 relaxation. For example, the relaxation factors and period of time to not perform any measurements on neighbor cells are extended, and moreover, relaxation in stationary scenario is introduced for RedCap. This improves the battery life of the RedCap device.

Furthermore, eDRX can be configured for a RedCap device in RRC Idle or RRC Inactive states together with relaxed measurements. This enables the device to improve its battery life more than what can be achieved with only RRM measurement relaxation.

In RRC Connected state, there is no solution to support relaxed RRM monitoring for regular 5G devices. Solutions are introduced for RedCap to identify low mobility scenarios and report the result to the network. This information serves as a basis for the network to find suitable measurement configurations in the device to achieve further battery life improvements.

It is expected that these relaxed measurement methods will enable the longer device battery life required to serve some of the RedCap use cases.

It is important that different device types can co-exist efficiently within the same cells in the same network. There is a potential risk that reducing the bandwidth or number of antennas of the RedCap devices will have undesired impacts both on the performance of the RedCap devices themselves as well as on other (non-RedCap) devices. If desired, the network can bar access to a cell for all RedCap devices or for a subset of them (specifically, RedCap devices with a single receive antenna branch and/or RedCap devices not supporting full-duplex operations). However, as described in the following subsections, it is generally possible to support efficient coexistence between different device types without significant negative impact on the overall network performance.

Ensuring good coverage for RedCap devices in an efficient way

In a cellular network, it is important to ensure good coverage for all devices. For a device to have good coverage, it needs to be able to receive and transmit multiple data channels and control channels in downlink and uplink.

For low-to-mid frequency bands (FR1), since a RedCap device has reduced bandwidth and a reduced number of receive antenna branches, the performance of downlink channels may be impacted. However, we expect that the RedCap device will achieve similar coverage as a regular 5G device. The reason is that, even with the reduced capabilities, the performance of downlink channels of a RedCap device is better than the bottleneck (weakest) channel of the regular 5G device. The bottleneck channel determines the coverage of the cell. For a regular 5G device, the bottleneck channel is typically the uplink data channel (PUSCH). Therefore, there may not be a need for redimensioning existing 5G networks prior to RedCap deployment.

For high frequency bands (FR2), the number of receive antenna branches has not been reduced for the RedCap device. Also, the RedCap device supports a relatively large bandwidth of 100 MHz in FR2. Based on these considerations, the RedCap device is expected to achieve similar coverage as the regular 5G device. However, as shown in Table 1, the RedCap device can support a lower power class in FR2. This reduces the radiated power requirements in the uplink and the reference sensitivity requirements in the downlink. Therefore, the coverage of some of the uplink and downlink channels may be impacted for devices using the lower power class. However, it is expected that the coverage can be recovered using traditional techniques, such as retransmissions for data channels.

It is also desired to ensure coverage for RedCap devices without increasing the required radio resources for downlink transmissions unnecessarily. For the network to efficiently schedule devices with different capabilities, and thus to avoid unnecessarily using many radio resources, there may be a need to identify RedCap devices early on, possibly already in the beginning of the initial-access procedure. Therefore, a RedCap device identifies itself as a RedCap device in Message 3 of the random-access procedure (which is part of the initial- access procedure). In addition, there is a possibility for the network to configure a RedCap device to identify itself already in Message 1 of the random-access procedure.

Avoiding resource fragmentation and signaling overhead

The frequency spectrum is a fundamental resource shared between the users in a cellular network. In every time slot, the base station tries to schedule data transmissions for different users efficiently in the frequency domain to achieve both high user throughput and high system capacity. This is true for both downlink and uplink, but uplink scheduling presents an additional challenge since each device may only be able to utilize uplink resource allocations that are contiguous in the frequency domain.

Since RedCap devices have a maximum bandwidth which may be much smaller than the total cell bandwidth, one potential coexistence issue when deploying RedCap devices and regular (non-RedCap) devices in a cell is uplink resource fragmentation. If such resource fragmentation prevents regular devices from utilizing the entire available bandwidth, they may not be able to transmit the data quickly over a wide contiguous frequency allocation in uplink and are instead forced to transmit in a narrower bandwidth allocation over a more extended period. This may result in a significant uplink peak data rate reduction for those regular devices.

Therefore, we want to highlight two mechanisms that have been standardized to minimize fragmentation of uplink resources for regular 5G NR devices due to transmission from RedCap devices. These mechanisms are described below and illustrated in Figure 6.

First, the network can configure a RedCap-specific initial bandwidth part (BWP) separate from the initial BWP used by regular devices. This RedCap-specific initial BWP can be placed near the edge of the uplink frequency resource to free up contiguous resources in the center for regular devices. Since the RedCap-specific initial BWP is primarily intended to be used only briefly during initial access, it can be configured without the ordinary periodic downlink transmissions of synchronization signals and system information, thus avoiding additional signaling overhead.

Second, the network can disable frequency hopping for all transmissions from RedCap devices to further reduce the uplink resource fragmentation. In regular 5G NR, many transmissions can be carried out using frequency hopping to improve the probability of successful reception in case of imperfect propagation conditions. However, when a transmission hops between different frequencies, it may contribute to undesired resource fragmentation, so it may be a good idea to deactivate the frequency hopping when it is not needed. In regular 5G NR, the frequency hopping can be deactivated for all transmissions except for one, but for RedCap devices the frequency hopping can also be deactivated for this transmission (to be specific, a transmission of a 1-bit acknowledgment on the so-called physical uplink control channel (PUCCH) during the initial access procedure) to minimize uplink resource fragmentation.

Ensuring high network capacity and cell spectral efficiency

Because of the device complexity reductions, RedCap link performance will inevitably be reduced. With many RedCap users in the network, there may be a concern that this could indirectly lead to worse performance for non-RedCap and negatively impact, for example, eMBB performance. Therefore, we have run system level simulations to study the impact based on the evaluation assumptions agreed by 3GPP (see details and further results in⁵). In the uplink, we found that the presence of RedCap users does not have any noticeable impact on the eMBB user throughput and performance. For the downlink, RedCap devices with 1 receive antenna branch would have the largest impact, and in Figure 7 the median eMBB user throughput is shown for an increasing fraction of such RedCap users (note that unlike the user throughput, the cell throughput is averaged over time also when there is nothing to transmit).

As can be seen from the results in Figure 7, at low average cell load no impact on the eMBB user throughput can be seen. At higher load, a slight degeneration of the eMBB performance can be noted but only for a fraction of 50 percent or more of RedCap users with 1 receive antenna branch. For eMBB users in bad coverage (fifth percentile) the tendency is the same, and for eMBB users in good coverage (95th percentile), no impact at all from an increasing RedCap user fraction can be noticed. The conclusion from these simulations is therefore that in realistic cases where most users are not of RedCap type with 1 receive antenna branch and the load is not high, there will in practice be no noticeable impact on eMBB performance.

As mentioned above, the RedCap devices introduced in Release 17 have similar peak rates and complexity as existing low-end LTE device categories (for example, Cat-2, Cat-3, or Cat-4). This makes RedCap devices ideal for replacing low-end LTE devices when use cases today served by low-end LTE devices eventually need to be migrated to NR. The device hardware requirements (in terms of bandwidth, number of antennas, supported modulation, and so on) are similar to low-end LTE devices, which facilitates implementation of dual- mode devices supporting both a low-end LTE device category and a RedCap device type if needed.

Furthermore, for IoT use cases with even lower peak rate requirements, a new RedCap device type will be introduced in Release 18 with a peak rate target of about 10 Mbps⁴, which is comparable to the peak rate for the lowest ordinary LTE device categories (that is, Cat-1 and its single-antenna variant Cat-1bis). However, it is expected that the additional complexity reduction compared to the simplest Release 17 RedCap device will be relatively small (less than 10 percent). For a comparison between 4G and 5G device types, see Figure 1.

Moreover, accurate positioning for location services is crucial for many IoT use cases. Basic positioning is supported for RedCap devices already in Release 17, but Release 18 introduces improved positioning support for RedCap devices, adjusting for their reduced capabilities.

Since 5G NR supports a wider range of frequency bands and deployment options compared to LTE/LTE-M/NB-IoT, it can be expected that RedCap devices can enable IoT use cases in new scenarios. For example, it may be desired to support Massive IoT use cases in frequency bands where LTE-M/NB-IoT either has no standard support or no product ecosystem (for example, in mid/high TDD bands), and in such cases we envision RedCap to be able to serve as a substitute for LTE-M/NB-IoT.

From a network point of view, support for RedCap devices can be expected to be introduced as a software upgrade of the network, that is, without the need for any new hardware deployments. It should be noted that RedCap supports the same spectrum sharing techniques⁶ as normal NR, meaning that different device types (LTE, LTE-M, NB-IoT, NR, RedCap) can be supported on the same cell carrier if desired.

The introduction of RedCap devices in Release 17 is expected to expand the 5G device ecosystem by introducing new devices with lower cost/complexity, smaller size, and longer battery life than regular 5G NR devices. For many IoT use cases, which are not high-end, NR devices are overly capable, and they may not be cost-efficient for such use cases. RedCap, which belongs to the Broadband IoT category, is introduced to match this market segment. Important use cases envisioned for RedCap include wearables, industrial wireless sensors, video surveillance cameras, and low-end AR/VR applications.

Moreover, RedCap devices are ideal for replacing low-end LTE devices when use cases today served by low-end LTE devices eventually need to be migrated to NR. RedCap can also serve as a substitute for LTE-M/NB-IoT in frequency bands where they have no standard support or no product ecosystem (for example, in mid/high TDD bands).

Further device simplifications for RedCap are expected in Release 18 to provide improved support for Release 17 use cases, and support expansion into new segments of use cases. However, the further cost/complexity reduction in Release 18 is expected to be small compared to Release 17.

As described in this white paper, it is possible for a RedCap device to efficiently co-exist with other NR device types without significant negative impact on the overall network performance. Furthermore, RedCap inherits many of the key benefits of 5G NR such as support for a wide range of frequency bands (including millimeter-wave bands) and deployment options, native 5G core network, high network energy efficiency due to lean NR design, low latency, beam-based air interface, and so on.

To summarize, RedCap expands the 5G device ecosystem for consumers and industries in ways that are attractive both from device and network points of view.