RedCap: Cellular IoT Technology for the 5G Era
Even before the Third Generation Partnership Project (3GPP)’s Release 15 set the foundation for 5G New Radio technology, 3GPP established three pillar use cases for 5G: enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), and massive machine-type communications (mMTC).
While these technologies are now enabling a host of real-world applications in manufacturing, retail, healthcare, education, and virtual reality -- to name just a few -- they are just the beginning. While 5G NR is enabling a host of new IoT applications, there remained a gap in providing a 5G flavor of cellular IoT to enable mid-tier applications like wireless sensors, healthcare monitoring wearables, and new types of surveillance equipment.
But with the completion of Release 17 last year, 3GPP introduced several enhancements to provide connectivity to mid-tier IoT devices that lack the need for the full capabilities of 5G NR but have much more stringent cost and power consumption requirements. These RedCap devices will benefit from the power and scale of 5G deployments but leverage fewer 5G capabilities for an optimum balance of features versus cost and power efficiency.
Like other cellular IoT technologies such as LTE Cat M, extended coverage GSM IoT (EC-GSM-IoT), and narrowband IoT (NB-IoT), RedCap occupies an important niche and should see very strong growth in adoption in the years to come.
RedCap device tradeoffs
RedCap devices use fewer antennas than standard 5G user equipment (UE) to reduce cost and complexity (and decrease the number of multiple-input multiple-output (MIMO) layers). RedCap devices support 2x2 MIMO for the downlink and single-input single-output for the uplink.
RedCap implements several other tradeoffs to reduce cost, complexity, and power consumption. They include:
- Limited device bandwidth. RedCap devices have a maximum bandwidth of 20 MHz for frequency range 1 (FR1) and 100 MHz for frequency range 2 (FR2).
- Different transmission mode. RedCap devices support for half-duplex frequency division duplex (FDD) transmission, which reduces cost by enabling RedCap devices to use switches rather than more expensive duplexers. As a consequence, RedCap devices cannot perform simultaneous transmission and reception.
- Reduced network monitoring scheme. RedCap devices limit the number of blind decoding and control elements monitored in the physical downlink control channel (PDCCH), reducing the amount of power required for these tasks.
- Extended discontinuous reception (eDRX). RedCap increases eDRX cycles when the device disconnects from the network or becomes idle, substantially prolonging the battery life of a RedCap device, but decreasing mobility performance.
- Relaxed radio resource management (RRM) requirements for devices that are not located at the cell edge and introduces a radio resource control (RRC) inactive state. which allows the UE to make small data transmissions without transitioning the RRC-connected state.
- No support for carrier aggregation. RedCap devices support only single connectivity, enabling them to operate in 5G standalone mode only.
Connecting to the network
Release 17 enhancements also specify new procedures to enable a RedCap device to establish and maintain connections to 5G networks.
5G networks must adapt to the specific features of RedCap during the random-access process and when the device stays connected. RedCap introduces new information elements (IEs) to enable the bandwidth to adapt dynamically.
Some of these new IEs pertain to the permission for a RedCap UE to camp in a cell or use half-duplex mode. Some IEs are required to enable a RedCap device to connect to a cell; when these IEs are not detected the cell will bar RedCap devices from connecting and the RedCap device will have to start the RRC procedure to connect to another cell where the required IEs are present.
Other IEs govern bandwidth part (BWP) configuration, enabling flexible spectrum use. This saves power by dynamically adapting the assigned bandwidth depending on what the UE is doing. Low bandwidths impact the random-access channel (RACH) procedure used by the devices to access the network. The network can specify a BWP for RedCap devices or reduce the size of the BWP for these devices to attach to the network.
New signaling parameters and procedures require device engineers to check the compatibility of their devices to ensure connectivity. RedCap device development also requires debugging tools specific to RedCap parameters.
Competing technologies
Initially, RedCap faces stiff competition from established cellular IoT technologies like Cat M and NB-IoT. According to Transforma Insights, these technologies will be difficult to displace in the near term because they are less costly and generally offer functionality that is more than adequate for most IoT applications. But in the long run, RedCap has a tremendous opportunity to take market share as it is refined in future iterations and IoT applications emerge that demand more capability than legacy C-IoT technologies provide.
Regardless of how robust the immediate outlook will be for RedCap uptake, there is no question that some applications will pounce on RedCap and implement it immediately. As with any cellular device, testing will play a critical role in RedCap device development.
Keysight was the first vendor to offer RedCap test support with its 5G Network Emulation Solutions portfolio, working with MediaTek last year to establish connectivity to MediaTek’s 5G chips using Release 17 and RedCap specifications. Keysight’s latest wireless test platform, the E7515R UXM 5G, a streamlined network emulator specifically designed for protocol, RF, and functional testing of all C-IoT technologies, including RedCap.
Additional resources: