0% found this document useful (0 votes)
92 views15 pages

Boost IoT With 5G NR RedCap - Whitepaper

RedCap whitepapaer

Uploaded by

patrick wang
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
92 views15 pages

Boost IoT With 5G NR RedCap - Whitepaper

RedCap whitepapaer

Uploaded by

patrick wang
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

WHITE PAPER

Boost IoT with 5G NR RedCap


Optimized design meets use case requirements
for low cost and power consumption
Table of Contents
RedCap: 5G NR to Support IoT Growth....................................................................................3

Evolution of Cellular IoT ........................................................................................................... 4

How RedCap Fits into 5G NR Use Cases...................................................................................5

First RedCap Release in R17...................................................................................................... 6

Key RedCap Parameters in R17................................................................................................10

RedCap Signaling Test with UXM 5G...................................................................................... 12

For More Information............................................................................................................... 14

RedCap Will Boost IoT.............................................................................................................. 15

2
RedCap: 5G NR to Support IoT Growth
The adoption of 5G New Radio (NR) has grown rapidly since its first commercial launch in
2019, bringing a significant boost in data rates to mobile devices. As of February 2022, nearly
200 operators in more than 60 countries had launched 5G mobile services. With the 3rd
Generation Partnership Project’s (3GPP) Release 17, 5G NR expands its reach to new users with
diverse requirements.

While applications such as Time-Sensitive Networks (TSNs) require very low latency and a robust
downlink and uplink, many Internet of Things (IoT) applications have lower capacity and latency
requirements, but have stringent cost and power consumption constraints.
Count of operators investing in 5G and operating commercial 5G networks

Investing Launched
500
450
400
350
300
250
200
150
100
50
0 2Q18 3Q18 4Q18 1Q19 2Q19 3Q19 4Q19 1Q20 2Q20 3Q20 4Q20 1Q21 2Q21 3Q21 4Q21 2022 YTD

Figure 1. Count of operators investing in 5G and operating commercial 5G networks


Source GSA-5G Market Update (February 2022)

This white paper looks back at the first cellular technologies that supported IoT. It examines 5G
NR reduced capability (RedCap) devices, a category of user equipment (UE) that requires more
capacity than LTE-based technologies (Cat-M or NB-IoT) provide and supports low cost and power
consumption. It includes a review of the new parameters and the most relevant changes introduced
in 3GPP R17 Layer 1, Layer 2, and Layer 3 procedures to support new RedCap devices.

IoT device shipments are on track to grow at double-digit rates through the 2020s. 5G NR RedCap
can succeed if it adequately meets the coverage, cost, and power consumption requirements of IoT
applications while operating on 5G networks, enabling operators to support all services with a single
cellular radio access technology (RAT).

3
Evolution of Cellular IoT
Mobile networks have evolved from supporting strictly voice services to supporting voice and data
connectivity services. This development enabled cellular networks to incorporate electronic devices
deployed in the field to monitor conditions and send data remotely, reducing the cost of operating
certain types of sensors and equipment by requiring fewer on-site visits. But this change required the
creation of globally accepted interoperability standards. These standards, which define the protocols
and RF interfaces, seek to minimize the incremental cost of devices to maximize the cost benefit of
remote wireless access.

3GPP first included technologies for these types of devices in Release 13 and added subsequent
enhancements up to Release 16. The 3GPP standards defined three categories of technologies as
cellular IoT (C-IoT):

• extended coverage GSM IoT (EC-GSM-IoT) based on 2G, aiming to leverage the existing networks
and subscriber base

• LTE for machine-type communications (LTE-M), compatible with regular LTE

• Narrowband IoT (NB-IoT), which brought new device specifications to further optimize power
consumption and coverage even in tough environments such as underground installations

Table 1. Release 13 IoT technology capabilities

NB-IoT (Rel-13) LTE-M (Rel-12 / 13) EC-GSM (Rel-13)

Range max. coupling loss < 15 km 164 dB < 11 km 144 dB < 15 km 164 dB

Spectrum bandwidth Licensed Licensed Licensed


700 – 900 MHz 700 – 900 MHz 800 – 900 MHz
200 kHz or shared 1.4 MHz or shared 2.4 MHz or shared

Data rate < 100 kbps < 1 Mbps

Voice service No Yes Yes

Battery life > 10 years > 10 years > 10 years

Compared with competing technologies, C-IoT can offer enhanced quality of service because it uses
regulated spectrum and support from mobile network operators. It achieves global compatibility by
adhering to 3GPP standards and certification organizations such as the Global Certification Forum
(GCF) and PCS Type Certification Review Board (PTCRB).

4
How RedCap Fits into 5G NR Use Cases
Enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), and
massive machine-type communications (mMTC) were the foundational goals of 5G NR. More
recently, 3GPP added TSN to the list.

The concept of RedCap is to build user equipment (UE) that can benefit from the scale of 5G NR
deployments but leverage fewer 5G NR capabilities for an optimum balance of features versus cost
and power consumption. 3GPP created a study item to research support for reduced-capability NR
devices. The study item ultimately became a 3GPP work item, with RedCap introduced in Release 17.

URLLC, mMTC, and TSN cover IoT connectivity with high-bandwidth and low-latency requirements,
such as manufacturing line robotics and drones. But they do not necessarily cover connectivity for
sensors, actuators, and other IoT equipment with lower performance requirements that are typically
cost- or form-factor constrained. These devices may send asynchronous information in small packets
but need radical cost optimization in initial purchase and operational maintenance for which battery
life duration is critical.

Apart from “smart” industries, 3GPP also included two other RedCap use cases in Release 17
specifications: surveillance devices and wearables that can gather and relay health and wellness
information.

5
First RedCap Release in R17
Figure 2 lists the main areas of interest for RedCap and the major initiatives undertaken in Release 17:

Cost-reduction Low power consumption


Use case
strategies enhancements

• Industrial sensors • Reduced • Relaxed DL


• Wearables Tx / Rx and MIMO and RRM monitoring
• Surveillance • Reduced bandwidth • Extended disconnect
• Half-duplex receiver times
and reduced antenna gain • Small data transmission

Figure 2. 5G NR RedCap goals and related implementation strategies

The initial use cases under analysis show low data throughput and latency requirements compared
with other 5G NR devices that will support eMBB (Table 2).

Table 2. RedCap’s first use cases, data rate, and latency requirements

Use case Data rate (max) End-to-end latency Service availability

Wireless industry sensor 2 Mbps < 100 ms 99.99%

Wearables 25 Mbps

Surveillance 150 Mbps (DL), < 500 ms 99 – 99.9%


50 Mbps (UL)

Source: 3GPP TR 38.875

6
Release 17 introduces the necessary changes to the 5G specifications to support devices with reduced
capabilities. Examples include the following:

• the use of reduced bandwidth of 20 MHz with implications in the bandwidth part (BWP)
configurations both in downlink (DL) and uplink (UL)

• support for devices with a single transmitter and receiver branch

• support for one DL layer and one UL layer

The initial deployments of RedCap devices will be on a single connection, which NR can support with
frequency range 1 (FR1) and frequency range 2 (FR2) standalone deployments.

Release 17 also supports half-duplex frequency division duplex (FDD), a transmission mode that can
significantly impact device cost. There are, however, some drawbacks. With half-duplex FDD, the
device will not detect scheduling information for DL and UL in the same set of symbols. The device
cannot monitor DL messages while configured in UL mode and will not be able to send uplink control
information while monitoring DL. In case of conflict, the device can decide what to do based on its
implementation, but it will not be able to do both transmission and reception simultaneously.

The simpler specs of RedCap allow device makers to remove components, reducing the final device
cost. For a successful IoT product launch, every cent counts. Table 3 summarizes key cost-reduction
simplifications in the initial RedCap devices and the potential benefits and trade-offs.

Table 3. Benefits and trade-offs of RedCap cost-reduction strategies

What Benefits Trade-off

Reduced number of Tx and Rx Strong cost Coverage and maximum


with support for maximum DL reduction data rates
2x2 and UL SISO only

Reduced bandwidth of Strong cost Coverage and maximum


20 MHz (FR1) 1
reduction data rates

t1 Half-duplex FDD instead of Moderate Increased scheduling complexity


t2 full-duplex FDD cost as RedCap half duplex device
t1 ≠ t2 reduction will not monitor DL messages
while communicating in UL

1. 100 MHz in FR2, although the first deployment will more likely be in FR1

7
Reduced complexity and power consumption

So far, we have examined RedCap and how it can reduce device costs by relaxing some NR-related specs. The next
step is how to reduce device complexity, which can enable size reductions to fit the RF components in the final
form factor of devices such as smart glasses. Release 17 requirements for RedCap devices include enhancements
such as the use of single connectivity and only selected power classes.

Finally, Release 17 also relaxes some requirements in a few areas to reduce power consumption. Since RedCap
devices are typically either static or moving slowly, reducing network monitoring activities can produce
significant power savings without impacting the device value for some use cases.

Table 4 summarizes the key simplifications implemented in the initial RedCap devices and their potential
benefits and trade-offs.

Table 4. Benefits and trade-offs of RedCap simplifications

What Benefit Trade-offs

Single carrier, with Simplified baseband Reduced maximum


PC + SC ... no support for carrier development throughput
aggregation scenarios

Single connectivity, NR Reduced RF module Requires 5G standalone


standalone only size and cost coverage and cannot
connect to 5G networks
using LTE as an anchor;
also, no support for
fallback to other RATs,
which reduces coverage

Power Class 3 Optimized power Coverage


consumption
reduces built-in
battery size

8
What Benefits Trade-off

Reduced network Power savings Latency, if PDCCH


monitoring (PDCCH) blocking probability
with fewer blind increases due to fewer
decodes (BD) and BDs; can also impact UE
control channel scheduling flexibility
element limits

Longer extended Power savings Mobility performance


discontinuous decrease
reception (eDRX) cycle
Data transfer

Data transfer

Data transfer

eDRX cycle

during RRC disconnect


eDRX cycle
or idle state, device
will not monitor
PDCCH

Radio resource Power savings None for the stationary


management (RRM) device use case, but
relaxation for stations may not be applicable
devices that are not for devices in motion
at cell edge (detected beyond a certain speed
by RRM relaxation as handover and radio
triggers criteria) link failures may increase

Small data Power savings


transmission: R17
allows the UE to
transmit data while in
RRC inactive state

9
Key RedCap Parameters in R17
For the network, the primary impact from the introduction of RedCap devices is the need to adapt to
their specific features during the random-access channel (RACH) process and when the device stays
connected. New information elements (IEs) handle those processes, as summarized in Table 5.

Table 5. Selection of R17 information elements relevant to RedCap device operation

Parameter Included in How it is used

cellBarredRedCap-r17 SIB1 “Barred” indicates the RedCap UE cannot camp


in the cell and needs to start the radio resource
control (RRC) procedure to camp in another cell
“NotBarred” indicates the RedCap UE can proceed
with the RRC procedure in that cell

intraFreqReselection SIB1 This parameter is necessary for RedCap UE support;


RedCap-r17 if not present, the cell will be barred

halfDuplexRedCapAllowed SIB1 If not present, then the UE shall consider the cell
barred and consider re-selection to other cells on
the same frequency

initialDownlinkBWP-RedCap in SIB1 When present, it indicates the initial DL BWP the UE


DownlinkConfigCommonSIB will use during RACH procedure

initialUplinkBWP-RedCap in SIB1 When present, it indicates the initial UL BWP the UE


UplinkConfigCommonSIB will use during RACH procedure

redCapAccessAllowed-r17 SIB4 Indicates if RedCap UE may access the frequency;


prevents RedCap UEs from measuring neighbor cells
not supporting RedCap

Logical Channel Identifier (LCID) Msg3 / Specific values for RedCap devices; used to identify
MsgA the device as “RedCap” during Msg3

relaxedMeasurement-r17 SIB4 Adds “stationary” and “cell edge while stationary”


concepts; when present, the RedCap device can
apply some relaxations described in 3GPP 38.133

intra-SlotFH-r17 SIB1 A RedCap UE will apply different intra-slot PUCCH


frequency hopping when this parameter is enabled

10
The first IEs listed in Table 5 pertain to the permission for a RedCap UE to camp in a cell or do so
using half-duplex mode. The next IEs pertain to BWP, which allows flexible spectrum use to achieve
power savings by dynamically adapting the assigned bandwidth depending on what the UE is doing.
However, BWP offers limited value for RedCap devices because of the reduced maximum bandwidth
(20 MHz).

Video
Traffic
streaming
Chat Chat

Cell BWP2 100 MHz


BWP1 20 MHz BWP1 20 MHz
configuration 4x4 MIMO
2x2 MIMO 2x2 MIMO
maxNumLayers = 2 maxNumLayers = 4 maxNumLayers = 2
RI reported = 2 RI reported = 4 RI reported = 2
BWP switch BWP switch

Figure 3. Example of use of different BWP in 5G NR devices

Bandwidth and power requirements

As discussed, RedCap UEs have a lower maximum bandwidth than other NR devices. This reduced
bandwidth has implications for the RACH procedure. The network can allow the UE to use a specific
initial BWP for RedCap devices or reduce the BWP size requirement to enable the RedCap UE to
complete the attach process. The use of RedCap BWP during initial access (Msg1) indicates that
the device is a RedCap device. The identification can also occur later in Msg3 if the device uses a
RedCap logical channel identifier.

SS block

SIB1 - RACH resources


InitialDownlinkBWP-RedCap-r17 UE decodes SIB1 and then
InitialUplinkBWP-RedCap-r17
sends Msg1 RACH on using
Msg1 (PRACH) InitialUplinkBWP-RedCap-r17
Use of RedCap BWP gives early indication

Msg2 (RAR message)

Msg3 (RRC connection request)


RedCap early indication via LCID
Msg4 (RRC connection setup)

RRC connection setup complete

Figure 4. Indication of RedCap UE during RACH procedure

11
Another power-saving enhancement Release 17 implements for RedCap is the use of system frame
number (SFN). This technique, which was available in LTE, allows an extension of disconnected
receiver time (eDRX) to a maximum of 10.24 seconds, reducing power consumption in devices with
long idle periods during operation.

To avoid handover errors, the use of maximum eDRX time may be restricted to stationary scenarios
or situations when the device is not at the cell edge.

Inactivity status timer


Start Expires
Internet browsing

Traffic (YouTube) DL IP traffic (YouTube)

DRX
inactivity DRX
Power
timer DRX
consumed
cycle

CONNECTED IDLE CONNECTED

Time
RRC release Paging
Autonomous scheduler
Service request
Inactivity status timer
Auto-paging

Figure 5. Example of a device using DRX before moving to idle and later reconnecting

RedCap Signaling Test with UXM 5G


Keysight was the first to market with support for testing 100 MHz-wide cells for pre-5G, known
as 5GTF. Since then, Keysight has supported the wireless industry in achieving other 5G NR
milestones in Releases 15 and 16, from initial calls in different deployment modes and frequency
ranges to achieving maximum data rates with record carrier aggregation configurations and total
used bandwidth.

12
Figure 6. The Keysight UXM 5G is the leading wireless
test platform for 5G. It supports additional radio access
technologies, including LTE, C-V2X, 3G, and wireless
local area networking.

Keysight offers support for Release 17 enhancements to 5G NR, including RedCap, with Keysight
network emulation solutions. The comprehensive portfolio of solutions covers non-signaling and
signaling testing in different domains, including protocol, radio frequency, functional verification,
and performance testing in real conditions.

As discussed previously, Release 17 implements some changes to signaling parameters and


procedures to ensure network support of RedCap devices. Device makers will need to ensure
compatibility before they roll out commercial products. The Keysight S8701A Protocol R&D Toolset
supports Release 17 ASN.1 and updated L1 to L3 procedures, which include specific testing of
RedCap parameters to ensure that connectivity can be achieved and maintained.

Figure 6. A Keysight S8701A Protocol R&D Toolset test script for correct Msg3 RedCap UE early indication

13
In addition to supporting the latest R17 signaling procedures, the Protocol R&D Toolset
offers reporting tools to analyze test results and help debug 5G NR devices, including those that
support RedCap.

Figure 7. Log obtained with S8701A Protocol R&D Toolset during a RedCap test. Boxes show RedCap parameters.

For More Information

Find more insights on how to accelerate 5G innovation across the device workflow at
the following links:

• Keysight 5G Network Emulation Solutions

• S8701A Protocol R&D Toolset

• S8702A RF Automation Toolset

• S8703A Functional KPI Toolset

• S8705A RF/RRM DVT & Conformance Toolset

• S8711A UXM 5G test application

• S8714A UXM 5G RF application

14
RedCap Will Boost IoT
3GPP has supported IoT devices since Release 13 using LTE or LTE-based technologies and has
added enhancements in the later releases. Release 17 introduces support for IoT devices with 5G NR
through a proposal that satisfies cost and power consumption requirements and adds more capacity
than its LTE-based peers. This proposal makes RedCap a good choice for devices with capacity
needs than cannot be satisfied with any of the previous IoT-specific technologies like NB-IoT and
LTE Cat-M.

With RedCap, the network adapts to support devices needed for Industrial IoT, wearables, and
security and surveillance applications.

The ability to support diverse device types on a single network brings additional benefits to network
operators and service providers that can contribute to the success of new IoT-based businesses.
While initial device launches may include support for LTE-based and 5G NR RedCap technologies,
the rapid growth of 5G deployments and subscribers worldwide should hasten the transition to
devices that use RedCap exclusively.

Keysight enables innovators to push the boundaries of engineering by quickly solving


design, emulation, and test challenges to create the best product experiences. Start your
innovation journey at www.keysight.com.

This information is subject to change without notice. © Keysight Technologies, 2018 - 2022,
Published in USA, November 14, 2022, 7122-1119.EN

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy