RedCap_wp_en_3683-9757-52_v0100

REDUCED CAPABILITIES (REDCAP) –
A NEW CLASS OF 5G DEVICES
White Paper | Version 01.00 | Reiner Stuhlfauth and Lothar Walther

CONTENTS
1 Technical evolution of IoT and motivation for RedCap................................................................................5
1.1 Cellular IoT – new services with new requirements.......................................................................................5
1.2 RedCap supporting the evolution of user equipment......................................................................................6
1.3 Positioning RedCap in the data throughput constellation..............................................................................8
1.4 Introduction of the next generation eNB (ng-eNB).........................................................................................9
1.5 Power saving aspects related to RedCap......................................................................................................11
2 Reduced capabilities overview (Rel. 17).....................................................................................................12

2.1 Reduced capabilities outlook (Rel. 18)..........................................................................................................15
3 RedCap-related bandwidth part aspects.....................................................................................................17
4 RedCap information signaling and network access restrictions...............................................................19

4.1 RedCap-related UE identification..................................................................................................................19
4.2 RedCap-specific cell barring signaling in SIB1.............................................................................................20
4.3 RedCap feature priority signaling – early RedCap identification..................................................................24
4.4 Inter-frequency cell reselection info via SIB4................................................................................................26
5 RRM measurement relaxation.....................................................................................................................27
6 Power saving features and technologies....................................................................................................29

6.1 Power saving overview..................................................................................................................................29
6.2 Power saving aspects in wireless communications up to Rel. 15.................................................................30
6.2.1 Discontinuous reception (DRX)......................................................................................................................30
6.2.2 Extended discontinuous reception (eDRX)....................................................................................................31
6.2.3 Power save mode (PSM)................................................................................................................................32
6.2.4 Wake-up signal (WUS)..................................................................................................................................32
6.3 Power saving in 5G Rel. 16............................................................................................................................33
6.3.1 UE preference for power saving parameters.................................................................................................34
6.3.2 SCell dormancy-like behavior........................................................................................................................35
6.3.3 Maximum number of DL MIMO layers..........................................................................................................36
6.3.4 Relaxed RRM measurements........................................................................................................................37
6.3.5 Cross-slot scheduling with minimum scheduling delay................................................................................37
6.3.6 Wake-up signal in 5G Rel. 16........................................................................................................................38
6.4 Power saving enhancements in 5G Rel. 17...................................................................................................38
6.5 Power saving enhancements in 5G Rel. 18...................................................................................................41
7 Coverage enhancements..............................................................................................................................44
8 RedCap-related T&M aspects .....................................................................................................................46

8.1 R&S®CMX500 one-box tester (OBT) supporting RedCap..............................................................................46
8.2 UE RedCap related RX and TX tests..............................................................................................................47
8.3 RedCap-related protocol testing....................................................................................................................48
8.4 Power saving measurement aspects.............................................................................................................53
8.5 Conformance, regulatory and LBS test solutions..........................................................................................55
8.6 Mobile network testing verifying RedCap KPIs in the network....................................................................58
9 Summary.......................................................................................................................................................60
The Bluetooth® word mark and logos are registered trademarks owned by Bluetooth SIG, Inc. and any use of such marks by Rohde & Schwarz is under license.
Wi-Fi® is a registered trademark of Wi-Fi Alliance®.
2
10 References....................................................................................................................................................61
11 3GPP specifications.....................................................................................................................................63
12 Abbreviations................................................................................................................................................65
INTRODUCTION
With the introduction of 5G, the 3GPP standardization organization is seeking to increase
the number of use cases for wireless communications. The result is the well-known tri-
angle of services with the three facets eMBB, uRLLC and mMTC. The reduced capability
(RedCap) work item in 3GPP Release 17 targets massive machine type communications
(mMTC). This encompasses the service continuation of legacy technologies like NB-IoT
as well as support for both enhanced and new machine type services. Initially, 3GPP
described a new study item formally known as NR light, which was then renamed 5G
RedCap. It is intended as the first 5G standard for the vast and growing internet of things
(IoT) landscape. RedCap should meet the requirements of IoT devices for smaller, less
complex and lower cost RF solutions with better battery life than existing 5G products.
Basically, RedCap targets IoT services needing a higher data rate than mMTC services
but lower data rates than 5G eMBB, while simultaneously reducing UE complexity and
improving power saving aspects. This also enables smaller form factors in IoT devices,
which is highly desirable in many use cases (e.g. wearables). In addition, RedCap tech-
nology is fully integrated into the overall 5G system and thus provides a future-proof
continuation within the IoT technology evolution [TS 38.300].
This document presents the main aspects of the 5G system's RedCap technology exten-
sion in terms of the user equipment as well as the network. Even if the different aspects
of RedCap and the power saving and coverage enhancements correspond to individual
technology features described in the 3GPP specifications, we believe these three tech-
nologies are strongly correlated and will coexist in a joint deployment. Accordingly, this
white paper not only presents the RedCap technology, but also contains a section on
power saving and coverage extension.
Section 1 provides a concise overview of RedCap and related technology aspects such as
the network architecture, power savings and the UE evolution. This section begins by dis-
cussing IoT technologies in order to position RedCap within that context. This is followed
by a summary of the main characteristics.
Section 2 describes in more depth the major technology aspects of RedCap, especially
the capabilities that are reduced in the UE along with the corresponding impact on UE
design and operation within a 5G network.
Sections 3 and 4 delve into important aspects related to how RedCap not only repre-
sents a reduction of the UE capabilities but also impacts the network behavior. Due to the
reduced capabilities of the UE, it behaves slightly different from the network's perspective
compared to a 5G NR UE. Thus, several signaling procedures need to be updated. This
includes aspects related to bandwidth (BW) part coordination since the reduced band-
width capability in the UE requires a reaction or adaptation from the network. In addition,
the network is able to signal UE capability specific cell access restrictions. Furthermore,
the UE must identify itself as a RedCap UE during the random access procedure so that
the network can handle the UE properly.
Rohde & Schwarz White Paper | Reduced capabilities (RedCap) – a new class of 5 evices 3
Gd
Section 5 covers aspects related to RRM measurement relaxation that can potentially
impact UE energy consumption. The topic of UE energy consumption or power sav-
ing is discussed in depth in Section 6. The discussion begins with a general overview of
power saving methodologies and then follows their evolution across 3GPP releases up to
Release 18. Section 7 presents some study item discussions related to extension of the
coverage, especially in the uplink direction.
Rohde & Schwarz has already released some RedCap test capabilities for its R&S®CMX500
mobile radio tester. Accordingly, Section 8 describes general test and measurement
aspects related to RedCap. This includes measurements on the RF layer like TX and RX
measurements as well as signaling test scenarios and relevant aspects of protocol test-
ing. To align with the technology section, Section 8 also briefly covers power saving test
scenarios. The T&M section concludes with additional information on RedCap testing,
especially in relation to conformance or certification testing. Finally, RedCap not only
affects the UE implementation, but also impacts the network, especially with the network
restriction signaling. Accordingly, Section 8 also briefly discusses mobile network testing
and the impact on existing methodologies due to RedCap.
The white paper concludes with a summary of why we believe RedCap will continue to
play a pivotal role within the overall 5G system.
4
1 TECHNICAL EVOLUTION OF IOT AND MOTIVATION
FOR REDCAP
As part of the evolution of wireless connectivity over the last decades, the transition
from a completely voice-centric network to a unified data network is apparent in the
system architecture. From the perspective of use cases and the device evolution, the
topic of machine type communications is becoming increasingly relevant. Today, there
are many wireless technologies claiming to support machine type communications or
more generally, the internet of things (IoT). This white paper will not attempt to cover
all the different technological aspects of IoT. Instead, its goal is to outline a classifica-
tion scheme and motivation for the role the new RedCap technology will play in this
ecosystem. For example, we can divide IoT technologies into cellular IoT technologies
or non-cellular technologies. Prominent examples of non-cellular IoT are standards like
Bluetooth®, Wi-Fi®, IEEE UWB®, Thread® or LoRaWAN®, including standards supported
by the Connectivity Standard Alliance (CSA) [Ref. 9], also known as Matter. For the sake
of brevity, we will not describe those technologies, but further information can be found
in [Ref. 4], [Ref. 10] and [Ref. 22]. In the cellular world, 3GPP serves as a standards devel-
opment organization (SDO). It has defined multiple technologies leveraging machine type
communications like GPRS, EC-GSM on 2G, NB-IoT or LTE-M on a 4G basis. Now with
5G RedCap, IoT is entering the 5G world. Multiple factors drive the need for RedCap,
including the desire to reduce device complexity, the need to reduce energy consump-
tion and the need for higher throughput machine type communications in both directions
(UL and DL). However, another aim is full integration of IoT into the 5G system in order
to benefit from overall system technologies like the service based architecture (SBA),
network slicing or the flexible air interface. Therefore, the motivation for RedCap can be
divided among several different technological aspects.
1.1 Cellular IoT – new services with new requirements

This section outlines the evolution of the internet of things (IoT) in general as well as the
related additional requirements with a focus on cellular IoT technologies [Ref. 8]. The ini-
tial services introduced IoT as a technology that allows machines to talk to one other in
a simple manner with low data rates and relaxed QoS requirements, driven by the notion
of a sensor type UE oriented network. Later deployments of IoT considered further and
more sophisticated classifications. A good definition of IoT can be found in the Ericsson
mobility report [Ref. 11]:
► Massive IoT primarily consists of wide-area use cases, connecting large numbers of low-
complexity, low-cost devices that have long battery life and relatively low throughput.
NB-IoT and Cat-M technologies complement one other. Globally, 124 service providers
have deployed or commercially launched NB-IoT networks and 57 have launched
Cat-M, while 56 have deployed both technologies according to a GSA report from
September 2022 [Ref. 28]. NB-IoT and Cat-M follow a smooth evolution path into 5G
networks, and can continue to be deployed in the same bands as today, even when
5G is introduced. Commercial devices for massive IoT include various types of meters,
sensors, trackers and wearables.
► Broadband IoT mainly includes wide-area use cases that require higher throughput,
lower latency and larger data volumes than massive IoT technologies can support. LTE
is already supporting many use cases in this segment. By the end of 2025, 34 % of
cellular IoT connections will be broadband IoT, with 4G connecting the majority. With
the introduction of 5G New Radio (NR) in old and new spectrum, throughput data rates
will increase substantially for this segment.
Gd
► Critical IoT is used for time-critical communications in both wide- and local-area use
cases that require ensured data delivery with specified latency targets. Critical IoT will be
introduced in 5G networks with the advanced time-critical communications capabilities of
5G. Deployment of the first modules supporting critical IoT use cases is ongoing since
about 2021. Typical use cases include cloud based AR/VR, cloud robotics, autonomous
vehicles, advanced cloud gaming, and real-time coordination and control of machines
and processes. The introduction of time sensitive networks (TSN) is supporting IoT
services requiring very low latency or round trip times (RTT) and reliable connectivity.
Prominent technologies are e.g. NB-IoT where the goal is to reduce complexity while sup-
porting low and sporadic data rates with very long battery life. Technological details for
NB-IoT are explained in [Ref. 5]. Based on LTE radio technology but with the aim of reduc-
ing complexity while offering a higher data rate compared to NB-IoT, LTE-M is specified
in 3GPP Rel. 12 and onwards [Ref. 7]. To ensure the longevity of NB-IoT and LTE-M, 3GPP
defined the concept of an updated nodeB, the ng-eNB to integrate both technologies
into the 5G system (see section Introduction of the next generation eNB (ng-eNB)). With
5G RedCap, a new cellular IoT technology has been introduced that is integrated into the
overall 5G system from its inception and can therefore take advantage of 5G technol-
ogy. This should enable a reliable, low-latency and higher data rate service, especially for
handling various facets of QoS requirements all the way through sophisticated QoS man-
agement like the SBA concept of the 5G core network and network slicing. While TSN is
directed towards the uRLLC evolution, the main motivation behind RedCap is to bridge
the gap between the mMTC and eMBB services, i.e. reducing the complexity of the
device while still offering a higher data rate (Figure 1).
Figure 1: IoT classification within 5G
eMBB Broadband IoT
Industrial IoT (IIoT),

Massive IoT critical IoT
mMTC uRLLC
Reduced capability (RedCap) devices,

ng-eNB 5GC formerly known as “NR light”
1.2 RedCap supporting the evolution of user equipment

An obvious trend with respect to user equipment that is also visible in statistics released
by organizations like the Global Supplier Association (GSMA) with their device informa-
tion service [Ref. 12] is the fact that the majority of future wireless communications UEs
will no longer be traditional smartphones. They will lose their number one position to
machine type UEs. Especially industrial modems will play a pivotal role in future 5G net-
works. The introduction of industrial modems or CCTV devices underscores the growing
need for UL-centric networks. Use cases driving the evolution of UEs include industrial
wireless sensors for connected industries, video surveillance in smart cities, and human
wearables. The evolution path of these devices is shown in the following figure.
6
Figure 2: Evolution of user equipment related to RedCap
Rel. 17: industrial sensors, Rel. 18: improved industrial sensors, Smart grid
video surveillance and wearables video surveillance and wearables
When dividing IoT into its various facets, we should consider that one motivation for
RedCap is to enable further evolution of IoT devices [TR 23.724]. Devices like industrial
sensors, video surveillance equipment and wearables are considered as the first RedCap
UE types. These devices are characterized by a non-human interface, a certain minimal
set of QoS flow requirements, and a need for a higher data rate, especially in the uplink
direction. The latency and throughput requirements of use cases earmarked for RedCap
devices cannot be met by legacy cellular IoT technologies and there is no overlap in their
applications [Ref. 12]. Future networks and also 3GPP Releases beyond Rel. 18 will seek
to improve the services offered to such IoT devices. A common buzzword is the “smart
grid”, i.e. a network of smart and agile sensors and machine type devices that commu-
nicate with one other and require data rates ranging from sporadic traffic in bursts all the
way through QoS ensured profiles, but still with low UE complexity. In summary, RedCap
devices can be viewed as mid-tier devices in a lower class than premium devices but
higher than eMTC/NB-IoT devices [Ref. 12]. The initial RedCap specifications target three
UE RedCap types or use cases: wearables, industrial wireless sensors and surveillance
video. They differ with respect to QoS requirements like wireless data rate, latency, avail-
ability, size and battery life (Figure 3) [Ref. 25].
Figure 3: Initial RedCap use cases and UE types
Availability and
Use case Example devices Data rate Latency Battery life Size
reliability
5 Mbps to 50 Mbps DL,
at least a few days
smartwatches, VR headsets, 2 Mbps to 5 Mbps UL
Wearables – – up to one to two compact
health monitors (peak rate up to 150 Mbps DL/
weeks
50 Mbps UL)
motion, pressure, temperature,

Industrial wireless humidity sensors, many new compact –
2 Mbps < 100 ms 99.99 % at least a few years
sensors and existing applications (e.g. large
autonomous wireless forklifts)
2 Mbps to 4 Mbps for

smart cities, factories, basic applications, compact –
Video surveillance < 500 ms 99 % to 99.99 % –
agriculture 7.5 Mbps to 25 Mbps for large
high-end applications
Gd
1.3 Positioning RedCap in the data throughput constellation
The discussion on reduced capabilities within 3GPP considered several motivational
aspects targeting machine type communications requiring higher data rates than legacy
MTC services but lower data rates than eMBB services. It was necessary to take into
account UE complexity, power saving and the longevity and service continuation of leg-
acy technologies [Ref. 13]. Referring to Figure 4, the motivation for RedCap becomes
obvious. 3GPP tackled the communications requirements entailed by the proliferation of
IoT with two major radio technologies: NB-IoT for the lower bound of basic IoT commu-
nications and LTE-M for devices supporting higher MTC data rates. We consider these
two radio technologies as the legacy technologies. The introduction of ng-eNB ensures
the longevity of these technologies by incorporating them into the overall 5G architecture.
On the upper axis, we see the extension of 5G targeting higher data rates. This is due to
the introduction of wider bandwidth (e.g. the most recent extension of frequency range
FR2 to FR2-2 with 2 GHz channel bandwidth), permission for carrier aggregation and dual
connectivity, but also the introduction of higher order modulation schemes like 1024QAM
and higher order MIMO schemes (e.g. 8x8 MIMO). The observer may now detect a kind
of “data rate gap” between these radio technologies, the lower bound existing with its
lower data rates but newer services and the upper bound aiming at much higher data
rates than before. One may now consider the introduction of RedCap as a concept to
bridge the gap between these two ends. RedCap should offer higher data rates than
LTE-M and NB-IoT to enable new IoT services, but much lower data rates than eMBB in
order to minimize the impact on UE complexity and power saving.
Another aspect related to data throughput is the direction of data transmission. For
example, especially with the introduction of extended MTC in non-public networks (NPN)
within industrial environments, the data rate requirements change from the downlink
to the uplink (or at least become symmetrical). While a typical smartphone with human
driven applications like video streaming requires data predominantly in the DL direction,
new UE types like industrial sensors or CCTV cameras require data mainly in the UL
direction. Thus, operators may potentially need to reconsider their current TDD UL/
DL configuration, which is historically more DL centric. The dynamic nature of the 5G
TDD UL/DL configuration allows network operators to configure a non-public network
(e.g. inside a factory) with symmetric UL/DL resources, whereas outside the factory DL
resources dominate. Higher frequencies do not easily penetrate the factory’s walls, which
helps in this scenario to minimize interference between the two network configurations.
Figure 4: 5G RedCap positioning in the data rate constellation – motivational aspects
Throughput
Highest throughput
eMBB
uRLLC Critical applications
5G RedCap Smart IoT
Low complexity and

high efficiency IoT
8
1.4 Introduction of the next generation eNB (ng-eNB)
The specification TS 38.300 defines the ng-eNB as a node providing EUTRA user plane
and control plane protocol terminations towards the UE, and connected via the NG inter-
face to the 5GC. The main objective is the service continuation of LTE, LTE-M and NB-IoT
in the 5G system. As a secondary motivation, network operators may migrate more
quickly to standalone 5G deployments since the ng-eNB makes the mandated need for
EPC obsolete.
In Rel. 10 with narrowband IoT (NB-IoT), 3GPP introduced a radio technology target-
ing very low UE complexity, very long battery life and low data rate plus best effort QoS
sporadic data transmissions [Ref. 5]. Defined in Rel. 13, NB-IoT is based on EUTRA radio
technology and uses the eNB for LTE radio access as well as the LTE core network EPC
[TS 36.300]. Service times for such end-user devices and networks are envisaged to
exceed 10 years and range up to even 20 years lifetime. In 3GPP Rel. 13, the extension of
LTE with the LTE-M technology envisages machine type communications using EUTRA
radio technology as a basis [Ref. 7]. With respect to the infrastructure of the core net-
work and backhaul connection, 5G introduces a new core network (5GC) using service
based architecture (SBA) functions. This enhanced core network concept is characterized
by strict disaggregation into the control and user plane and definition of an SBA archi-
tecture. In simplified terms, the core network entities can be described as cloud native or
virtual network functions (NFV) where each function offers services to other functions.
Every network function can call a service of another network function. Therefore, the logi-
cal network structure is more like a bus – as opposed to having defined reference points
and fixed interfaces between network functions. These functions are stateless and can be
scaled easily. Moreover, isolated operation is possible in case of failure to ensure uninter-
rupted service. As part of the 5G evolution, several mitigation and deployment paths have
been described, e.g. option 3 as EN-DC non-standalone (NSA) or option 2 as standalone
(SA) [Ref. 6]. Because some of these architecture options (options 4, 5 and 7) require
connection of the EUTRA radio network to the 5GC, an enhancement of the existing LTE
eNB is introduced as ng-eNB. ng-eNB enables connection of the eNB with the gNB via
the Xn interface and/or with the 5GC via the NG interface. To support disaggregation into
control and user planes, the interfaces are designated as Xn-C, Xn-U, NG-C and NG-U.
This enhancement of the eNB into ng-eNB supports features like network slicing, carrier
aggregation or multicarrier connection. Several facets of architecture deployments are
possible; see TS 37.340 and [Ref. 6] for details.
Gd
Figure 5: Next generation eNodeB
5G core AMF
Supported RATs
EUTRA
LTE-M
NB-IoT
ng-eNB
UPF
NG interface
EUTRA
AMF/UPF AMF/UPF
LTE-M
5GC NB-IoT
ng-eNB
NG NG NG Xn interface
NG NG NG NG
Xn NG-RAN
gNB gNB 5G NR
Xn Xn
Xn
ng-eNB ng-eNB
gNB
To support NB-IoT and LTE-M service coordination via the 5G core network and to ensure
the longevity of NB-IoT/LTE-M as well as the service continuation, the ng-eNB provides a
connection between EUTRAN and the 5G core network. In other words, this introduces
the existing LTE radio with the ng-eNB entities as a new RAN architecture element in the
entire 5G architecture. Requiring the 5G core network to coordinate NB-IoT/LTE-M ser-
vices ensures their service continuity. Basically, we can now consider NB-IoT and LTE-M
as additional RANs in the entire 5G system. This enables a smooth migration path and
preserves investments made into those RATs [TR 23.724]. A RAN that is made out of ng-
eNBs and gNBs (SA) both individually connected via NG to 5G is also called an NG-RAN.
In addition, the ng-eNB supports sophisticated services defined in Rel. 17, e.g. it
maintains the security and radio configuration for user and control plane CIoT 5GS
optimizations. To optimize cellular IoT or MTC services, TS 23.501 introduces several
enhancements to allow efficient provisioning of IoT services with respect to UE com-
plexity, service characteristics of the IoT, and energy consumption. Such CIoT support
features are (see TS 23.501 for further details):
► Signaling of UE 5G preferred network behavior indicating the network behavior the UE
can support and what it would prefer to use
► Signaling enabling better coordination of selection, steering and redirection between
EPS and 5GS
► Control plane CIoT 5GS optimization to exchange user data between the UE and SMF
as the payload of a NAS message in both the uplink and downlink directions, avoiding
establishment of a user plane connection for the PDU session in order to efficiently
transmit small data packets
► Non-IP data delivery to the AF and reliable data transfer
► Power saving enhancements allowing the network to configure optimized power
saving features, especially when the UE operates in mobile initiated connection only
(MICO) mode
► High latency support, requesting longer buffering within the network
► Inter-RAT mobility signaling support
10
► User plane CIoT 5GS optimization enabling transfer of user plane data from idle mode
without using the service request procedure to establish an access stratum (AS)
context in NG-RAN and UE
The ng-eNB supports such CIoT optimizations on the radio interface Uu and on the NG
interface [TS 38.410].
1.5 Power saving aspects related to RedCap

We should first mention that the technology facets related to power saving that were
introduced by 3GPP (Rel. 16/Rel. 17) were defined independently of any RedCap consid-
erations. However, it is obvious that they are closely related. Thus, it does not make sense
to deploy RedCap functionalities without taking power saving into consideration. A con-
cise description of the various aspects of power saving is given in the section on Power
saving features and technologies; see also [Ref. 2]. In relation to RedCap in the context of
power saving technologies, see the power saving cluster depicted in Figure 6.
Figure 6: Power saving technology cluster
Hardware restrictions and reduced capabilities

► Lower power class
► Single antenna
► Half-duplex operation
► Bandwidth restrictions
► Etc.
Enhanced mechanisms and innovations Operational enhancements

► Wake-up signals ► Discontinuous reception (DRX)
► Relaxed measurements ► Sleep mode
► Adaptive bandwidth ► Power save mode (PSM)
► Etc. ► Signaling reduction, i.e. TAU
► Cross-slot scheduling
► Etc.
On a high level, the different aspects of power saving can be divided into three main
facets:
► Hardware restrictions and reduced UE capabilities, e.g. lower power class UEs,
bandwidth and number of antenna restrictions as well as half-duplex operation to
reduce hardware requirements, e.g. duplexer to separate UE TX and RX
► Operational enhancements like the well-known DRX cycles or sleep mode (PSM) as
well as innovative ideas like cross-slot scheduling with ensured minimum scheduling
delay or signaling reduction
► Enhanced mechanisms like permission for relaxed measurements, adaptive bandwidth
and wake-up signals, to name a few examples
RedCap clearly enables the relevant capability reduction seen in the power saving classi-
fication since its methods fulfill both of the desired objectives, i.e. reduced UE complexity
and decreased energy consumption.
Rohde & Schwarz White Paper | Reduced capabilities (RedCap) – a new class of 5
G devices 11
2 REDUCED CAPABILITIES OVERVIEW (REL. 17)
In terms of lower UE complexity, 3GPP discussed certain technology aspects in the study
item [Ref. 14] leading to the RedCap definition. This section will present the major tech-
nology aspects, especially the capability restrictions that were agreed upon in the aim of
complexity reduction. As an initial question, we might ask how to distinguish between
a RedCap UE and a standard UE supporting 5G. Moreover, can the network indicate
RedCap support or is there the option of a RedCap-only 5G network? To answer these
questions, we might ask how to recognize that a UE supports RedCap. During connec-
tion setup, the UE reports its capability information to the network. Here, a UE uses the IE
RedCapParameters to indicate its support for RedCap.
Within 3GPP RAN1, some RedCap-specific restrictions were agreed upon. They are listed
in the specification TS 38.306, namely: bandwidth limitation, number of DRB, PDCP and
RLC SN length, number of RX antennas and non-support for multicarrier and mobility
features:
Bandwidth reduction: A device claiming to be a RedCap UE in FR1 supports a maximum

channel bandwidth of 20 MHz in FR1 and 100 MHz in FR2 [TS 38.300]. Support for these
bandwidth restrictions is aligned with the general indication of reduced capabilities with
the RRC IE supportOfRedCap-r17.
Number of UE RX antennas: A RedCap UE can support either one or two RX antennas

depending on the frequency range. In FR1, the UE can support either one or two RX
antennas. In FR2, the UE needs to support two RX antennas. There is also a relationship
between the number of supported RX antennas and the number of supported DL MIMO
layers. A UE supporting two RX antennas in FR1 must support two MIMO layers, but a
UE supporting two RX antennas in FR2 either supports one or two MIMO layers.
Number of UE TX antennas: To shrink the complexity, 3GPP decided that a RedCap UE only
needs to support a single TX antenna. Thus, no UL diversity or UL MIMO is supported (in
Rel. 17/Rel. 18). Since antennas represent an important factor with respect to the over-
all UE size, reduction of the number of antennas reduces the device complexity and the
form factor, enabling manufacturers to design highly compact UEs like wearables and
IIoT devices.
Optional support for higher order modulation schemes: The maximum modulation scheme in
5G NR is 256QAM in Rel. 15. In Rel. 17, 1024QAM was added e.g. for eMBB high data
rate UEs. Support for 256QAM is mandatory for a regular 5G NR UE for DL data (PDSCH).
RedCap UEs only have to support 64QAM as the highest order modulation scheme.
All other modulation schemes are optional for any channel/direction for RedCap UEs.
Therefore, a new UE capability IE had to be introduced to indicate the optional support for
256QAM for the PDSCH in FR1: the IE pdsch-256QAM-FR1.
Half-duplex operation: To reduce the RX and TX complexity, especially the need for a duplex
filter in FDD to separate the TX and RX from one other, the RedCap UE is allowed to
operate in half-duplex mode. This entails no simultaneous transmission and reception.
Note that full-duplex operation is optional for a RedCap UE. Thus, it is not excluded. The
drawback of half-duplex operation is the potential risk of a collision, i.e. the UE receives
scheduling information for simultaneous RX and TX. In such cases, there is a need to
define priority rules for simultaneous TX and RX situations. TS 38.213 defines such poli-
cies. If the UE is configured to receive downlink channels or signals like PDCCH, PDSCH,
CSI-RS or PRS and detects scheduling of resources for TX, it would skip reception. If
the UE is configured to transmit SRS, PUSCH or PUCCH and receives the scheduling of
downlink resources, it would skip transmission after a timer expiry (Tproc, 2). TS 38.213 also
12
clarifies the conflict between transmission and reception of system information (SSB)
such that the TX is skipped after a wait time because SSB seems to have a higher priority.
Figure 7: Half-duplex operation and conflict solving rules
Reduced capability supports half-duplex UE (HD-UE), not capable of simultaneous transmission and reception on a serving cell
with paired spectrum (FDD); TS 38.213 defines some rules.
Half-duplex operation FDD UL TX TX TX

(UE perspective)
FDD DL
FDD UL TX TX TX RX RX RX
FDD DL RX RX E.g. conflict solve: UE is configured with set of symbols for PDSCH
and receives TX scheduling of PUSCH/PUCCH ⇒ UE will skip RX.
FDD UL TX TX TX TX
Note: duplex TX and RX not excluded
FDD DL
FDD UL TX TX TX RX RX RX RX
FDD DL RX RX RX
E.g. conflict solve: UE is configured with set of symbols for PUSCH TX
and receives scheduling of PDSCH/PDCCH ⇒ UE will skip RX,
based on timer configuration.
Reduced capabilities for mobility scenarios and multicarrier operations (CA, MR-DC, DAPS and CPC):
Motivated by the objective to reduce the overall UE complexity, several features related to
multicarrier operation and enhanced mobility are not supported. These features are car-
rier aggregation (CA) for wider bandwidth, multi-radio dual connectivity (MR-DC) for dual
radio connections like NR+EUTRA (EN-DC or NE-DC) or NR+NR (NR‑DC), dual active
protocol stack (DAPS) for seamless handover mobility and conditional PSCell change
(CPC). As an important consequence of this feature reduction, we should be aware that
a RedCap UE will only be able to operate in a 5G standalone (SA) network. A non-stand-
alone (NSA) network requires simultaneous EUTRA and NR connections, thus conflicting
with the MR-DC preclusion. From a device complexity perspective, this reduces the RF
complexity, device size and power consumption. Since CA is not required, complex filters
can be omitted in the UE design, reducing the complexity and insertion loss and leading
to lower energy consumption.
Early RedCap UE identification by the network: This refers to a technical feature involving early
indication of RedCap support by the UE during either the random access procedure
(Msg1) or in the first RRC connection setup message (Msg3). This reduces the signaling
overhead during connection setup and possibly the call setup time. A later section will
explore this topic further.
UE capability specific network access restrictions: With the introduction of RedCap, 3GPP intro-
duces the concept of access restrictions signaled via system information that are valid
for certain UE capabilities. For example, the network may restrict access for UEs support-
ing one or two RX antennas only or UEs operating in half-duplex mode. This restriction is
valid on a cell level. Later sections will provide further details.
RRM measurement relaxation: One feature that is not directly related to RedCap is network
indicated relaxation of RRM measurements [TS 38.133]. For example, a stationary UE like
an FWA CPE can be permitted by the network to relax the amount of neighbor cell RSRP
measurements supporting mobility procedures. This is because it is unlikely that such a
UE will trigger a handover procedure. Such procedures consider the UE mobility status
(i.e. stationary UE criterion or UE with low velocity) or the UE's presence in the cell center
or at the cell edge (not-at-cell-edge criterion). See later sections for further details.
G devices 13
Bandwidth part (BWP) operation: To avoid a possible conflict between the network indicated
initial or common BWP and the UE reduced bandwidth, it is possible with RedCap to sig-
nal a UE-specific or RedCap-specific BWP. See later sections for further details.
Reduced number of data bearers (DRB): A RedCap UE must support a maximum number of
eight DRBs since this aligns with the achievable throughput and reduces the protocol
implementation complexity. Support for 16 DRBs is optional and will be signaled with the
IE supportOf16DRB-RedCap-r17.
Shorter RLC sequence number: The RLC layer supports with its acknowledged mode (AM) a
reliable link for retransmission of data packets. This retransmission is based on signal-
ing of a sequence number, i.e. the RLC AM SN indicating the status of properly received
packets. To reduce the UE memory affected by the storage of pending or not yet con-
firmed packets, RedCap reduces the length of this sequence number to 12 bit. The 18 bit
sequence number is optional and will be signaled with the IE am-WithLongSN-RedCap-r17.
Shorter PDCP sequence number: The PDCP layer supports mobility procedures like dual
connectivity or handover scenarios and ensures reliable data transfer by applying a
sequence number based acknowledgement mechanism. The maximum length of the
PDCP sequence number for a RedCap UE is 12 bit. The 18 bit length is optional and will
be signaled with the IE longSN-RedCap-r17.
Transmit power: In general, RedCap UEs are of the same power class 3 as defined for NR in
TS 38.101-1, but a few extensions are defined for FR2. TS 38.101-2 defines a new power
class 7 valid for FR2 UEs if they are RedCap UEs. This has the same maximum TRP of
23 dBm, but there are some relaxations with respect to the spherical coverage percentile
(see [Ref. 16] for further details).
PUCCH frequency hopping: In case a separate UL BWP for RedCap UEs is configured by the
network, the parameter intra-SlotFH-r17 controls the intra-slot frequency hopping of the
PUCCH. If this parameter is absent from the PUCCH-ConfigCommon message, intra-slot
hopping is enabled. If this IE is included, PUCCH frequency hopping is disabled. Instead,
the PUCCH will then use a single PRB resource at either side of the UL BWP. The value
of the intra-SlotFH-r17 parameter indicates whether the PRB counting starts in increasing
order from the lower edge or in decreasing order from the upper edge [TS 38.331]. An
optional PRB offset for the common PUCCH resource can be signaled with the parameter
additionalPRBOffset.
The PUCCH resources to be used by RedCap UEs until they will be provided with dedi-
cated resources are defined by pucch-ResourceCommonRedCap, a cell-specific parameter.
Fewer frequency bands: This is not directly mandated by 3GPP, but it is assumed that RedCap
devices will support fewer bands in order to reduce the overall complexity. Most likely,
RedCap UEs will support a regional subset of bands plus a few bands to enable interna-
tional roaming if the UE type allows a non-stationary installation. Simpler IoT devices may
need just a few bands, especially if they are designed for use in a single location [Ref. 25].
14
2.1 Reduced capabilities outlook (Rel. 18)
In December 2021, 3GPP kicked off discussion for the next release including study items
[Ref. 17] as well as work item proposals for the Rel. 18 specifications [Ref. 18]. The name
for the RedCap-specific work item in Rel. 18 is extended RedCap (eRedCap). It includes
the following aspects:
Bandwidth reduction to 5 MHz: 3GPP discusses a new UE type supporting a maximum band-
width of 5 MHz for FR1. Note that this is a similar bandwidth to what e.g. LTE-M devices
support. This enables new data services for less complex UEs with a peak data rate of
around 10 Mbps. However, unlike LTE-M, the 5G RedCap connection will benefit from an
entire end-to-end connection based on the 5G architecture. This is especially relevant to
take advantage of 5G features like enhanced QoS management and network slicing. The
goal is to enable UEs in the background of mission-critical communications (MCX) and
FRMCS, for example. The challenge of this bandwith reduction is adapting existing cell
acquisition procedures, i.e. the SSB acquisition needs some adjustments as the PBCH
bandwidth may exceed 5 MHz.
Future railway mobile communications system (FRMCS): To enable communications between

railway system entities, the Union International de Chemins de fer (UIC) began stan-
dardization in 1992 of the GSM based GSM-R railway communications system in the
frequency range from 874.4 MHz to 880 MHz (UL) and from 919.4 MHz to 925 MHz (DL).
Since the industry has announced it will only support GSM-R until 2035 at the latest, the
UIC began work on a successor railway communications system (FRMCS) based on 5G
technology [Ref. 20]. This includes the definition of the new n100 and n101 frequency
bands for also using the 1900 MHz spectrum. With the 5.6 MHz bandwidth for the n100
band, a co-existence between GSM-R and FRMCS is possible and a minimum band-
width of 2.88 MHz is anticipated for 5G NR based waveforms. In a possible coexistence
scenario, the 5.6 MHz spectrum is divided into 14 GSM-R channels and one 2.88 MHz
FRMCS channel. RedCap will extend its capabilities to support such a bandwidth,
enabling RedCap devices for FRMCS.
RedCap for mission critical communications (MCX): Public protection disaster relief (PPDR) is
obviously one of the major human safety related use cases for wireless communications.
There are several proprietary technologies like DMR, TETRA or P.25 enabling direct device
to device communications for first responders. 3GPP considers mission critical commu-
nications (MCX) in its releases, e.g. with the introduction of proximity services in Rel. 12
and future extensions, support by RedCap devices is also taken into account for MCX
[Ref. 19]. One current discussion item is support for a 3 MHz bandwidth UE in the NR
band n28. Another motivation for public safety agencies to integrate NR RedCap-enabled
wearables into their networks is that, because cloud native technologies are central parts
of the 5G core architecture, the network will provide wearable devices with the needed
storage capacity and processing power. Hence, NR RedCap-enabled wearables will be
able to host more sensors, collect more data and be involved in new sets of p ublic safety
applications [Ref. 19].
RedCap sidelink support: Originally, the sidelink or PC5 interface was introduced to sup-
port vehicle-to-everything (V2X) communications. However, as more machine type or
handheld devices seek to benefit from direct device-to-device sidelink communications,
the feature sets of both technology facets (RedCap and NR-V2X) will be combined. This
includes operation of the sidelink on a narrow bandwidth to align with the bandwidth
restrictions of RedCap. It will also incorporate power saving methodologies like DRX,
preferred and preconfigured subbands for high-priority messages and semi-persistent
scheduling. Thus, a RedCap sidelink mode could potentially reduce latency and device
energy consumption.
G devices 15
RedCap enhancements for narrowband positioning: A Rel. 17 RedCap device could use any of the
Rel. 17 positioning technologies. However, they are not optimized for RedCap use cases.
To support additional use cases in RedCap devices, Rel. 18 introduces RedCap-optimized
positioning methodologies. This includes, for example, positioning reference signal (PRS)
transmission in a narrow bandwidth complying with the UE bandwidth capabilities, or
UE support for time of arrival measurements. The study item under the name low power
high accuracy positioning (LPHAP) in Rel. 18 [TR 38.859] discusses such combinations
of RedCap and positioning methods. In addition, positioning methods on the sidelink can
be used as well, for example offering ranging as a new service. With the enhancements
of positioning services in Rel. 18, two techniques improving the positioning accuracy will
be incorporated into the 5G system. The first is bandwidth aggregation to increase the
bandwidth of the PRS, enabling better granularity. The second is similar to the known
RTK method used in satellite navigation. It allows the phase of the 5G carrier to also be
retrieved in order to improve the accuracy of the location estimate. Further details on 5G
positioning methodologies can be found in [Ref. 21] and [Ref. 32].
Study on further RedCap complexity reduction: The study item [Ref. 17] proposes in addition
to the 5 MHz bandwidth restriction, additional complexity reduction techniques like UE
processing relaxation and BWP operation with or without SSB and RF retuning. FR1
operation is targeted first in the aim of defining a Rel. 18 RedCap UE type.
16
3 REDCAP-RELATED BANDWIDTH PART ASPECTS
To enable flexible usage of the available bandwidth and potential support for dynamic
numerologies, 3GPP introduced the concept of bandwidth parts (BWP). This is the effec-
tive bandwidth from the UE's perspective in both directions, uplink and downlink. The
introduction of RedCap with limited bandwidth support by the UE reveals a possible mis-
match. TS 38.213 claims: “A UE expects the initial DL BWP and the active DL BWP after
the UE (re)establishes dedicated RRC connection to be smaller than or equal to the maxi-
mum DL bandwidth that the UE supports.”
Figure 8: Bandwidth part including possible conflict with network BWP and RedCap UE BW capability
Reminder: The BWP is configured via SIB, e.g. “BWP-DownlinkCommon“.
TS 38.213 about RedCap UE:

“A UE expects the initial DL BWP and the active DL BWP after the
UE (re)establishes dedicated RRC connection to be smaller than or
equal to the maximum DL bandwidth that the UE supports”.
Network BWP
Possible conflict!
► If the network schedules a BWP wider than the RedCap UE
bandwidth capability
UE ► 3GPP introduced the possibility of a RedCap-specific BWP
bandwidth (in fact, two possibilities: RedCap_common or UE_dedicated)
To prevent the BW of the common BWP, signaled by SIB, from exceeding the
UE capability, 3GPP decided to introduce the optional RedCap-specific BWP. The
exact BWP determination procedure is performed in multiple stages [Ref. 1]. The
first DL BWP has the same size and frequency location as CORESET0 and con-
tains the SS-PBCH block (including the MIB). This initial DL BWP is common for all
UEs (its maximum BW does not exceed the RedCap UE capability). Via the MIB con-
tent, the UE receives information about where (frequency) and when (time) to find
the RMSI (essentially, SIB1). The network operator may choose to configure in SIB1
an initial DL BWP overwriting the previous initial DL BWP definition by using the IE
DownlinkConfigCommon or UplinkConfigCommon (for the initial UL BWP), contained in
the IE ServingCellConfigCommon. The BW of a SIB1-defined initial BWP could in principle
have a size up to the channel BW. However, this would then not be usable by RedCap
UEs (a RedCap UE would regard this cell as barred). The network operator could limit the
SIB1-defined initial DL BWP for all UEs to the maximum value a RedCap UE can support.
As an alternative, SIB1 can also configure RedCap-specific initial BWPs via two additional
information elements initialUplinkBWP-RedCap-r17 and initialDownlinkBWP-RedCap-r17.
G devices 17
Figure 9: RedCap bandwidth part related signaling
Comm
on BW
Manda Network configures a common BWP for all UEs; drawback is that
tory this BWP is not allowed to be larger than the RedCap UE capability
for all UEs.
RedCa
p-
specifi
c BWP
Optionally, the network configures a specific BWP for RedCap
UEs with a maximum BW not exceeding the UE capability,
otherwise cell is considered as “barred“.
Dedica
ted BW
After UE is in connected state, the network may configure

dedicated BWPs (e.g. different ones for RedCap and non-RedCap
UEs) ⇒ higher flexibility to adjust BWP to UE needs.
After the UE enters the RRC_Connected state, the network can signal up to four dedi-
cated BWPs and set one of them to be active. Afterwards, the network can switch the
active BWP to one of the three other preconfigured BWPs. Using dedicated BWPs in the
RRC_Connected state, the network can manage individual BW restrictions for RedCap
and non-RedCap UEs. A UE capability determines how many dedicated BWPs are
supported and how to switch between them. In the simplest case, the UE can only sup-
port one dedicated BWP that can be changed by an RRC reconfiguration procedure.
18
4 REDCAP INFORMATION SIGNALING AND
NETWORK ACCESS RESTRICTIONS
As is usual in cellular communications, the network informs the UEs about certain con-
figuration details and network access policies via system information. Following the
introduction of RedCap in Rel. 17, this behavior lingers but with some marginal adapta-
tions. The objective is to identify RedCap at a very early stage in the connection setup but
also to enable the network to configure some access restrictions [Ref. 15]. The difference
in the latter signaling is the possibility for the network to restrict access depending on
the UE capabilities. In addition, since the goal of RedCap is to enable energy consump-
tion reduction strategies, the network can support neighbor cell reselection processes for
RedCap UEs and permit some RRM measurement relaxations in idle mode. The system
information blocks that contain RedCap-relevant information are SIB1, SIB2 and SIB4.
In addition, RedCap is declared as one of the features within a feature group where the
network can configure early identification signaling during the random access procedure
[TS 38.331].
Figure 10: System information signaling about early identification and network access restrictions related
to RedCap
cellBarredRedCap1Rx
intraFreqReselectionRedCap
cellBarredRedCap2Rx
SIB 1
Feature priorities
► redCapPriority-r17 halfDuplexRedCap-Allowed
► slicingPriority-r17
► msg3-Repetitions-Priority-r17
► sdt-Priority-r17 SIB 2 relaxedMeasurement
InterFreqCarrierFreqInfo
SIB 4
redcapAccessAllowed
4.1 RedCap-related UE identification

To support fast and efficient scheduling of required resources aligned with optional flex-
ibility in signaling overhead since RedCap IoT services may need lower QoS, the network
needs to already identify a RedCap UE in the very early cell access attempt. The objective
is to inform the network as early as possible during connection setup that the connection
will be established by a RedCap UE. A UE can indicate that it is a RedCap UE during the
random access procedure in either message 1 (Msg1) or message 3 (Msg3).
G devices 19
Figure 11: UE indicating that it is a RedCap UE during random access procedure
UE gNB
Random access preamble (Msg1)

Random access response (Msg2)
Scheduled transmission (Msg3)
UE can indicate in Msg1 (MsgA) Contention resolution (Msg4)

or Msg3 that it is a RedCap UE.
Contention based random access
Furthermore, this early indication signaling uses either the scheduled transmission (Msg3)
from a RedCap-specific logical channel ID or optionally the random access preamble or
Msg1 (PRACH occasion or PRACH preamble). The latter runs in combination with the
featurePriorities signaling.
Feature priority signaling via SIB1 affecting Msg1 RedCap indication

For the sake of brevity, we will not further discuss the random access procedure in 5G NR
as defined in TS 38.321. However, in general terms, the network indicates random access
resources that the UE may use for random access preamble transmission. As optional
signaling (see section on RedCap feature priority signaling for details), the network may
indicate feature priority configurations in SIB1. This corresponds to a feature-specific
RACH partition. In this manner, the UE (like the RedCap UE) can be easily identified dur-
ing the random access procedure.
RedCap indication in RRCSetupRequest (Msg3)

The mechanism of the logical channel ID (LCID) can be used as a second method for
the network to identify a RedCap UE as an early indication via random access. The MAC
header contains an LCID field that determines the logical channel. In Rel. 17, the RedCap
UE uses instead of the LCID 0 for CCCH either the values 35 or 36, indicating a CCCH
with a size of 48 bit or 64 bit that is only relevant for RedCap UEs [TS 38.321]. This case
of Msg3 RedCap UE identification by the dedicated LCID(s) is applicable regardless of
whether the RedCap feature priority random access resource configuration has been
preconfigured by the network or not [TS 38.300]. The information element useFullResu-
meID in SIB1 indicates whether the UE should use the short RNTI or the full RNTI values.
4.2 RedCap-specific cell barring signaling in SIB1

Before delving into the details of RedCap-specific cell barring signaling, we will briefly
review the general 5G NR cell reservation and cell access restriction policies. On a high
level, two mechanisms for cell reservations and access restrictions are defined by 5G NR.
The first occurs in the context of unified access control (UAC) and allows the network to
configure access barring rules associated with a given access category and access iden-
tities mainly intended for cell loading. These categories or identities are associated with
higher layer protocols like NAS or are RRC-related. A well-known example is the definition
of a UE access category as an element of the USIM profile, which is related to the service
access. This would enable the network to configure service-specific cell access restric-
tions, like network operator maintenance work with higher priority compared to a default
user. This cell barring based on UAC will not be relevant for RedCap-specific cell access
and is mentioned at this stage for completeness only. See [Ref. 1] or TS 24.501 for further
details.
The second mechanism is related to system information signaling of cell status and spe-
cial reservations and barring policies influencing the UE cell selection and reselection
procedures as defined in TS 38.304. With respect to RedCap introduced in Rel. 17, a new
20
mechanism applies where the network can signal cell-specific policies for cell access that
are valid depending on certain UE capabilities.
Figure 12: Review of UAC and system information based cell access restriction signaling
Reminder: 5G NR defines two mechanisms to

impose cell reservations and access restrictions.
MIB
Unified access control (UAC)
SIB1 and
other system
information
e.g. cellBarred e.g. UAC-BarringInfoSetList
System information broadcast to indicate cell status Access barring check associated with given
and special reservations for the control of cell access category and access identities
selection and reselection [TS 38.304] [TS 38.331]
With the introduction of RedCap as a new UE type with new features, 3GPP extended
the existing configuration of cell-specific access restrictions with cell restrictions that are
bound to a specific RedCap UE feature. In general, the network can impose specific cell
access barring policies depending on the following three RedCap-related UE capabilities,
transmitted via SIB1:
Cell barred for UE with only one RX antenna: If SIB1 contains the IE cellBarredRedCap1Rx‑r17,
a UE with a single RX antenna capability would be banned from cell access and is
required to search for another suitable cell. The value of this Boolean type IE can either
be “barred” or “not barred”. The reason for configuring this flag is the fact that a single
RX antenna UE may have a smaller DL coverage. This is because a possible RX diver-
sity antenna gain in the DL direction is not given and therefore, the DL cell size would
be reduced. To compensate for the DL cell size reduction, the network could e.g. con-
figure repetitions or use higher aggregation levels and lower MCS values. Essentially,
the network needs to spend more of its resources to support one RX antenna devices,
potentially leading to reduced support for regular UEs. This is why network operators may
choose whether to allow one RX antenna devices on a cell level.
Cell barred for UE with two RX antennas: If SIB1 contains the IE cellBarredRedCap2Rx-r17, a
UE with two RX antenna capability would be banned from cell access and is required to
search for another suitable cell. The value of this Boolean type IE can either be “barred”
or “not barred”. Some 5G bands require a minimum of four RX antennas per UE. The
same arguments are valid as before when reducing from two to one RX antenna. If both
restrictions are broadcast in SIB1, then the cell does not allow any RedCap device to
access it at all.
Half-duplex UE permission: Operation in half-duplex mode impacts the scheduling algorithm

in the network since simultaneous RX and TX are not supported by the UE and the MAC
layer needs to buffer pending TX packets until a valid TX window appears. A potential
drawback is the impact on the overall cell spectral efficiency since, for example, simulta-
neous TX resources in parallel to an ongoing RX window cannot be used for transmission
of data units to other users. For this reason, 3GPP permits restriction of a cell with respect
to the UE half-duplex capability. As a Boolean type parameter, the information element
halfDuplexRedCapAllowed-r17 indicates whether cell access for a UE supporting half-
duplex mode only is permitted or not.
G devices 21
Integrated access backhaul (IAB) restrictions: An IAB node acts like a UE in the direction
towards the network (backhaul link) and like a base station in the direction towards a UE
(access link). The UE facet of an IAB node cannot employ any RedCap-specific features.
It behaves like a regular UE. A RedCap UE cannot behave as an IAB node forwarding
the radio signal to another UE since IAB increases the complexity of the UE itself, e.g.
simultaneous RX and TX, at least on the backhaul and access link [Ref. 1], and therefore
violates the goal of reduced capability.
Figure 13: RedCap UE capability related cell access restrictions
Network can restrict access on cell level! Specific for

RedCap features! But: There is no “RedCap-only“ cell!
Cell barred for 1 RX UE only Cell barred for half-duplex UE (HD-UE) only
Cell barred for 2 RX UE only
SIB1
Barred cell may use intra-
frequency reselection RedCap
field to assist with reselection.
Summarizing the RedCap-related UE capability access restrictions, note that these

additional policies are valid for RedCap UEs only. A non-RedCap UE would ignore the
signaling of SIB restrictions. On the other hand, considering the possibility of a RedCap-
only cell, note that such a feature was never discussed in 3GPP. This indicates there is
no chance to deploy a RedCap-only cell or network. Every cell that supports access for
RedCap UEs would also support access for traditional 5G NR UEs. This is because the
information signaling of RedCap-specific restrictions is complementary to the signaling of
the 5G NR system information.
Intra-frequency cell reselection indicator (IFRI) related to RedCap

Beyond the cell barring mechanisms, cell reselection may present a cumbersome pro-
cess with respect to energy consumption and UE mobility. Potentially, RedCap UEs will
incorporate low complexity hardware and emphasize low battery consumption when-
ever possible, or they will operate under more stationary conditions. To support the
UE with cell reselection, 3GPP introduces the concept of network assisted cell change
(NACC) or network assisted frequency information for cell reselection purposes in gen-
eral. With respect to RedCap, the cell barring signaling may have an impact on future
cell reselection. This is because, as described before, either general cell access restric-
tions or RedCap-specific cell access restrictions are applied. Via the master information
block (MIB), the cell can not only indicate a barring status (i.e. cellBarred), but can
also set a flag intraFreqReselection to either allowed or not allowed. In addition to this
general reselection flag, the network can signal in SIB1 a RedCap-specific parameter
intraFreqReselectionRedCap [TS 38.304].
The RedCap UE can recognize if the cell does not support RedCap in case the parameter
intraFreqReselectionRedCap is missing in SIB1.
We will first assume the MIB parameter cellBarred is set to “yes”. In this case, access is
forbidden for all UEs, regardless of whether they are RedCap UEs or not, and even for
emergency calls. In contrast to regular UEs, a RedCap UE needs to also acquire SIB1
on top of the MIB. In case SIB1 contains the parameter intraFreqReselectionRedCap, its
22
value overwrites intraFreqReselection from the MIB. If intraFreqReselectionRedCap (SIB1)
is set to “allowed”, a RedCap UE may reselect another cell on the same frequency. If
intraFreqReselectionRedCap (SIB1) is set to “notAllowed”, a RedCap UE can only reselect a
cell on a different frequency. Note that in addition, rules apply depending on whether the
cell operates in licensed spectrum or not. See TS 38.304 for further details.
Figure 14: Cell access barring and cell reselection signaling

Scenario 1: General cell barring is active
Intra-frequency cell reselection is a two-step

procedure involving MIB and SIB1 [TS 38.304].
cellBarred = yes
No UE is allowed to select this cell, not even for emergency calls.
MIB
intraFreqReselection
Non-RedCap UE
Allowed: may reselect another cell on same frequency
Not allowed: may reselect another cell on different frequency
RedCap UE reads SIB1. Overwrites
ignored by RedCap UE (uses SIB1 info instead)
SIB1 RedCap UE
We will now look at a second situation where the MIB parameter cellBarred is set to “no”.
This means that regular UEs are allowed to access the cell and intraFreqReselection is not
relevant. As before, a RedCap UE will also read SIB1, which may contain RedCap-specific
barring indications, e.g. whether a UE with one or two RX is permitted to access the cell
or not. Assuming the cell is barred for a RedCap UE because of these RedCap-specific
cell access restrictions, the SIB1 parameter intraFreqReselectionRedCap again indicates
whether the UE is allowed to search for another cell on the same or a different frequency.
Figure 15: Cell access barring and cell reselection signaling

Scenario 2: RedCap-specific cell barring is active
Intra-frequency cell reselection is a two-step

procedure involving MIB and SIB1 [TS 38.304].
cellBarred = no
No general access restrictions activated
MIB
intraFreqReselection
Not important as cell is not barred
RedCap UE reads SIB1.
RedCap-specific cell access restrictions (1 or 2 RX UE)

SIB1 are activated.
RedCap UE
G devices 23
4.3 RedCap feature priority signaling – early RedCap identification
As a digression, we will now briefly review Rel. 17 feature priority indication affecting
the random access preamble selection. The network optionally indicates in SIB1 the fea-
tures or feature combinations that are associated with a specific random access partition,
e.g. to enable access priorities or early indications. In the context of signaling of a feature
at the earliest possible stage, the mechanism of feature priorities is related to the spe-
cific Rel. 17 features defined as RedCap, slicing, coverage enhancement and small data
transmission:
► RedCap for reduced capability UEs: The network signals PRACH occasions or random
access partitions for RACH resources as well as preamble formats that are valid
only for RedCap UEs. As a result, a network receiving such a PRACH signal at those
preconfigured instances knows immediately that the connection is established by a
RedCap UE.
► Network slicing for a UE requesting a connection related to a specific network slice
[Ref. 24]
► Small data transmission (SDT) priority to allow a UE to request a connection setup for
small data only
► Coverage enhancements (CE) (Msg3-Repetitions) to indicate that the UE supports
coverage enhancement features
These priorities are used to determine which FeatureCombinationPreambles the UE should

use when a feature maps to more than one FeatureCombinationPreambles. A lower
value means a higher priority. The process of feature priority is related to the random
access preamble and random access resource selection. The network schedules uplink
resources as random access resources to be used by the UE. In addition, the network
schedules policies for selection of the respective PRACH sequence or random access
preamble. In case of a feature like RedCap, the SIB1 may indicate a feature priority and
the configuration of the UL BWP may contain an optional RACH resource configura-
tion that can be used if the UE requests a connection setup related to a feature indicated
by that. Consequently, the network is informed about the UE’s intention or service
request at the earliest possible time. The network does not signal the same priority for
more than one feature, but according to TS 38.331, it is possible for several features to
be combined. Such a feature combination is then also related to a preamble resource
configuration, i.e. the network signals a priority for all features that map to at least one
FeatureCombinationPreambles.
24
Figure 16: Feature priority signaling and RACH resources for early RedCap feature indication
Reduced capability UE may be permitted to indicate RedCap in Msg1 transmission already.
The network may configure a PRACH resource for RedCap indication

⇒ UE selects RACH preamble associated with those features.
SIB 1
PRACH configuration index:
Periodicity: 40 ms 10 ms
Radio frame … SFN #1 … SFN #5 … SFN #9 … SFN #1017 … SFN #1021

featurePriorities
1 ms
Subframes SF #0 SF #1 SF #2 SF #3 SF #4 SF #5 SF #6 SF #7 SF #8 SF #9
Features can be
associated with PRACH
a random PRACH occasion in frequency domain RO #1 RO #2 RO #3 RO #4 RO #5 RO #6
access resource “I want to set up a
configuration. RedCap connection.“ Bandwidth for preamble transmission
PRACH slot
Preamble format B1 CP SEQ SEQ GP
The motivation for early RedCap UE identification is that RedCap UEs may have to be
treated differently than legacy UEs during initial access, i.e. before the UE capabili-
ties are known. Possible reasons that may require such early RedCap identification are
[TR 38.875]:
► Coverage recovery including link adaptation allows the network to react early, even
with Msg2 reaction to a previously received PRACH and enables more robust coding
to overcome coverage leakage since the RedCap UE may have less RX antennas
compared to a NR UE.
► Identifying the UE capability for UL modulation order for Msg3 and Msg5 scheduling
avoids a conflict in which the network schedules UL modulation schemes for the
signaling messages during the random access procedure that are not within the
capabilities of the RedCap UE. This is because the UE can only transmit its entire UE
capability information message once a signaling radio bearer is established.
► Identifying the UE bandwidth capability for Msg3 and Msg5 scheduling makes it
possible to avoid the unlikely, but possible conflict, that the network schedules a
bandwidth wider than 20 MHz for the signaling messages during the random access
procedure.
Since it is possible to configure the initial UL BWP to be wider than 20 MHz, we can
conclude that it is beneficial for the gNB to know that it is dealing with a RedCap UE
[Ref. 23].
G devices 25
4.4 Inter-frequency cell reselection info via SIB4
System information block SIB4 contains information relevant for inter-frequency cell
reselection and thus has an impact on UE behavior in idle and connected mode. As
described, one objective of RedCap is to minimize UE battery consumption while
reducing UE complexity. Monitoring metrics like RSRP or RSRQ for neighbor cells, intra-
frequency or inter-frequency, consumes energy within the UE. The network (serving cell)
can help the UE to save energy by signaling which neighbor frequencies are of interest.
The SIB4 information element InterFreqCarrierFreqInfo provides the UE with frequency
information for potential neighbor cells in order to assist with cell reselection. This aligns
with the introduction of the high speed dedicated network (HSDN) concept, allowing con-
figuration of higher priority cells for cell reselection purposes, especially when the UE is
in the high mobility state. The motivation is to allow a network configuration to influence
neighbor cell reselection based on a priority ranking between neighbor cells [TS 38.304].
Especially when considering a heterogenous network architecture with small cells and
macro cells overlapping, this signaling avoids unnecessary mobility procedures. The
neighbor frequency list, InterFreqCarrierFreqInfo, can also contain the information element
redCapAccessAllowed, informing a RedCap UE about which neighbor frequency supports
RedCap or not. In this way, a RedCap UE can save energy by not even measuring neigh-
bor cells’ RSRP or RSRQ if they do not allow access by RedCap UEs.
26
5 RRM MEASUREMENT RELAXATION
To assist the UE in its efforts to save battery power and reduce complexity by considering
real-world situations where e.g. a RedCap UE may be of a more stationary or low mobil-
ity type, the network may indicate situations where the UE is allowed to relax neighbor
cell measurements and reporting. What is the underlying idea here? As in all wireless
communications systems where UE mobility is required, the UE assists with mobility
services through radio resource management (RRM) and related measurements like the
well-known power level sampling (RSRP) and reporting for the serving cell and neighbor
cells. In simplified terms, a relaxed measurement condition allows the UE to perform less
of these RSRP measurements and remain longer in DRX cycles in order to save energy.
Such relaxed measurement rules are configurable for inter-frequency, intra-frequency or
inter-RAT situations and are of course conditional. Thus, they are not activated by a sig-
naling message but rather when an a priori signaled condition becomes true. There are
two high level conditions for such relaxed measurements. The first is a low mobility or
stationary UE condition, while the second requires a good SNR, i.e. a non-cell-edge UE
state. SIB2 broadcasts such evaluation criteria for low mobility and cell edge evaluation
[TS 38.331]. This information is valid either for all UEs or it can be restricted to RedCap
UEs only. The difference is that for normal UEs, the network can configure relaxed mea-
surement for stationary or not-at-cell-edge conditions, but for RedCap, the conditions
are stationary and stationary plus not-at-cell-edge conditions [TS 38.304]. With the IE
combineRelaxedMeasCondition2, SIB2 indicates whether both criteria, stationary and not-
at-cell-edge, need to be valid for the UE to relax its measurements. Note that the details
of RRM relaxation are actually more extensive and do not restrict it to RedCap UEs only,
e.g. there can be additional relaxation criteria for beamforming detection of secondary
cells signaled by the network. As mentioned, however, a RedCap UE does not support
multiple radio links. The network also configures the reporting of RRM measurements.
Finally, we should mention that relaxation of RRM is an optional feature for the UE and is
indicated via the UE capability information.
Figure 17: RRM measurement relaxation
To reduce complexity and energy consumption, the network

can configure the RedCap UE for relaxed measurements [TS 38.304].
Relaxed measurement rules for intra-frequency,

inter-frequency and inter-RAT measurements
Motivation:
► Stationary devices
► Devices not at the cell edge
Relaxed measurement criterion for stationary RedCap UE (RRC connected):

When “relaxed measurement“ (SrxlevRefStationary – Srxlev) < SSearchDeltaP – Stationary
condition is true, the UE performs less
measurements (larger DRX cycles). Time period over which the Srxlev variation is evaluated for stationary
criterion for relaxed measurement:
TSearchDeltaP – Stationary
G devices 27
The specification TS 38.304 defines the criteria for relaxed measurements. For the station-
ary condition, the rule that needs to be fulfilled is:
(SrxlevRefStationary – Srxlev) < SSearchDeltaP-Stationary
The network broadcasts two parameters via SIB2 to influence the stationary criterion. The
first parameter is an RSRP offset SSearchDeltaP-Stationary. The second parameter is a timer dura-
tion TSearchDeltaP-Stationary indicating a time that needs to expire without matching the stationary
criterion before updating the SrxlevRefStationary value. In other words, with the stationary crite-
rion, 3GPP configures an RSRP fluctuation definition to observe a stationary condition of
the UE, i.e. typically in a stationary situation, there is less RSRP variance.
For a RedCap UE, the second criterion can be that the stationary RedCap UE is not at a
cell edge. In addition to the stationary criterion that needs to be fulfilled, the network can
additionally configure search quality and search power level thresholds (SSearchThresholdQ2 and
SSearchThresholdP2). See also TS 38.133 for further details on relaxed measurements.
28
6 POWER SAVING FEATURES AND TECHNOLOGIES
6.1 Power saving overview
In almost every 3GPP release, techniques have been defined to reduce UE power con-
sumption. Any type of UE may benefit, but UE power saving is perhaps most important
for IoT devices including RedCap UEs. From a logical point of view, the complexity
reduction introduced with RedCap and the energy saving introduced with power sav-
ing methods are specified independently. Due to their obvious relationship, however, we
consider power saving features as an essential feature set that will be incorporated into
RedCap UEs to ensure successful operation. The objective of this section is to provide an
overview of existing power saving technologies along with a look towards Rel. 18. Further
information on power saving features can be found in [Ref. 1], [Ref. 2] and [Ref. 3].
A general classification of power saving features is shown in Figure 6. Three main mech-
anisms are covered that have a major impact on energy saving: hardware restrictions
and reduced capabilities, enhanced mechanisms and innovations, and lastly, operational
enhancements.
Since hardware complexity is one major factor influencing energy consumption, restric-
tion of the hardware capabilities can be a successful strategy to tackle this challenge.
There exist several methods that have been incorporated into wireless technologies. This
includes development of mobile devices with a lower power class (since the maximum TX
power has a significant impact on battery drain), restriction of the number of antennas,
or restriction of the bandwidth. In FDD networks, the half-duplex restriction where the
mobile device is either in TX or RX mode (but not both simultaneously) allows implemen-
tation of a single RF chain.
To ensure successful operation in a wireless network, the protocol structure defines cer-
tain signaling procedures and behaviors a UE must comply with. One method to reduce
energy consumption involves optimizing certain signaling procedures with a focus on
energy consumption. As one example of how signaling reduction can lead to more
energy efficiency in certain circumstances, a more stationary UE may completely skip the
tracking area update (TAU). A prominent mechanism to increase battery life is the defini-
tion of sleep operations, better known as discontinuous transmission (DTX) or reception
(DRX). During such periods, a UE does not need to monitor downlink control channels
like the system information broadcast or paging, or does not need to monitor UL schedul-
ing messages. Other mechanisms include enhancements of overall signaling procedures
like cross carrier scheduling in carrier aggregation or dual connectivity situations. Here,
the protocol information is sent over one carrier only, thus preventing the receiver from
also monitoring the control channel information of additional carriers.
To optimize and extend the power saving results, 5G wireless technology began introduc-
ing innovative and enhanced mechanisms to either substitute or complement existing
procedures and behaviors. One good example is the so-called wake-up signal. It is used
to decide whether the UE has to fully wake up and monitor the legacy control channel or
can skip the next monitoring instance.
The following pages will discuss the power saving features introduced in LTE and 5G that
are related to the specification release and are described as logically independent fea-
tures. Note that in real-world implementations, a combination of energy saving features
is typically used to obtain optimum results. Depending on the circumstances, multiple
power saving features can be activated simultaneously.
G devices 29
6.2 Power saving aspects in wireless communications up to Rel. 15
With the introduction of machine type communications technologies like LTE-M or
NB-IoT, power saving has experienced a sort of renaissance due to its heightened impor-
tance. Despite the fact that standby times have represented a key performance indicator
for UEs since the early days of wireless communications, this KPI has become even more
important with the introduction of machine type communications. Moreover, certain
methods that have been applied since the earliest days have now been enhanced.
6.2.1 Discontinuous reception (DRX)

In radiocommunications, a distinction is made between two general operating modes, i.e.
connected and idle/inactive mode.
In idle/inactive mode, the UE must periodically update its knowledge based on system
information broadcast by the network. To enable mobile terminated traffic, the UE must
monitor the physical downlink control channel (PDCCH) for paging messages and decode
the paging message on its allocated physical downlink shared channel (PDSCH). This
consumes electrical energy.
Discontinuous reception (DRX) is a generic mobile communications mechanism that

allows a device to stop monitoring the radio channel, e.g. PDCCH, and enter low power
consumption mode or sleep mode for a certain period of time. The general principle of
DRX mode is depicted in Figure 18 [Ref. 1]. Configuration details for the MAC layer are
described in TS 38.321.
Figure 18: Discontinuous reception (DRX) – general principle of operation
Schedule data
UE continuously UE does not Short DRX cycle
monitors PDCCH. monitor PDCCH.
5G Monitor PDCCH Short cycle
to wait for
Short DRX cycle
On duration Opportunity for DRX “delayed” packets
UE shall Monitor PDCCH arriving at gNB
monitor PDCCH.
Long DRX cycle

DRX cycle
There is a short and a long DRX cycle configured by RRC.

Monitor PDCCH
Since several protocol layers like mobility management (MM), session management (SM)
and radio resource control (RRC) define the operational behavior of the UE, the generic
DRX mode can be subdivided into two modes: connected DRX (c-DRX) and idle DRX
(i-DRX).
When the UE is in the RRC_IDLE state, it is tracked by the network with a paging mecha-
nism even though it has no active radio connection to the base station.
The general paging mechanism in LTE and 5G uses a concept where, in the downlink
direction, the paging message for each individual UE carried by the PCCH logical chan-
nel is multiplexed on the PDSCH. The PDCCH allocates the resource for the PDSCH. A
UE in idle/inactive mode needs to monitor the PDCCH in order to check whether there
are any paging messages on the PDSCH. The UE searches for an identifier indicating pag-
ing content, known as P-RNTI within the PDCCH. If P-RNTI is found, then the downlink
control indicator (DCI) that carries PDSCH resource scheduling information is decoded.
This DCI information will redirect the UE to the associated PDSCH resource blocks (RB) to
30
decode the higher layer paging message as to its relevant UE identity (i.e. TMSI or IMSI).
If the UE does not find its identity in the paging record, it will return to check PDCCH for
P-RNTI at another time. This paging process is repeated. A UE operating in DRX mode
only monitors the PDCCH at defined time intervals, i.e. within a paging cycle, for instance
every 40 ms or 100 ms. The UE will enter sleep mode the rest of the time. Without DRX,
the UE would have needed to monitor PDCCH continuously for each radio subframe (i.e.
every 1 ms), which significantly drains the battery in RRC_IDLE/INACTIVE state. Applying
the DRX mechanism conserves the battery life of the device.
Paging occasion (PO) and paging frame (PF) are two key terms that we need to under-
stand when discussing i-DRX operation. PO is the subframe where the P-RNTI may be
transmitted on the PDCCH during the paging cycle. In DRX operation, there is only one
PO for each UE in a DRX paging cycle. The paging frame (PF) is one radio frame contain-
ing one or multiple paging occasions (PO). Several timers configured either per cell or
per UE determine the duration of the paging cycle, paging frame and paging occasion
[Ref. 2].
In addition to idle state DRX, connected DRX (c-DRX) operated in the RRC connected
state is another approach taken to conserve the battery life of the device. In c-DRX mode,
the UE is allowed to monitor the PDCCH discontinuously to check if the scheduling mes-
sages can be detected by its C-RNTI on the PDCCH.
While in the RRC_CONNECTED state, the UE permanently monitors the PDCCH for
scheduled reception of information such as data packets or control information. The MAC
layer can be configured via RRC for a DRX period where the UE does not need to moni-
tor the PDCCH and thus enters a sleep mode to save energy. There are two DRX cycle
lengths in 5G: a short DRX cycle and a long DRX cycle. The idea here is that the short
DRX cycle is started in combination with the last packet arriving for an ongoing connec-
tion since it is likely for the connection to be resumed or for “delayed” packets to arrive.
For example, in a typical web browsing scenario, after downloading a file containing a
web page, it is likely that the human user will interact by clicking on another link and thus
trigger another data transfer. Such behavior is targeted by the short DRX cycle length.
The long DRX cycle starts after a longer period of inactivity or when activated via a MAC
CE. DRX is configured by a higher layer and is either activated via a timer that expires or
via MAC control elements.
6.2.2 Extended discontinuous reception (eDRX)

Extended discontinuous reception (eDRX) is a power saving optimization feature intro-
duced in 3GPP Rel. 13 and designated for LTE-M or NB-IoT. As the name implies, it
supports a longer DRX cycle than the legacy DRX power saving features. For example,
in the RRC idle state, the paging cycle is extended from 2.56 s to minutes or even hours
(more precisely, approx. 44 min in LTE-M and approx. 3 h in NB-IoT). Thus, we consider
eDRX as an important feature focused on IoT devices targeting battery life of several
years and only requesting very low and sporadic data services. eDRX was introduced in
5G with Rel. 17 for all UEs, but RedCap UEs may benefit the most. The maximum value
of the 5G eDRX cycle is 10485.76 s (2.91 hours) for RRC_IDLE and 10.24 s for
RRC_INACTIVE, while the minimum value of the eDRX cycle is 2.56 s for both
RRC_IDLE and RRC_INACTIVE. In Rel. 18, the cycle time for RRC_INACTIVE UEs will be
further extended.
G devices 31
6.2.3 Power save mode (PSM)
For the first time, 3GPP Rel. 12 introduced power save mode (PSM) as a power saving
feature designed for LTE-M and NB-IoT to help conserve battery power.
To update the network about its availability, the UE performs periodic tracking area
updates (TAU) after a configurable TAU timer has expired. The UE then remains reachable
for paging during the paging time window (PTW) of the idle state. Once the PTW expires,
it enters deep sleep mode (PSM) and becomes dormant and unreachable until the next
periodic TAU occurs. During PSM mode, the UE turns off its circuitry yet is still registered
in the network, meaning that the UE closes the AS connection yet keeps the NAS status.
The advantage of such an approach lies in the fact that the UE can wake up immediately
from PSM without having to re-attach or re-establish the PDN connections. This avoids
extra power consumption due to additional signaling message transmission for the higher
layer connection establishment procedure. PSM maximizes the downtime of the UE,
which significantly reduces battery consumption.
6.2.4 Wake-up signal (WUS)

A wake-up signal (WUS) was introduced in 3GPP Rel. 15 for LTE-M and NB-IoT as the
first RATs to use this mechanism. At first glance, it looks like a repetition of the paging
indicator channel introduced in 3GPP Rel. 99 (UMTS). With the paging indicator channel,
the network sends physical layer information that indicates whether the UE should read
the higher layer control information on the respective control channels. The advantage is
that recognition of the paging indicator channel is based on a matched filter or correla-
tion metric, a sort of low power receiver, and does not require more energy consuming
demodulation and decoding operations with the main baseband receiver.
Similar to the UMTS paging indicator channel, 3GPP specified for LTE operation a physi-
cal signal in conjunction with I-(e)DRX or C-(e)DRX operation that can be decoded or
detected before the UE decodes paging on PDCCH and PDSCH. The benefit of WUS is
that it reduces unnecessary power consumption related to PDCCH monitoring. Without
WUS, the UE would have to monitor the PDCCH for paging at each PO. With the WUS
approach, the UE only needs to decode the PDCCH when WUS is detected. Otherwise,
the UE will stay in sleep mode. This represents an efficiency improvement, especially
at times of low activity on the control channels within a cell, e.g. at night. Figure 19
compares the WUS principle with conventional I-DRX operation. The upper section
shows I-DRX and the lower section shows DRX with WUS. This technical improvement
enhances UE battery life.
Figure 19: DRX versus DRX with WUS detection

UE power consumption
PO PO PO
PDCCH monitoring
PDCCH monitoring
PDCCH monitoring
detection
WUS
Sleep mode Sleep mode

Time
UE power consumption
PO
PDCCH monitoring
detection
WUS
Sleep mode
Time
32
The network controls the WUS timing with respect to the associated paging occasion.
The WUS duration is the maximum time duration configured by the network for the UE to
detect the WUS. After the WUS is detected, the network leaves a time gap to allow the
UE to resynchronize to the network and switch from low-power sleep mode to the main
baseband circuitry in order to be ready to decode the PDCCH.
WUS is an optional feature for the UE. From the eNB perspective, WUS operation can be
enabled or disabled by the cell. If the feature is disabled, the UE will not detect the WUS
and normal PDCCH monitoring for paging messages is necessary.
To ensure that the UE does not miss any paging messages, the robustness of WUS plays
a very important role. The missed detection rate for the signal should be kept as low as
possible, say below 1 %. To achieve a highly reliable signal, WUS adopts a Zadoff-Chu
sequence of length 131. This provides very good cross-correlation and auto-correlation
properties.
6.3 Power saving in 5G Rel. 16

With respect to power saving, one of the major extensions in Rel. 16 is the incorporation
of machine type communications and power related features into the 5G NR technology
[Ref. 1]. The 5G system is expected to support various types of devices ranging from
high-end UEs through wireless sensors with no power supply. Therefore, 3GPP Rel. 16
also focuses on the issue of power consumption. In comparison to LTE as the previous
technology, 5G technology is expected to improve the energy efficiency by a factor as
great as the traffic increase according to the ITU-R requirement for next generation wire-
less technology for IMT-2020. To comply with the requirements from IMT-2020, 3GPP
submitted a radio interface technology (RIT) proposal including EUTRA, 5G NR, LTE-M or
eMTC, NB-IoT and LTE+NR DC.
According to the 3GPP study on NR power saving [TR 38.840], device energy efficiency
can relate to support for the following two aspects:
► Efficient data transmission in active connected mode (active mode)
► Low energy consumption when there is no data (sleep mode)
Certain techniques such as DRX, inactive state and BWP switching were already intro-
duced. Moreover, 3GPP Rel. 16 introduces additional power saving techniques that cover
both UE modes as depicted in Figure 20.
Figure 20: Power saving techniques for 3GPP Rel. 16
► Cross-slot scheduling with

minimum scheduling delay
► Wake-up signals
Sleep Active ► Per-BWP maximum DL MIMO layers
► Efficient transition to idle
mode mode ► UE preferences for adaptive DRX
► Relaxed RRM
parameters, CA and maximum BW
measurement
► SCell dormancy-like behavior
G devices 33
6.3.1 UE preference for power saving parameters
To improve the support for various UE types especially with respect to energy consump-
tion, one innovative idea associated with Rel. 16 is to allow the UE to indicate certain
preferences. This enhances the established concept of UE capability information trans-
fer by allowing a flexible transformation of configuration requests from the UE to the
network. The UE can help the network to configure power saving methods with the
following information:
► drx-Preference: UE preference for c-DRX, e.g. various timer and counter setting
proposals
► maxBW-Preference: UE preference for maximum aggregated bandwidth of the cell
group
► maxCC-Preference: UE preference for maximum number of secondary component
carriers of the cell group
► maxMIMO-LayerPreference: UE preference for maximum number of MIMO layers of
the cell group
► minSchedulingOffsetPreference: UE preference for minimum scheduling offset for
cross-slot scheduling of the cell group
► releasePreference: The UE can indicate its preferred RRC state, i.e. if it prefers to
transition to idle immediately.
The UE first informs the network about which of these parameters it actually supports as
part of the UE capability information message. Then, the network replies with a (sub)list
of parameters the UE is actually allowed to use. Together with every allowed parameter,
the network also configures a prohibit timer preventing the UE from repeating the config-
uration faster than this timer.
As one example, we will consider releasePreference in more detail:
After the UE has informed the network that it supports the releasePreference parameter,
the network may allow the UE to use it by sending a releasePreferenceConfig message.
As part of this configuration, the network also sends a prohibit timer. From now on, the
UE may send a UEAssistanceInformation message including e.g. its release preference.
However, if and when this happens is up to the UE. In case the UE changes its mind and
wants to send another value for the same parameter, it has to wait at least as long as the
respective prohibit timer. Otherwise, the network could become overloaded. With the
releasePreference parameter, the UE can indicate its preferred RRC state. Possible values
are: idle, inactive, connected, outOfConnected.
In case a UE in the connected state does not expect data to be transmitted soon, it
can save energy by not waiting for the inactivity timer to time out. Instead, it sends
releasePreference = idle or inactive to the network (whatever state the UE prefers). If the
UE does not have any preference but just wants to leave the connected state, it would
report: releasePreference = outOfConnected. The UE may revoke its decision leaving the
connected state by sending releasePreference = connected in order to say “I want to stay
in connected mode.” The procedure is summarized in Figure 21.
34
Figure 21: UE release preference
UECapabilityEnquiry
UECapabilityInformation
releasePreference
releasePreferenceConfig RRC Reconfiguration

→ including prohibit timer → OtherConfig “setup”
UEAssistanceInformation
releasePreference = inactive
min. = prohibit time UEAssistanceInformation
releasePreference = connected
●
● ●
● ●
●
6.3.2 SCell dormancy-like behavior

One key aspect of 5G technology involves dual connectivity and carrier aggregation,
originally leveraging the eMBB and URLLC services for higher throughput and reliability.
However, since power saving issues were not considered initially, certain enhancements
were introduced in Rel. 16 to provide mechanisms for power reduction even in higher
data rate situations.
The bulk of UE power consumption is due to monitoring the downlink control channels
and performing quality measurements/reporting on a carrier link. In idle mode, this is
tackled with mechanisms like DRX.
Another technique introduced in Rel. 16 within the carrier aggregation work item involves
reducing control channel reception for specific secondary cells. In fact, in a carrier aggre-
gation configuration, the UE is expected to monitor all active SCells. One example of
where this occurs is a scenario with FR1 and FR2 carrier aggregation. In that case, the
receiver must operate two independent RF chains simultaneously.
Especially the FR2 bands will, on one hand, allow larger carrier bandwidths. On the other
hand, however, they will introduce shorter slot times that will increase the number of
decoding operations for control channels per time unit. Additional measurements are also
required to control beam mobility.
In order to save energy, LTE introduced the option to deactivate an SCell and put it into
a dormant state. The idea in NR is to apply the dormant state to the configuration of a
BWP rather than at the SCell level. The SCell is configured with a minimum of two BWPs,
one of which is marked as the “dormant BWP”. The SCell itself remains activated the
whole time. The UE can now be switched back and forth between the normal and dor-
mant BWPs. A UE using the dormant BWP stops monitoring the PDCCH on the SCell and
also stops transmitting on the UL (i.e. configured grant, RACH, SRS). The UE continues
to perform configured CSI measurements and transmit periodic CSI and will possibly trig-
ger beam management procedures such as SCell beam failure recovery. The advantage
compared to SCell deactivation is that the UE can be quickly returned to “normal BWP”
operation mode through a downlink control message on PCell/PSCell.
G devices 35
Figure 22: Activation of a dormant BWP on an SCell
SCell 1
SCell 0, BWP1 BWP1 BWP2 = dormant
Frequency
1. Active BWPs on SCells
Active
2. Switch to BWP2 on SCell 1 Active CSI measurement/reporting,

beam management, PDCCH monitoring,
UL grant and RACH
3. Dormant BWP on SCell 1 use BWP2 =
dormant
Time CSI measurement and reporting,

beam management
6.3.3 Maximum number of DL MIMO layers

Many FR1 bands require a UE to be able to operate with up to four DL MIMO layers.
The majority of the FR1 bands and all FR2 bands still require UE operation with up to
two DL MIMO layers. How many layers will actually be used for a data transmission
depends on the current radio conditions and the amount of data to be transmitted.
Ultimately, the gNB decides per transmission how many MIMO layers it will use for this
DL transmission and informs the UE accordingly as part of the scheduling information in
a DCI. Since the number of DL MIMO layers can change frequently, the UE must have all
receive chains ready in case they need to be used. If the UE somehow knew that the gNB
would not schedule more than e.g. two DL MIMO layers, then it could turn off the other
two receive chains and save energy.
In Rel. 15, the maximum number of DL MIMO layers can be configured by the
network. However, this is a cell-wide configuration, valid for all UEs in this cell
(PDSCH-ServingCellConfig IE).
Starting with Rel. 16, it is now possible to configure a maximum number of DL MIMO
layers per BWP. This allows more granular and faster changes to the configuration.
Figure 23: Maximum DL MIMO layer adaptation per BWP
Cell 1
BWP1, BWP2,
max. no. of DL MIMO layers = 1 max. no. of DL MIMO layers = 4
BWP1
active
BWP switch
BWP2
active
Time
The network could configure e.g. two BWPs: BWP1 with maximum number of
DL MIMO layers = 1, BWP2 with maximum number of DL MIMO layers = 4. In case more
DL throughput is required, the network simply switches the active BWP for this UE to
BWP = 2. This could be complemented with the idea to also configure the BW of BWP1
to be small and the BW of BWP2 to be larger. This situation is illustrated in Figure 23.
Note that the BW of BWP1 and BWP2 could also be overlapping or even identical. Then,
a BWP switch would just change the configuration and not the frequency range to be
36
used by the UE. On the UL, it has already been possible to configure the maximum num-
ber of MIMO layers per BWP (maxRank) since Rel. 15 (at least for codebook based UL
transmission).
6.3.4 Relaxed RRM measurements

Even if a UE is in the idle/inactive state, it must regularly measure the received DL power
of its serving cell and neighbor cells. If certain broadcasted thresholds are reached, the
UE will reselect to a better cell. These regular cell measurements (a.k.a. RRM measure-
ments) represent a major part of the power consumption of UEs in the idle/inactive state.
The periodicity of the RRM measurements is part of the network configuration to the UE.
Under certain conditions, for example when the UE is not at the cell edge, the periodic-
ity of measurements can be reduced since it is unlikely that the UE will need to change its
cell soon.
Moreover, in case of low mobility, it is unlikely that the UE will need to change cells
quickly. Thus, the RRM measurements do not require high periodicity.
Therefore, in the interest of power saving, the UE may relax (reduce) the RRM measure-
ments if at least one of the following conditions is met:
► Low mobility: The serving cell measurement does not change more than a relative
threshold during a time period.
► Not at cell edge: The UE is not at a cell edge, meaning the serving cell, beam RSRP,
RSRQ and SINR are above a threshold.
The base station broadcasts its support for measurement relaxation along with the appli-
cable parameters in SIB2. The UE will then perform relaxation if the UE supports it after
measuring and evaluating the overall cell quality.
6.3.5 Cross-slot scheduling with minimum scheduling delay

5G applies a very flexible scheduling concept, allowing dynamic scheduling of time and
frequency resources. To support low-latency data communications, the time between the
downlink control information (DCI) and the corresponding downlink or uplink resource
can be very short, requiring frequent monitoring by the UE. This is contrasted with the
idea of enabling power saving during the active time via cross-slot scheduling. This
involves defining a minimum offset (K0min / K2min) between the time when the UE receives
the scheduling information (PDCCH) and the time when the UE receives the downlink
data (PDSCH). This will enable a micro-sleep time of up to 16 slots where the UE cannot
be scheduled for data reception, triggered to receive A-CSI or transmit a PUSCH.
In the same manner, the network can define a minimum offset (K2min) that represents the
minimum time between when the UE receives the scheduling information (PDCCH) to
when the UE receives the uplink transmission resource (PUSCH).
Figure 24: Cross-slot scheduling
Slot 1 Slot 2 Slot 3 Slot 4

Decoding
Decoding
PDCCH
PDCCH
Sleep Sleep PDSCH PDSCH
K0min = 2 slots (1…16)
G devices 37
To optimize this power saving method, 3GPP decided that it is up to the UE to send UE
assistance information with the minimum applicable K0 / K2 value(s) over RRC per band-
width part. In addition, the timers can be dynamically adapted via PDCCH scheduling.
Moreover, to reduce the signaling overhead, the network can configure up to two pre-
ferred timer settings per bandwidth part [Ref. 1].
6.3.6 Wake-up signal in 5G Rel. 16

The UE in idle/inactive mode as well as in connected mode is required to monitor the
downlink control channel (PDCCH) to receive information from the network. According
to a study [Ref. 3], control channel monitoring consumes the most power for a UE.
Discontinuous reception (DRX) functionalities as explained will pause the monitoring and
set a specific periodicity (DRX cycle) for the UE to wake up and receive the control chan-
nel. DRX will require the UE to wake up periodically according to a DRX cycle and for a
period known as the “OnDuration” where the UE will detect the PDCCH channel for a DL/
UL grant. The UE wakes up independently no matter whether data is expected or not. For
a long quiet transmission period, the UE might wake up several times and still not receive
any data. In this case, monitoring of the full PDCCH channel (CORESET and DCI) leads to
high power consumption and is a waste of energy. As an additional optimization of the
DRX procedure, the DRX procedure was modified with a wake-up signal (WUS). Rel. 15
introduced such a concept for LTE-M and NB-IoT radio technologies. Rel. 16 is introduc-
ing the wake-up signal concept for 5G. Before the active time (“OnDuration”) starts, the
UE will check a specific PDCCH search space location (DCI 2_6 scrambled by PS-RNTI
configured in physicalCellGroupConfig > dcp-Config-r16) to know whether the UE should
skip receiving the full PDCCH data for the upcoming "OnDuration" or even longer. WUS
signaling is linked to long c-DRX and is only configured when c-DRX is configured (only
for UEs in connected mode). If WUS is not configured, legacy operations apply. WUS is
monitored at an “offset” before the expected expiration of the DRX cycle and the start of
the “OnDuration” period.
Figure 25: Wake-up signal (WUS) in 5G

UE active time
On On
Offset duration Offset duration
WUS UE not WUS UE

off active on active
DRX cycle DRX cycle
UE awake during DRX active time

UE asleep during DRX active time
6.4 Power saving enhancements in 5G Rel. 17

UE power saving is always a very important topic within 3GPP. Rel. 17 added a new class
of devices with reduced capabilities, thus named RedCap devices. Since they only need
to support e.g. 20 MHz bandwidth in FR1 and only one RX chain, they have much lower
power consumption compared to regular 5G devices.
Another new feature allows UEs to stay in RRC inactive mode in case they only need to
transmit a small amount of data (small data transmission, SDT). This will also save power
as a side effect.
In addition, some power saving features introduced in Rel. 16 have been enhanced in
Rel. 17 in order to address outstanding issues. This will be the focus of this section. All
Rel. 16 power saving features, except RRM measurement relaxation, are designed for
the idle/inactive mode of the UE. This also includes the wake-up signal (WUS). Rel. 17
38
extends this idea to the idle/inactive state in order to optimize the paging procedure. The
second area of improvement involves optimization of PDCCH monitoring during DRX
active time for connected mode UEs.
Reducing power consumption for idle/inactive UEs

A UE in idle/inactive mode needs to regularly wake up and monitor the PDCCH and look
for e.g. a possible paging indication. If found, the UE would have to decode the cor-
responding PDSCH to find the actual paging message, just to maybe figure out: “the
message was not for me”. A lot of energy is wasted. This is the standard paging cycle
with the so-called paging occasion (PO) in the beginning of the paging cycle. In order to
save energy, a paging early indication (PEI) signal has been introduced. If a PEI is sent
before the upcoming paging occasion, the UE needs to check the paging message as
described before. If a PEI is not sent, the UE does not have to check the next PO and can
therefore save energy (PEI detection consumes much less energy than checking PO). This
situation is depicted in Figure 26.
The PEI itself is PDCCH based, which means the UE has to monitor a PDCCH config-
ured with a peiSearchSpace containing a DCI 2_7 where the CRC is scrambled with a
PEI-RNTI.
Figure 26: Paging early indication for idle/inactive UEs

Paging cycle
occasion
occasion
Paging
Paging
SSB
SSB
SSB
SSB
SSB
SSB
PEI
PEI
When the UE wakes up and wants to read the PDCCH, it has to adjust the automatic gain
control, synchronize in time and frequency, and maybe also perform RRM measurements.
To do so, the UE usually needs to detect multiple SSBs before the PO. This again means
energy consumption. In order to make detection of only one SSB before a PO sufficient,
the gNB can help the UE by providing additional reference signals. The idea is to use the
tracking reference signals (TRS) that have already existed since Rel. 15 for this purpose.
Usually, the TRS are configured in a UE-specific manner for the connected UEs. In case
they already exist for certain connected UEs, they could also be used for the idle/inac-
tive UEs. Alternatively, the gNB can configure them exclusively for the idle/inactive UEs.
Whether TRS are available for the idle/inactive UEs can be signaled either in the paging
DCI and/or in the PEI itself. The TRS configuration is broadcast in SIB17 (Figure 27).
Figure 27: Paging early indication plus tracking reference signal (TRS) for idle/inactive UEs
DCI 2_7 / PEI-RNTI: Paging cycle
► PEI
► TRS availability
occasion
occasion
Paging
Paging
SSB
SSB
PEI
PEI
TRS enabled, configuration known by idle/inactive UEs from SIB17
G devices 39
PDCCH monitoring improvements for connected UEs
The second Rel. 17 power saving optimization is for UEs in connected mode during DRX
active time. During this time, the UE has to monitor the PDCCH for e.g. possible DCI
scheduling of DL data. The gNB can preconfigure up to three different search space set
groups (SSSG) with different monitoring rates. Depending on how frequently the gNB
detects DL data to be sent, it can switch between the different search space set groups.
This will save energy in case the DL data is sparse. Moreover, PDCCH monitoring can be
configured to be skipped completely for some amount of time (Figure 28).
Figure 28: Enhancements to power saving in connected mode, search space switching
Definition of search space switching groups (SSSG) to schedule

via DCI which search space is to be used in connected mode
Periods of PDCCH monitoring
Data Data
Micro- Micro- Micro- Micro- Micro-

c-DRX sleep sleep sleep sleep sleep c-DRX
DCI scheduling: DCI scheduling: DCI scheduling: DCI scheduling:

use dense use sparse use dense use sparse
search space search space search space search space
Sidelink enhancements with respect to power saving

Rel. 16 introduced a direct communications mode over the PC5 interface known as side-
link for services. It has use cases in the context of automotive applications [Ref. 27]. The
Rel. 17 feature set extends the sidelink applications and use cases, e.g. sidelink com-
munications in a relay mode for coverage extensions or sidelink communications for
non-automotive communications like industrial machine to machine connections. In addi-
tion, certain enhancements to sidelink power consumption play a pivotal role in these
extensions. Using the term vehicle-to-everything (V2X) where the first applications were
vehicle-to-vehicle (V2V), the extension could encompass communications between vehi-
cles and pedestrians (vehicle-to-pedestrians, V2P). Considering the communications
devices used by people, there is clearly no restriction just to devices like smartphones.
Future trends are moving towards intelligent clothing items with communications capa-
bilities or wearable devices with such capabilities. Power saving techniques are obviously
crucial for such devices.
One power saving method involves definition of DRX operation for sidelink broadcast,
groupcast and unicast. This entails the introduction of on-durations and off-durations in
sidelink communications along with corresponding UE procedures. One critical aspect
here is that sidelink communications occurs on an ad-hoc basis without a priori knowl-
edge of the communications role, e.g. in a UE to network connection. Thus, common
wake-up times need to be configured across multiple UEs. Moreover, configuration of the
DRX parameters must be possible in either the Uu-interface signaling when in coverage,
or using default mechanisms for out-of-coverage scenarios.
With respect to power consumption on the sidelink, the two opposing operations of sens-
ing and transmission are the most problematic. To reduce the energy consumption for
sensing, two relaxed methods are discussed: partial sensing or random resource alloca-
tion for TX. In the latter case, the UE starts transmitting without any prior sensing of the
channel, e.g. in a kind of “emergency” situation such as when a pedestrian steps into the
40
road. Partial sensing requires sensing of at least part of the resource pool. In combina-
tion with some sort of preconfiguration, this can provide a way to successfully combine
power saving with collision avoidance.
Additional power saving methods exist for sidelink operation, but for the sake of brev-
ity, we will not consider them here. Such methods involve reduction of the bandwidth or
BWP adaptation for sensing and resource allocations, preconfiguration of the resource
pool, or relaxation of the sidelink measurements.
6.5 Power saving enhancements in 5G Rel. 18

As expected, the motivation for enhancements in power saving continues with the
upcoming technology release of 5G. Several study items are proposed to add new meth-
ods for power saving. One major research and study topic in Rel. 18 is the application and
introduction of artificial intelligence (AI) and machine learning (ML) algorithms. The ini-
tial focus is on enhancements of radio layer procedures like CSI-RS transmission and CSI
feedback reporting and beamforming optimization. An adjacent study also discusses AI
mechanisms for power optimization.
Extended reality (XR) and impact on power saving

Another topic in Rel. 18 involves extension of the use cases or services provided by 5G.
While legacy communications systems talked about services or use cases, a new buzz-
word in the industry is the term metaverse. This is associated with the introduction of
new use cases like extended reality (XR). XR combines augmented reality (AR) and virtual
reality (VR). AR is one such variant in which digital information is overlaid on images of
reality viewed through a device. With VR, users are totally immersed in a simulated digi-
tal environment or a digital replica of reality. Since XR introduces new facets of use cases
to end users, it may also exhibit complexity or power consumption issues with param-
eters that are challenging to handle. Besides discussion of XR use cases, power saving
issues specific to extended reality XR are also under study. This includes, for example,
specific power saving configurations related to XR service characteristics like periodic-
ity, jitter, latency and reliability. XR applications are generally processing intensive and
require connectivity to high-end computational devices, e.g. PCs, game consoles and
GPUs. Thus, they are rarely implemented in RedCap UEs. Aspects like UE processing
power, memory, storage, battery life as well as heat dissipation play a pivotal role in XR
UE design. Accordingly, any power saving mechanisms that support these services are
beneficial.
Non-terrestrial networks and power saving

Rel. 18 is advancing the evolution of non-terrestrial networks (NTN) [Ref. 26]. As a new
study item, power saving mechanisms related to NTN are also included. First, certain
power saving methods like DRX, reduced TAU or mobility restrictions are configured for
NTN, similar to terrestrial connections. In addition, however, the discussed power sav-
ing methods will tackle certain NTN-specific connection characteristics. Due to the long
delay time in NTN, HARQ operation can either be extended to 32 HARQ processes or
HARQ feedback can be disabled (a mechanism that also reduces energy consumption).
As a mandatory requirement, an NTN UE is equipped with a GNSS receiver to determine
its terrestrial position. The discussed power saving mechanisms consider a more relaxed
position estimation if only required for satellite acquisition and therefore reduce the
power consumption for GNSS. Lastly, one interesting and sophisticated power saving fea-
ture involves the concept of data storage or data collector devices. Satellite coverage may
not always be available and the UE can relate its DRX time to the satellite constellation.
Especially for IoT devices, a collector UE may be permanently attentive and collect data
from the surrounding IoT UEs. It stores this data and then forwards it when the satellite
becomes visible.
G devices 41
Ambient IoT or zero power UEs
In contrast to the idea of energy saving we have discussed so far, another idea involves
energy harvesting to make the UE more autonomous with respect to its battery. We can
even imagine UEs without any battery at all ("zero power UEs"). Sophisticated methods
are under study to determine whether it is possible to harvest energy from the received
RF signal. Energy harvesting based on external sources like movement, solar cells or
external heat is outside the scope of this document.
Network energy saving

A major topic in Rel. 18 is power saving on the network side, i.e. network energy saving.
This covers various fields basically divided into energy consumption, energy efficiency
and energy saving. The 5G network is considered from a holistic perspective, which
includes selection of devices and entities with very low energy consumption. Studying
energy consumption requires determination of the consumed energy, up to the granular-
ity of single entities. Energy efficiency represents the quotient of the transferred data over
the consumed energy. Energy saving involves methods to reduce the network power con-
sumption. Several energy saving mechanisms are discussed, including:
► Turning off cells when no capacity is needed. This is applicable especially for small
cells to avoid coverage loss.
► Turning off radio carriers. This is similar to the previous item, but instead specific radio
carriers are deactivated, e.g. in carrier aggregation or dual connectivity situations.
► Turning off RF elements in an antenna array has an impact on the beamforming of the
cell, e.g. narrower beams will turn into wider beams. However, if the coverage impact
is tolerable, it may represent a way to save energy.
► Advanced sleep mode (ASM) is a similar concept like DTX on the UE side. Whenever
feasible, the gNB may turn off its radio for a short period of time. Such time durations
can last for several frames, several slots and even up to single OFDM symbols within
one slot. The drawback is the impact on the required signaling information, e.g. SSB
signaling. Thus, a minimum of radio signaling is required to be on the air.
► Uplink wake-up signal to activate a dormant cell, initiated by the UE.
► Adaptation of SIB, i.e. SIB on demand. This can reduce the signaling overhead due to
permanent on-air signals and thus reduce the energy consumption of e.g. secondary
cells.
► Semi-static configuration of SSB and UE-specific reference signals like CSI-RS. This
idea studies relaxation of signaling overhead in agreement with the UE, especially
when connection conditions allow it.
► Adaptation of BWP, similar to the UE power saving feature. The network can also
shrink the active BWP if the situation allows it.
The study in TR 38.864 considers certain aspects of network energy saving in further
detail.
42
Figure 29: Network energy saving aspects
Holistic approach: from cloud to component,

energy saving methods in the entire 5G system ETSI and 3GPP definition: energy efficiency
DVMN CoAdes.MN
EEMN,DC = ––––– EEMN,CoA = –––––––––
ECMN ECMN
Data volume / Designated coverage area /
energy consumption energy consumption
SSB Data RF RF
RF RF
5G NR RF RF
Blank/DTX RF RF
RF RF
RF RF
LTE Advanced sleep mode (ASM)
RF RF
Turn on/off cells Activate/deactivate RF RF
carriers/RAT
Turn on/off RF
G devices 43
7 COVERAGE ENHANCEMENTS
Any type of UE may benefit from coverage enhancement features, but they are perhaps
most important for IoT devices including RedCap UEs. As mentioned, RedCap primarily
targets machine type communications and one key aspect here is uplink-centric com-
munications. 3GPP conducted a study [TR 38.830] on NR coverage enhancements. The
overall set of proposals can be classified into time domain strategies (e.g. automatic
retransmission), frequency domain strategies and other strategies.
To improve NR uplink coverage for both FR1 and FR2, the following enhancements on
PUSCH, PUCCH and Msg3 PUSCH are supported [TS 38.300]:
► Enhanced aggregation of multiple slots with transport block (TB) repetition is
supported for both PUSCH transmission with dynamic and configured grant. The
maximum number of aggregated slots for counting based on available slots and
counting based on physical slots is 32.
► Transport block processing over multiple slots with and without repetition is supported
for both PUSCH transmission with dynamic grant and configured grant. This includes
enhancements of interleaving and transport block channel coding mechanisms.
► DMRS bundling is supported where the UE maintains phase continuity and power
consistency across PUSCH transmissions or PUCCH repetitions to enable improved
channel estimation.
► Dynamic PUCCH repetition factor indication configured per PUCCH resource was
introduced.
► Aggregation of multiple slots with TB repetition for Msg3 transmission is supported
and is applicable with the contention based random access procedure.
Figure 30: Coverage enhancements – ideas
E.g. time domain CE methods

Transport block
Enhanced PUSCH repetitions processing over
Transport block
⇒ Depending on TDD UL/DL configuration multiple PUSCH
PUSCH PUSCH PUSCH PUSCH PUSCH
Transport block Transport block PUSCH with

different orthogonal
Transport block interleaving over multiple PUSCH cover codes (OCC)
E.g. frequency domain and other CE methods
Study on π / 2 BPSK MPR Enhanced PUSCH Study on UL PUSCH

reduction and power boosting DMRS density TX diversity
PUSCH (26 dBm)
Pmax
PUSCH
In addition to the CE methods incorporated into the current 3GPP specifications, various
other methods for coverage enhancements were discussed and are left for future stud-
ies. Some examples are frequency hopping for uplink channels that could benefit from
a wider channel bandwidth, the dual transmission MIMO scheme, permission for higher
burst power on the uplink, or simultaneous transmission of the signal by an orthogonal
cover code separation.
44
In the context of the 5G evolution, some additional coverage enhancement technologies
are discussed in the Rel. 18 standardization phase. This includes several methods target-
ing improvement of the uplink coverage:
► PRACH coverage enhancements by permitting multiple PRACH transmissions with the
same beam
► Enhancements to realize a higher UE power limit for carrier aggregation or dual
connectivity scenarios
► Enhancements for maximum power reduction (MPR) resulting in higher TX power
► Support for dynamic switching between DFT-S-OFDM and CP-OFDM. The current
5G NR uplink considers both waveforms as possible. Via RRC configuration, the
network controls the uplink. DFT-S-OFDM is beneficial for UL coverage because of its
lower crest factor or PAPR. A study was launched to discuss more dynamic switching
to support cell-edge UEs.
G devices 45
8 REDCAP-RELATED T&M ASPECTS
Test and measurement solutions ensure proper implementation of RedCap features in the
user equipment and verify the performance of RedCap deployed in 5G networks. T&M
thus covers a wide range of applications, including component testing, RF testing of UEs
and base stations, signaling testing and mobile network testing. This section will briefly
introduce the relevant T&M aspects with respect to the RedCap technology features
described in the previous section.
8.1 R&S®CMX500 one-box tester (OBT) supporting RedCap

The test system that will be the basis of the Rohde & Schwarz portfolio for RedCap testing
of end-user devices is the R&S®CMX500 radio communication tester. The R&S®CMX500
is a future-proof solution for 5G NR testing, featuring an intuitive and flexible web based
user interface known as R&S®CMsquares. Supporting manual interactive operation
as well as automatic sequence-controlled test protocols, R&S®CMsquares is a power-
ful software solution with unique modules for all signaling use cases. These range from
R&D design through end-to-end application testing, production and conformance tests.
Introduction of a one-platform strategy for all 5G NR test equipment enables a unified test
environment for signaling and non-signaling testing through all stages of 5G device pro-
duction [Ref. 29]. A specific hardware configuration known as R&S®CMX500 “OBT lite”
is tailored to lower data rate applications like 5G RedCap. Manufacturers of IoT chipsets,
modems and end devices can use the one‑box tester for all device production stages,
from early R&D to type approval conformance testing.
Some key facts that are relevant for RedCap in connection with the R&S®CMX500 are:
► Support for multiple RATs like LTE, 5G FR1 frequencies up to 8 GHz, and FR2 mmWave
frequencies up to 50 GHz in a single instrument
► Support for 5G standalone mode/non-standalone mode
► Support for a large variety of present and future LTE and 5G 3GPP band combinations
► Future-proof modular and scalable hardware architecture
► Web based R&S®CMsquares user interface for RF tests, functional tests, application
tests and protocol tests
Figure 31: 5G NR test solution R&S®CMX500 “OBT lite” hardware configuration
46
8.2 UE RedCap related RX and TX tests
The specification series TS 38.101-X [TS 38.101-1], [TS 38.101-2] establishes minimum
RF requirements for NR UEs operating in FR1 and FR2 along with minimum RF require-
ments for interworking with other radios and minimum performance requirements. In
other words, this specification series defines the technical RF requirements a UE must
fulfill. To ensure proper implementation, the specification series TS 38.521-X [TS 38.521-
1], [TS 38.521-2], [TS 38.521-4] defines measurement procedures for conformance testing
of UEs that exhibit RF characteristics for FR1, FR2, CA and DC. It also defines measure-
ment procedures for conformance testing of user equipment (UE) that is subject to
performance requirements as part of 5G NR. The document series TS 38.101 defines the
RF requirements, while the document series TS 38.521 defines measurement procedures
for conformance and performance testing. Note that there are no RF requirements or test
procedures for RF interworking. Since RedCap does not support CA and DC operations,
such tests are applicable to 5G NR UE only.
The major RF requirements in the specifications correspond to the previously described

features, i.e. maximum bandwidth support of 20 MHz in FR1 and 100 MHz in FR2, maxi-
mum TX power as power class 3, and a reference receiver sensitivity depending on
whether the UE has one or two RX antennas.
UE TX testing
With respect to TX and RX RF testing, there are only marginal differences between a
RedCap UE and a 5G NR UE. The main difference is that RX and TX tests are executed
only up to the maximum bandwidth the RedCap UE supports. Transmitter tests verify-
ing the UE TX power are mostly similar between RedCap and 5G NR since the UE power
class PC3 is similar in both technologies. This is true except for the FR2 situation where
the RedCap UE is PC7, which corresponds to the same maximum power of 23 dBm, but
defines more relaxed spherical coverage requirements [TS 38.521-2]. The current release
of the RF test specification does not define any maximum transmit power reduction tests.
UE RX testing
The reference sensitivity is the basis of the test methodology used to verify receiver per-
formance. The R&S®CMX500 system simulator sends downlink signals according to a
defined fixed reference channel (FRC) and test model (TM) at a certain reference input
power level at the UE RX port. The FRC and TM configure channel parameters like MCS
and TBS, resource allocations and RF parameters like SNR and RSRP as well as propa-
gation aspects, etc. in order to ensure that the tests are conducted under reproducible
conditions. The test is passed when the UE receiver achieves a throughput of 70 % or
higher at the reference sensitivity receiver level. The reference sensitivity is band and
channel bandwidth dependent, but since the RedCap throughput is typically not very
high, there is a minimum test time required to achieve sufficient statistical confidence
in the BLER evaluation. While the RX sensitivity tests apply a reference channel on the
downlink under static conditions, only the SNR and RX input level are essential param-
eters. Additional RF performance tests are defined that verify the RX throughput under
various RF conditions like fading and Doppler shift. Further tests, especially in the context
of RF conformance testing, also verify the receiver performance under situations with an
interferer, e.g. co-channel, adjacent channel interferer or out of band blocking tests. This
also entails an increase in test system complexity. Rohde & Schwarz offers various test
solutions, e.g. the R&S®TS8980 type approval test system using the R&S®CMX500 as the
centerpiece. Another procedure related to receiver performance verifies UE procedures
related to channel quality (CQI) reporting [Ref. 1]. Test scenarios are defined to check
whether the UE reports the proper channel quality under the configured downlink chan-
nel conditions. The purpose of the CQI reporting requirements is to verify that the RedCap
UE is tracking the channel variations and suggests via CQI feedback the largest possible
transport format according to the prevailing channel state for the frequency non-selective
scheduling. Note that CQI reporting tests adapted to RedCap UEs require an update of
G devices 47
the specification with respect to reporting time, signaling message content and test dura-
tion. These items were still in the draft stage when this document was created.
The screenshot in Figure 32 shows a typical example of RedCap UE TX and RX mea-

surements. The UE receives power control commands and should transmit with the
maximum power of 23 dB for the TX measurement. For the RX measurements, the BLER
is indicated as well as the achieved throughput of around 3.5 Mbps, given a channel
bandwidth of 20 MHz.
Figure 32: RedCap UE TX power and RX BLER and throughput measurements with the R&S®CMX500
8.3 RedCap-related protocol testing

Besides reduced capability in the context of an RF and UE capability restriction feature
set for low complexity devices in 5G for MTC and IoT use cases, RedCap includes sev-
eral signaling aspects described in previous sections of this document like cell access
restriction signaling, bandwidth part signaling or early feature indication. The document
TS 38.523 specifies test scenarios for protocol or signaling testing to verify proper proto-
col stack implementation in the UE. The R&S®CMX500 radio communication tester can
be used to execute such signaling tests. The test possibilities range from configuration
of user-defined scenarios via a programming interface through execution of validated
test cases that are supplied for conformance testing. The R&S®CMX500 offers an XLAPI
programming interface using the Python language, permitting the user to program and
configure custom signaling test scenarios. This method allows early testing that is rel-
evant especially during R&D of new features. Together with the R&S®CMX500mars
message analysis tool within the web based user interface R&S®CMsquares, this allows
developers to perform in-depth signaling scenario configuration and analysis by combin-
ing protocol stack analysis with RF signal measurements.
To ensure proper implementation of RedCap, SDOs like the 3GPP are defining test cases
to verify proper protocol implementation [TS 38.523]. Moreover, organizations like the
GCF offer a global device certification scheme. Rohde & Schwarz supports this device
certification scheme by providing protocol test scenarios as validated test cases on the
R&S®CMX500 and on full type approval test systems like the R&S®TS8980.
In addition to 3GPP testing based on TS 38.523, several operators worldwide also define
proprietary carrier acceptance test scenarios. The difference is that on a high level, 3GPP
protocol testing verifies proper protocol implementation, i.e. whether the specification
is implemented properly. In contrast, carrier acceptance testing extends the signaling
48
testing with a usability verification that verifies the user experience. At the time of drafting
this document, no RedCap-specific carrier acceptance tests were available, but they are
expected in future deployments.
RedCap-related signaling scenarios

The signaling test cases defined in TS 38.523 contain some signaling test scenarios
defined especially for RedCap UEs. In addition, they contain signaling scenarios for gen-
eral 5G NR UEs that will be slightly adapted to verify RedCap-related signaling scenarios.
For example, the 3GPP RAN5 working group, responsible for test case definition, allows
more than 260 test cases based on 5G Rel. 15 to be executed on a RedCap UE as well.
More Rel. 17 RedCap-specific test cases are under development. The TTCN code is in
working progress at the time of writing this document. Generally speaking, RedCap pro-
tocol testing aspects are described in the test specification TS 38.523 Rel. 17:
► UE behavior during cell selection or reselection
► Random access and early feature indication signaling
► Bandwidth part signaling by indicating a separate BWP for a RedCap UE
► RRM measurement relaxation
► Signaling procedures for 5G NR slightly adapted for RedCap, e.g. UE capability
signaling, transport block size adaptation and MAC, RLC and PDCP header information
Before delving into RedCap-specific signaling scenarios, a user performing RedCap-

related tests should first verify that the UE supports RedCap and that the emulated
network also supports RedCap. During the attach procedure, the UE transfers the
requested radio access capabilities to the network via the UECapabilityInformation
message. This complex and extensive signaling message contains several informa-
tion elements describing the details of the radio access capabilities. The information
element RedCapParameters contains the Boolean flags supportOfRedCap and
supportOf16DRB-RedCap that are the two most relevant features indicating whether
the UE is a RedCap UE or not. The screenshot in Figure 33 shows this uplink signaling
message capability information indicating a RedCap-capable UE.
Figure 33: UE capability information message details indicating support for RedCap
Screenshot from R&S®CMX500mars message analyzer
G devices 49
The network side transfers system information messages. With respect to RedCap, one
of the most important system information blocks is SIB1 since it contains the various
cell access restriction parameters and early indication signaling affecting the cell selec-
tion and reselection process for the UE as well as the UE random access procedures.
The screenshot in Figure 34 shows details of the SIB1 system information, especially the
access related cell restrictions.
Figure 34: System information block SIB1 indicating support for RedCap
If we are sure that the UE and network support RedCap, several test cases can be exe-
cuted on the R&S®CMX500 in order to analyze more detailed signaling behavior.
Test scenario for cell selection and cell reselection

To verify that the UE properly follows the rules defined for cell selection and r eselection,
protocol scenarios are defined as test cases to ensure that the test steps are executed
properly:
► The system simulator activates a 5G NR cell that indicates that the RedCap CellBarred
status is true. It then verifies that the UE does not perform a random access within the
next 60 s on that cell.
► The system simulator changes to another cell with removed CellBarred signaling. The
UE should trigger a random access procedure within the next 300 s.
► The system simulator changes to another cell where the intraFreqReselectionRedCap
information element is not present at all. It then verifies that the UE does not perform a
random access within the next 60 s on that cell.
► The system simulator emulates two cells and one cell is ranked higher than the other
cell according to the reselection rules [TS 38.304]. First, it is verified that the UE
does not select the lower ranked cell, i.e. no random access is initiated there. Then,
the simulator changes the SIB4 inter-frequency neighbor cell indication to allow the
RedCap UE to access the frequency of the neighbor cell. Lastly, it verifies by initiating
a mobile terminated short message transfer that the UE is camped properly on the
neighbor cell.
50
Test scenario for random access procedure
To verify that the UE properly follows the rules defined for the random access proce-
dure and UE identification or for the feature priority indication described in the section on
RedCap information signaling and network access restrictions, TS 38.523 describes some
protocol test scenarios.
► The system simulator activates a cell that indicates via SIB1 that the UE should use the
full RNTI value range. In a mobile terminated connection, the simulator verifies that the
UE uses the expected RRCResumeRequest1 message by setting LCID to the value 36.
► The system simulator activates a cell that configures specific PRACH resources for
RedCap UE in the common initial UL BWP. In a mobile terminated connection, the
simulator verifies that the UE transmits the PRACH preamble with the correct preamble
index on one of the configured resources and sends Msg3 with LCID indicating
RedCap. The test case is repeated with a change in that the network configures the
specific PRACH resources in a RedCap-specific UL BWP instead of the initial UL BWP.
► A feature with respect to the uplink coverage enhancements allows aggregation of
multiple slots with transport block repetition for Msg3 transmission. If configured,
the UE requests such Msg3 repetition via separate RACH resources if the DL RSRP
is below a configured threshold. The signaling test procedure now emulates such a
cell scenario and verifies that the RedCap UE will use such RACH resources for Msg3
repetition indication.
The screenshot in Figure 35 shows an example of early indication of RedCap capability

by the UE during the random access procedure. In this example, the UE uses message 3
(Msg3) to indicate via the logical channel ID (LCID) that it supports RedCap.
Figure 35: RedCap UE indicating support for RedCap in Msg3 during the random access procedure
G devices 51
Test scenario for RedCap-specific BWP operation
The signaling scenarios for testing BWP operation for RedCap-specific signaling of the DL
and/or UL BWP as described in the section on RedCap-related bandwidth part aspects
verify the following UE behavior:
► The system simulator activates a 5G NR cell with initialDownlinkBWP-RedCap and
intialUplinkBWP-RedCap configured in the system information. First, a mobile terminated
connection is established via scheduling of the PDCCH paging on the RedCap-specific
DL BWP. It is verified whether the UE accepts the connection via RRCSetupRequest.
Second, the simulator sends the RRCSetup message and verifies that the UE transmits
the UL HARQ acknowledgement on PUCCH resources configured for the RedCap-
specific UL BWP.
Figure 36: System information block SIB1 indication RedCap-specific downlink BWP
Test scenario for RRM measurement relaxation

This specific signaling scenario has the preconditions that the UE must support RedCap
and RRM measurement relaxation, i.e. the IE rrm-RelaxationRRC-ConnectedRedCap-r17 is
set to true in the UE capability information.
► The test case emulates a single cell scenario where RRM measurement relaxation is
configured for stationary situations. In addition, the RF conditions on the DL are set
to fulfill this criterion. The UE should send a UL UEAssistanceInformation message
indicating that the criterion for RRM measurement relaxation is fulfilled. In a second
stage, the RF conditions on the DL are modified to not fulfill the criterion. The UE
should indicate this in the uplink assistance information signaling message.
52
Test scenarios for general signaling with RedCap-specific settings
Besides the previously mentioned RedCap-specific signaling scenarios that analyze
UE behavior in specific situations and verify proper protocol implementation in the UE,
TS 38.523 contains several general protocol test scenarios for 5G NR UEs that can be
executed with minor changes to test a RedCap UE instead. Such protocol scenarios verify
UE implementations such as the following:
► RRC signaling test cases are available to verify that the UE reports the correct
capability information, i.e. a RedCap UE should send e.g. RedCapSupport,
longSN‑RedCap, rrm-RelaxationRRC-ConnectedRedCap, no support of NE-DC (to name
only a few RRC IEs for RedCap) [TS 38.331].
► MAC PDU and control information set according to RedCap to verify that the UE
transfers the correct MAC header information. This test case is available for 5G NR UEs
and is slightly adapted for RedCap UEs.
► Transport block size (TBS) selection is a test case that verifies that the 5G NR UE
selects the correct TBS depending on the data throughput. Since RedCap is expected
to support lower data rates and the RedCap UE may not support every MCS, this test
procedure is slightly modified to verify that the RedCap UE selects the proper TBS.
Note that there are multiple test cases for UL and DL scenarios in TS 38.523.
► Small data feature group priority in combination with RedCap represents a test
scenario where the network configures early UE identification for both feature groups,
SDT and RedCap. The UE should use the correct RACH resource.
► RLC test cases are adapted for RedCap UEs to verify that RedCap UEs signal the
correct sequence number length according to their capabilities.
► The PDCP test case for a handover scenario is modified to verify that the RedCap UE
will apply the PDCP status report with the correct length.
8.4 Power saving measurement aspects

The section on power saving features and technologies introduces the various technology
aspects related to UE power saving. Test methods to verify proper protocol implemen-
tation of such features in the UE are covered by the signaling test scenarios defined in
TS 38.523, which are available in the protocol test setup with the R&S®CMX500. For the
sake of brevity, we will not further consider signaling test cases related to power saving
since they generally behave similar to the RedCap signaling test cases that were previ-
ously described.
There is another test item to verify power saving methods on UEs, i.e. the effective
energy consumed by the device itself. This field may consider the energy consumption
of components, e.g. a developer may use test tools like an oscilloscope to measure sig-
nal integrity and signal energy in the time domain [Ref. 30]. Determination of the energy
consumption is beneficial not only for the user of the device and the potential use cases.
In the meantime, there are also several regulatory mandates that require indication of the
consumed energy on a product level [Ref. 31].
The performance of power saving features like DRX, WUS, BWP switching, dormant
SCell, RRM measurement relaxation etc. can only be tested and analyzed in a controlled
emulated environment that allows reliable debugging, optimization or R&D support
by anticipating mechanisms deployed in the future. A battery life measurement setup
consisting of the R&S®CMX500 in combination with an R&S®NGM power supply unit
allows execution of test scenarios where certain signaling or connection related steps
are executed with simultaneous monitoring of the energy consumption. The power sup-
ply unit supports up to two-channel measurements of voltage, current and power with
a high sampling rate, very fast load recovery and low ripple and noise. Depending on
the power supply model, several supply voltages as well as maximum power and maxi-
mum current values are available. The fast sampling rate and low ripple and noise allow
direct analysis of the impact of the power saving features on UE power consumption.
For example, during a connection, the radio communication tester activates DRX and the
G devices 53
R&S®CMX-KM110 measurement option directly measures the UE power consumption.
This allows detection of the DRX execution time within the UE, the absolute energy sav-
ing between non-DRX and DRX mode, the energy consumption during sleep mode (DRX
on) and possible power ripples or power spikes that happen unexpectedly. Figure 37
shows an example of a 5G NSA test sequence, configured in the R&S®CMsquares
sequencer tool for power measurements. The UE's consumed power is measured in con-
junction with activation of certain connection parameters like EN-DC, carrier aggregation,
padding, DRX and wake-up signals.
Figure 38 shows the overall setup for battery life measurements with the R&S®CMX500
radio communication tester and the R&S®NGM200 power supply unit. One advantage of
this setup for the user is that the radio communication tester and power supply unit are
interconnected via LAN. This allows them to synchronize with one another and coordi-
nate the signaling of the connection steps with the power sample measurements. The
user only needs to work within the GUI of the R&S®CMX500, i.e. R&S®CMsquares where
the sequencer tool allows configuration of test setups and direct activation of power
measurements. In the measurement window, it is then possible to view and analyze the
consumed energy.
In summary, the R&S®CMX500 provides 5G RF and 5G signaling testing capabilities along

with a fast, accurate and easy to use method for analyzing UE energy consumption.
Figure 37: Power saving measurement campaign and UE power measurements

Screenshot taken from R&S®CMX500
Power consumption graph

EN-DC
CA
MAC padding
No padding
c-DRX
Rel. 16 WUS
54
Figure 38: Battery life measurement setup with the R&S®CMX500 and R&S®NGM200
8.5 Conformance, regulatory and LBS test solutions

Due to space limitations, this chapter will only provide an overview of the requirements
for regulatory, conformance and positioning testing related to RedCap. While RF and
signaling testing will be impacted by the introduction of RedCap, conformance and regu-
latory testing should not be generally affected by RedCap. Since, however, regulatory
tests like RED or FCC are essential for market access for all electronic devices while cer-
tification testing like the Global Certification Forum (GCF) ensures interoperability, we will
summarize the relevant testing aspects insofar as RedCap is concerned.
Conformance and regulatory testing

This aspect deals with the certification process established by the telecom industry offer-
ing mobile and interoperability certification programs based on conformity to agreed
standards. A prominent organization is the GCF with its vision to lead the global ecosys-
tem by facilitating interoperable devices, networks and services to enable high-quality,
reliable and secure wireless communications (see www.globalcertificationforum.org).
To enable conformance testing, e.g. according to GCF or PTCRB and regulatory test-
ing according to regulatory bodies, Rohde & Schwarz offers type approval test systems,
e.g. the R&S®TS8980 full range approval test system. This system fulfills the certification
entry criteria for the GCF work items and PTCRB requests for conformance testing. The
device certification process is vital for the mobile communications industry since compli-
ance with GCF and PTCRB certification requirements ensures that handsets operate as
specified in various networks. With the R&S®CONTEST sequence tool, the system offers a
modular and fully automated measurement setup for 24/7 operations.
At the time of writing this white paper, existing GCF test scopes included machine IoT
(M-IoT) and industrial IoT (IIoT), positioning, LTE-M and NB-IoT. With the Umbrella-WI-530
work item containing several sub work items, the GCF CAG conformance agreement
group decided to update about 20 legacy Rel. 15 test cases for RedCap UE testing and
to specify around seven new Rel. 17 RedCap UE test cases, with a primary focus on the
FR1 frequency bands n1, n5, n8, n28 n41, n78 and n79. Agreement on separate work
items (WI) is the distinction between full duplex and half duplex operation (FD-FDD and
HD-FDD) and FDD<->TDD transfers. The default UE in line with GCF is equipped with
two RX antennas, but exceptions are possible. We anticipate in the near future addi-
tional Rel. 15 test cases amended to RedCap features, new Rel. 17 RedCap test cases
being defined and the frequency extension of the test scope to FR2 in the longer term. As
RedCap mainly affects the UE RF and protocol behavior, the agreed GCF test types are
“RF” and “Protocol” in a first step, whereas “RF Performance” and “RRM” are planned
for later work items. RF, protocol and RRM test cases are already being validated on the
R&S®TS8980.
G devices 55
Figure 39: The R&S®TS8980FTA-3A full range conformance test solution
in line with requirements from GCF, PTCRB and regulatory bodies
Location based service testing

Location based or positioning services are obviously not exclusively restricted to RedCap.
In fact, the opposite is true: Positioning services can be offered for any type of UE.
Moreover, no RedCap-related positioning techniques have been introduced in the 5G
standardization process. In future releases, 3GPP will tackle the aspect of LPHAP support-
ing positioning estimates on low complexity and low power UEs. Therefore, we anticipate
that positioning testing will play an essential role in the RedCap technology evolution.
Most likely even in the first generation, RedCap devices will offer location based services.
To ensure proper positioning estimates, a test system like the R&S®TS-LBS can be used to
execute various test scenarios like GNSS supported positioning, 5G RAT based position-
ing or even barometric positioning services or z-axis positioning. Further details on the
various positioning techniques in 5G and how to test them can be found in [Ref. 21] and
[Ref. 32].
Figure 40: R&S®TS-LBS positioning test system for GNSS and RAT based positioning in FR1 and FR2
56
RedCap-related regulatory testing according to RED and FCC
Regulatory certification and compliance testing are essential steps for market access
in accordance with legal requirements. Certain regions have implemented test require-
ments and procedures in order to control market access and avoid faulty devices that can
harm other devices. A prominent example is the CE marking in the European Union that
states that the “CE marking is an administrative marking with which the manufacturer or
importer affirms its conformity with European health, safety and environmental protec-
tion standards for products sold within the European Economic Area (EEA)”. The Radio
Equipment Directive (RED) in the EU mandate 2014/53/EU covers the following areas:
► Health and safety to ensure the protection of persons, domestic animals and property
► EMC to ensure an adequate level of electromagnetic compatibility (EMC) as set out in
Directive 2014/30/EU
► Radio spectrum requiring that “Radio equipment shall be so constructed that it both
effectively uses and supports the efficient use of radio spectrum in order to avoid
harmful interference”
► Specific testing, e.g. specific tests for radio equipment supporting certain features
ensuring access to emergency services
There are various documents describing the relevant test methods and requirements as
well as the validity of the tests, e.g. EN 301 908-25 is applicable for 5G NR UEs.
Similar regulatory tests are mandated in the US by the FCC. There, testing is divided
into the areas of human exposure and EMC/RF. The document CFR47 describes the test
requirements.
At the time of drafting this white paper, there were not yet any RedCap UE-specific reg-
ulatory tests. However, since regulatory testing is more generic, we assume that the
current market access mandates related to test requirements like EN 301 908-25 and
CFR47 will also apply to RedCap UEs. Rohde & Schwarz has a wide range of test solutions
related to regulatory and EMC testing in its portfolio. Figure 41 shows a typical example
of an EMC device test with a specific test aperture consisting of a positioning system and
a test antenna and performed in an EMC test chamber.
Figure 41: EMC regulatory test setup using a specific test aperture in an EMC test chamber
G devices 57
8.6 Mobile network testing verifying RedCap KPIs in the network
Mobile network testing solutions aim to ensure mobile network performance and qual-
ity in either private or public networks. Since 5G networks support new and innovative
applications for many use cases while providing critical features related to performance,
reliability, latency and security. Rohde & Schwarz offers specialized test solutions that
are designed to prepare, deploy and operate mobile networks to meet quality of service
and quality of experience (QoS/QoE) specifications for human and machine end-users.
These solutions range from mobile network testing using the R&S®TSMx passive net-
work scanner family through interactive testing of QoE KPIs using a mobile device like
a smartphone with the QualiPoc Android software. Finally, there are benchmarking and
network optimization strategies like the SmartBenchmarker and SmartAnalytics software
facilitating data collection and analysis, especially for evaluating the network performance
score (NPS).
5G mobile network testing related to RedCap basically seeks to verify the obtained KPI in
an E2E connection. The QualiPoc Android software runs on a RedCap UE. In an E2E con-
nection, various KPIs like throughput, BLER and latency, or application quality parameters
like voice or video MOS values can be determined.
Is coverage equal to coverage?

What are some possible differences in the existing mobile network testing strategies if we
designate RedCap as the feature to be verified? RedCap introduces cell-specific and UE
capability-specific access restrictions. Consequently, there is a possible difference in how
we assess the network coverage. A simple field strength (RSSI) or RSRP based coverage
plot would indicate different coverage than what a RedCap UE would experience when
specific cell access restrictions are applied. A mobile network scanner like the R&S®TSMx
that can decode the system information message allows users to verify the effective cov-
erage taking certain access restrictions into account. A similar test aspect involves BWP
analysis to detect possible network deployment errors, e.g. detection of cells that require
an initial BWP that exceeds the RedCap UE bandwidth and therefore leads to dropped
connections.
Since RedCap UEs may only have one or two RX branches, this can have an impact
on the downlink coverage, especially in 5G frequency bands that require a 5G NR UE
with four RX antennas due to legacy issues. A highly accurate and fast receiver like
the R&S®TSMx network scanner will definitively outperform the RSRP measurements
made by a low-complexity RedCap UE and thus allow detection of network coverage
outages for RedCap services. Finally, the network may signal its permission for uplink
coverage enhancement methods in its system information when this is feasible, requir-
ing SIB decoding as supported by a network scanner. The R&S®ROMES4 drive test
software in combination with the mobile network scanner R&S®TSMx and a test UE with
the QualiPoc Android software presents a powerful toolkit for RedCap-specific network
performance verification.
In summary, mobile network testing methodologies will continue to play a pivotal role
in the verification of network performance as well as in network troubleshooting and
optimization.
58
Figure 42: The R&S®TSME mobile network test solution with an IoT device
G devices 59
9 SUMMARY
We now wish to recall the first sentence in this white paper: “With the introduction of
5G, the 3GPP standardization organization is seeking to increase the number of use cases
for wireless communications. The result is the well-known triangle of services with the
three facets eMBB, uRLLC and mMTC.” Clearly, 5G tackles a plethora of use cases and
the triangle of services is being stretched further in all directions. Higher data rates in
eMBB will be enabled by additional frequency bands in FR2-2 up to 71 GHz, wider band-
width, higher order modulation and MIMO schemes, to mention only a few aspects of
the technological evolution. The optimization of time synchronized networks (TSN), com-
bined with reliability plus latency improvements, is providing support to URLLC services.
Integration of NB-IoT and LTE-M into the 5G system will not only ensure the longevity of
those RATs, but will also support radio technologies like zero-power IoT or ambient IoT
and extend the use cases of mMTC. 5G RedCap brings IoT into the 5G realm and not only
introduces mid-tier eMTC into the 5G ecosystem, but also serves as a launch pad for new
waves of devices with optimized designs for use in applications like industrial automation,
smart cameras and wearables. By also targeting specific use cases like MCX or FRMCS
applications, RedCap will lead the way towards the proliferation of 5G and support expan-
sion into non-public applications as well. We assume that the RedCap evolution does not
represent a technology deadlock, but that RedCap will instead lead the way towards new
services. The introduction of sidelink communications has enabled direct device to device
connections. In the next evolutionary stage, RedCap devices will communicate over this
sidelink in a direct mode. With non-terrestrial networks (NTN), 5G is opening the skies
and taking flight. IoT-NTN extends IoT to become a global IoT. The initial applications here
are targeting ubiquitous connections with low data rates. However, IoT services requir-
ing higher data rates are likely on the long term. Although we can only speculate, our
assumption is that it is only a matter of time until a sort of convergence takes place here,
i.e. a RedCap UE that is capable of NTN. On the way to 6G, the next generation involves
research areas like joint communications and sensing, unified 3D networks and SIM-free
authentication methods as potential areas that will extend RedCap functionalities. We
strongly believe that RedCap's position as a mid-tier mMTC technology will continue in
6G.
Rohde & Schwarz has already added support for 5G RedCap to its R&S®CMX500 radio
communication tester. The tailored R&S®CMX500 ”OBT lite” hardware configuration
addresses lower data rate applications like RedCap for all production stages from early
R&D to type approval conformance testing. As the authors of this white paper, our goal
is to contribute to the technology evolution of 5G RedCap. Rohde & Schwarz is proud to
support this evolution with its expertise in test and measurement.
60
10 REFERENCES
[Ref. 1] 5G New Radio Fundamentals procedures, testing aspects, M. Kottkamp, A. Pandey, D. Raddino,
A. Roessler, R. Stuhlfauth, Rohde & Schwarz technology book, PW 3642.6376.00, ISBN 978-3-939837-15-2,
5th edition, 2022, https://www.rohde-schwarz.com/5G-ebook
[Ref. 2] Power saving methods for LTE-M and NB-IoT devices, Y. Shi, Rohde & Schwarz white paper,
PD 3609.3820.52, June 2019, https://www.rohde-schwarz.com/solutions/test-and-measurement/wireless-
communication/iot-m2m/whitepaper-power-saving-lte-m-nb-iot-register_251417.html
[Ref. 3] A technical look at 5G mobile device energy efficiency, Ericsson study,

https://www.ericsson.com/en/blog/2020/2/mobile-devices-and-energy-efficiency
[Ref. 4] Why IoT changes everything, Ericsson web page, https://www.ericsson.com/en/internet-of-things
[Ref. 5] Narrowband Internet of Things, Rohde & Schwarz white paper, J. Schlienz, D. Raddino, August 2016,
https://www.rohde-schwarz.com/appnote/1MA266
[Ref. 6] 5G standalone architecture, Samsung technical white paper, January 2021
[Ref. 7] Let’s talk IoT – 5G mMTC, Rohde & Schwarz technology poster and video, F. Xie, J. Koepp,
https://www.rohde-schwarz.com/solutions/test-and-measurement/wireless-communication/iot-m2m/lte-m/
lte-m-theme_234034.html#video-rs-663584
[Ref. 8] Mobile IoT in the 5G Future – NB-IoT and LTE-M in the Context of 5G, GSMA white paper, April 2018,
https://www.gsma.com/iot/resources/mobile-iot-5g-future
[Ref. 9] Connectivity Standard Alliance CSA, technical information, https://csa-iot.org/all-solutions/matter
[Ref. 10] Wireless connectivity testing, Rohde & Schwarz web page,
https://www.rohde-schwarz.com/solutions/test-and-measurement/wireless-communication/wireless-
connectivity/overview/wireless-connectivity_233828.html
[Ref. 11] Mobility Reports, Ericsson, https://www.ericsson.com/en/reports-and-papers/mobility-report/reports
[Ref. 12] Device Information Services, Global Supplier Association GSMA, https://www.gsma.com/services/tac
[Ref. 13] 3GPP Releases 16, 17 and beyond, 5G Americas white paper, January 2021
[Ref. 14] RP-201677 Study on support of reduced capability NR devices, Ericsson, 3GPP TSG RAN Meeting #89e,
September 2020
[Ref. 15] RP-220480 RAN2 CRs to Support of reduced capability NR devices, Nokia, 3GPP TSG-RAN Meeting #95,
March 2022
[Ref. 16] Over-the-air RF conformance measurements on 5G NR devices, Rohde & Schwarz white paper, H. Mellein,
R. Stuhlfauth, March 2021, https://www.rohde-schwarz.com/solutions/test-and-measurement/wireless-
communication/cellular-standards/5g-test-and-measurement/massive-mimo/white-paper-over-the-air-rf-
conformance-measurements-registration_254676.html
[Ref. 17] RP-213661 Study on further NR RedCap UE complexity reduction, Ericsson, 3GPP TSG RAN meeting #94e,
December 2021
G devices 61
[Ref. 18] An Overview of 5G Advanced Evolution in 3GPP Release 18, IEEE communications standard magazine,
Ericsson, X. Lin, September 2022, https://ieeexplore.ieee.org/document/9927255
[Ref. 19] Enabling Next-Generation Public Safety Operations with Mission-Critical Networks and Wearable
Applications, MPDI sensors magazine, S. Safi, J. Hosek, A. Kolackova, August 2021,
https://pdfs.semanticscholar.org/88a6/c63280576167fd1fac444863b859f5d44c10.pdf
[Ref. 20] Future Railway Mobile Communications System FRMCS, https://uicfrmcs.org/?lang=en
[Ref. 21] Positioning in 5G NR: A look at the technology and related test aspects, Rohde & Schwarz white paper,
R. Stuhlfauth, January 2022, https://www.rohde-schwarz.com/solutions/test-and-measurement/wireless-
communication/cellular-standards/5g-test-and-measurement/5g-nr-whitepaper_255392.html
[Ref. 22] Internet of Things, Nokia web page and technology information,
https://www.nokia.com/networks/internet-of-things/
[Ref. 23] R2-2108729 Early indication & access restriction for RedCap UEs, Ericsson, 3GPP TSG-RAN WG2 #115-e,
August 2021
[Ref. 24] 5G network slicing – all you need to know, Rohde & Schwarz webinar, L. Walther, January 2023,
https://www.rohde-schwarz.com/knowledge-center/webinars/webinar-5g-network-slicing-all-you-need-to-
know_256237.html
[Ref. 25] 5G RedCap: RF Implications for IoT Devices, Qorvo white paper, August 2022
[Ref. 26] 5G NTN takes flight, Rohde & Schwarz white paper, R. Stuhlfauth, June 2022,
https://www.rohde-schwarz.com/solutions/test-and-measurement/aerospace-defense/satellite-test/white-
paper-5g-ntn-takes-flight-technical-overview-of-5g-non-terrestrial-networks_255919.html
[Ref. 27] 5G NR-V2X for enhanced automotive communications, Rohde & Schwarz white paper, R. Stuhlfauth,
May 2022, https://www.rohde-schwarz.com/solutions/test-and-measurement/automotive/automotive-
connectivity-and-infotainment/white-paper-5g-nr-v2x-for-enhanced-automotive-communications-
registration_255741.html
[Ref. 28] Global Mobile Suppliers Association web page and market statistics, https://gsacom.com/
[Ref. 29] Rethink 5G testing, Rohde & Schwarz webinar, G. Talaganov, T. Seyler, November 2022, https://www.rohde-
schwarz.com/knowledge-center/webinars/webinar-rethink-5g-testing-vd_256115.html#media-gallery-4
[Ref. 30] IoT power consumption testing, Rohde & Schwarz web page and videos,
https://www.rohde-schwarz.com/solutions/test-and-measurement/wireless-communication/iot-m2m/iot-
power-consumption-testing/iot-power-consumption-testing-theme_233864.html
[Ref. 31] ETSI ES 202 706-1, Environmental Energy; Metrics and measurement method for energy efficiency of
wireless access network equipment, October 2016
[Ref. 32] Location-Based Services in Cellular Networks from GSM to 5G NR, A. Cardalda Garcia, S. Maier, A. Philips,
Artech House Publishers, ISBN: 978-1-63081-634-6, 2020
62
11 3GPP SPECIFICATIONS
TR 23.724 Study on Cellular Internet of Things (CIoT) support and evolution for the 5G System (5GS), Rel. 16,
June 2019
TR 38.859 Study on expanded and improved NR positioning; Rel. 18, December 2022
TR 38.875 Study on support of reduced capability NR devices, Rel. 17, March 2021
TR 38.840 NR; Study on User Equipment (UE) power saving in NR, Rel. 16, June 2019
TR 38.830 Study on NR coverage enhancements, Rel. 17, December 2020
TR 38.864 Study on network energy savings for NR, Rel. 18, December 2022
TS 23.501 System architecture for the 5G System (5GS); Stage 2; Rel. 17, December 2021
TS 24.501 Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3, Rel. 17, September 2022
TS 37.340 Evolved Universal Terrestrial Radio Access (EUTRA) and NR; Multi-connectivity; Stage 2, Rel. 16,
August 2019
TS 38.101-1 NR; User Equipment (UE) radio transmission and reception; Part 1: Range 1 Standalone, Rel. 17,
December 2022
TS 38.101-2 NR; User Equipment (UE) radio transmission and reception; Part 2: Range 2 Standalone, Rel. 17,
December 2022
TS 38.133 NR; Requirements for support of radio resource management, Rel. 17, September 2022
TS 38.213 NR; Physical layer procedures for control, Rel. 17, September 2022
TS 38.214 NR; Physical layer procedures for data, Rel. 17, September 2022
TS 38.300 NR; NR and NG-RAN Overall Description; Stage 2; Rel. 17, December 2022
TS 38.304 NR; User Equipment (UE) procedures in Idle mode and RRC Inactive state, Rel. 17, September 2022
TS 38.306 NR; User Equipment (UE) radio access capabilities, Rel. 17, June 2022
TS 38.321 NR; Medium Access Control (MAC) protocol specification, Rel. 17, September 2022
TS 38.331 NR; Radio Resource Control (RRC) protocol specification, Rel. 17, September 2022
TS 38.410 NG-RAN; NG general aspects and principles, Rel. 17, June 2022
G devices 63
TS 38.521-1 User Equipment (UE) conformance specification; Radio transmission and reception;
Part 1: Range 1 Standalone; Rel. 17, December 2022
Part 1: Range 2 Standalone; Rel. 17, December 2022
Part 4: Performance requirements, Rel. 17, December 2022
TS 38.523-1 User Equipment (UE) conformance specification; Part 1: Protocol, Rel. 17, December 2022
64
12 ABBREVIATIONS
Term Explanation
3GPP 3rd generation partnership program
5GC 5G core network
5GMM 5G mobility management
AF Application function
AGC Adaptive gain control
AI Artificial intelligence
AM Acknowledged mode
AMF Access and mobility management function
AR Augmented reality
ASM Advanced sleep mode
BER Bit error rate
BLER Block error rate
BSR Buffer status report
BWP Bandwidth part
CA Carrier aggregation
CE Control element
CE Coverage extension
CCTV Closed-circuit television
CIoT Cellular IoT
CL Clutter loss
CORESET Control and resource set
CP Control plane
CPC Conditional PSCell change
CPE Customized premises equipment
CQI Channel quality indicator
CRC Cyclic redundancy check
CSI Channel status information
CSI-RS CSI reference signal
CU Centralized unit
DAPS Dual active protocol stack
DC Dual connectivity
DCI Downlink control information
DFT Discrete Fourier transformation
DL Downlink
DRB Data radio bearer
DRX Discontinuous reception
DTX Discontinuous transmission
DU Distributed unit
E2E End to end
eMBB enhanced mobile broadband
EMC Electromagnetic compatibility
eNB evolved NodeB (LTE base station)
EN-DC EUTRA and NR dual connectivity
EPS Evolved packet core (LTE core network)
EUTRA Evolved UMTS terrestrial radio (LTE air interface)
EUTRAN Evolved UMTS terrestrial radio access network
EVM Error vector magnitude
FCC Federal Communications Commission (US regulator)
FDD Frequency division duplex
FR Frequency range
FRMCS Future railway mobile communications system
FSPL Free space path loss
G devices 65
Term Explanation
FWA Fixed wireless access
gNB Next generation NodeB (5G base station)
GNSS Global navigation satellite services
GSCN Global synchronization channel number
GSM Global System for Mobile Communications (2nd generation)
GSMA Global Supplier Association
HARQ Hybrid automatic repeat request
HPA High power amplifier
HPHT High-power high-tower
HSDN High speed data network
HTS High throughput satellite
IAB Integrated access backhaul
IE Information element
IFRI Intra-frequency cell reselection indicator
IMSI International mobile subscriber identity
IMT International mobile telecommunications
IoT Internet of things
IIoT Industrial IoT
ITU International Telecommunication Union
KPI Key performance indicator
LBS Location based services
LCID Logical channel identifier
LNA Low noise amplifier
LOS Line of sight
LPHAP Low power high accuracy positioning
LTE Long Term Evolution (4th generation)
LTE-M Long Term Evolution machine type communications
MAC Medium access control
MCG Master cell group
MCS Modulation and coding scheme
MCX Mission critical communications
MEC Multi-access edge computing
MIB Master information block
MICO Mobile initiated connection only
MIMO Multiple input multiple output
ML Machine learning
mMTC Massive machine type communications
MNO Mobile network operator
MOCN Multi-operator core network
MOS Mean opinion score
MPP Multipath propagation
MPR Maximum power reduction
MTC Machine type communications
NACC Network assisted cell change
NAS Non-access stratum
NB-IoT Narrowband internet of things
NGSO Non-geostationary satellite orbits
NF Noise figure
NFV Network function virtualization
NLOS Non line of sight
NodeB Term for base station
NPN Non public network
NR New Radio
NR-ARFCN New Radio absolute radio frequency channel number
66
Term Explanation
NSA Non-standalone
NTN Non-terrestrial networks
OFDMA Orthogonal frequency division multiple access
OTA Over-the-air
PAPR Peak to average power ratio
PC Power class
PC5 Direct UE to UE interface for automotive
PCell Primary cell in CA/DC mode
PCF Policy control function
PCI Physical cell identity
PDCCH Physical downlink control channel
PDCP Packet data convergence protocol
PDN Packet data network
PDSCH Physical downlink shared channel
PDU Protocol data unit
PEI Paging early indication
PF Paging frame
PH Power headroom
PL Path loss
PLMN Public land mobile network
PO Paging occasion
PPDR Public protection and disaster relief
PRACH Physical random access channel
PRB Physical resource block
PRS Positioning reference signal
PSM Power save mode
PTCRB PCS Type Certification Review Board
PTRS Phase tracking reference signal
PTW Paging time window
PUCCH Physical uplink control channel
PUR Preconfigured uplink resource
PUSCH Physical uplink shared channel
QAM Quadrature amplitude modulation
QoS Quality of service
QoE Quality of experience
RAC Registration area code
RACH Random access channel
RAR Random access response
RAT Radio access technology
RAN Radio access network
RedCap Reduced capability
RF Radio frequency
RLC Radio link control
RNTI Radio network transaction identity
RRC Radio resource control
RRM Radio resource management
RSRP Reference signal received power
RSRQ Reference signal received quality
RSSI Received signal strength indicator
RTT Round-trip time
RX Reception
SA Standalone
SBA Service based architecture
SDAP Service data adaptation protocol
G devices 67
Term Explanation
SDO Standard developing organization
SDT Small data transmission
SCell Secondary cell in CA/DC mode
SCG Secondary cell group
SCS Subcarrier spacing
SF Shadow fading
SFN System frame number
SIB System information block
SINR Signal to interferer noise ratio
SMF Session management function
SMTC SSB based measurement timing configuration
SMO Service, maintenance and orchestration
SN Sequence number
SR Scheduling request
SRS Sounding reference signal
SSB Synchronization signal and PBCH block
SSSG Search space switching group
SU-MIMO Single user MIMO
TA Tracking area
TA Timing advance
TAC Tracking area code
TAI Tracking area index
TAU Tracking area update
TCI Transmission configuration indication
TDD Time division duplex
TM Transparent mode
TMSI Temporary mobile subscriber identity
TRP Transmission and reception point
TRP Total radiated power
TRS Tracking reference signal
TTI Transmit time interval
TX Transmission
UAS Unmanned aerial system
UAV Unmanned aerial vehicle
UE User equipment
UL Uplink
UM Unacknowledged mode
UMTS Universal Mobile Telecommunications System (3rd generation)
UP User plane
UPF User plane function
URLLC Ultra-reliable low latency communications
USIM UMTS subscriber identity module
UWB Ultra-wideband IEEE 802.15.4
V2X Vehicle to everything
VR Virtual reality
WLAN Wireless local area network
WUS Wake-up signal
XR Extended reality
68
G devices 69
70
G devices 71
Rohde & Schwarz
The Rohde & Schwarz technology group is among the trail-
blazers when it comes to paving the way for a safer and
connected world with its leading solutions in test & measure-
ment, technology systems and n etworks & cybersecurity.
Founded more than 85 years ago, the group is a reliable
partner for industry and government customers around
the globe. The independent company is headquartered in
Munich, Germany and has an extensive sales and service
network with locations in more than 70 countries.
www.rohde-schwarz.com
Rohde & Schwarz customer support

www.rohde-schwarz.com/support
3683975752
R&S® is a registered trademark of Rohde & Schwarz GmbH & Co. KG

3683.9757.52 01.00 PDP/PDW 1 en
Trade names are trademarks of the owners

PD 3683.9757.52 | Version 01.00 | April 2023 (ch) | White Paper
Reduced capabilities (RedCap) – a new class of 5
G devices
Data without tolerance limits is not binding | Subject to change
© 2023 Rohde & Schwarz GmbH & Co. KG | 81671 Munich, Germany

RedCap_wp_en_3683-9757-52_v0100

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RedCap_wp_en_3683-9757-52_v0100

Uploaded by

Copyright:

Available Formats

REDUCED CAPABILITIES (REDCAP) –

A NEW CLASS OF ­5G ­DEVICES

White Paper | Version 01.00 | Reiner Stuhlfauth and Lothar Walther

2 Reduced capabilities overview (Rel. 17).....................................................................................................12

3 RedCap-related bandwidth part aspects.....................................................................................................17

4 RedCap information signaling and network access restrictions...............................................................19

5 RRM measurement relaxation.....................................................................................................................27

6 Power saving features and technologies....................................................................................................29

8 RedCap-related T&M aspects .....................................................................................................................46

1.1 Cellular IoT – new services with new requirements

Figure 1: IoT classification within 5G

eMBB Broadband IoT

Industrial IoT (IIoT),

Reduced capability (RedCap) devices,

1.2 RedCap supporting the evolution of user equipment

Figure 3: Initial RedCap use cases and UE types

motion, pressure, temperature,

2 Mbps to 4 Mbps for

Figure 4: 5G RedCap positioning in the data rate constellation – motivational aspects

uRLLC Critical applications

5G RedCap Smart IoT

Low complexity and

1.5 Power saving aspects related to RedCap

Figure 6: Power saving technology cluster

Hardware restrictions and reduced capabilities

Enhanced mechanisms and innovations Operational enhancements

Bandwidth reduction: A device claiming to be a RedCap UE in FR1 supports a maximum

Number of UE RX antennas: A RedCap UE can support either one or two RX antennas

Figure 7: Half-duplex operation and conflict solving rules

Half-duplex operation FDD UL TX TX TX

Future railway mobile communications system (FRMCS): To enable communications between

Reminder: The BWP is conﬁgured via SIB, e.g. “BWP-DownlinkCommon“.

TS 38.213 about RedCap UE:

After UE is in connected state, the network may conﬁgure

4.1 RedCap-related UE identification

Random access preamble (Msg1)

UE can indicate in Msg1 (MsgA) Contention resolution (Msg4)

Feature priority signaling via SIB1 affecting Msg1 RedCap indication

RedCap indication in RRCSetupRequest (Msg3)

4.2 RedCap-specific cell barring signaling in SIB1

Reminder: 5G NR deﬁnes two mechanisms to

e.g. cellBarred e.g. UAC-BarringInfoSetList

Half-duplex UE permission: Operation in half-duplex mode impacts the scheduling algorithm

Figure 13: RedCap UE capability related cell access restrictions

Network can restrict access on cell level! Speciﬁc for

Summarizing the RedCap-related UE capability access restrictions, note that these

Intra-frequency cell reselection indicator (IFRI) related to RedCap

Figure 14: Cell access barring and cell reselection signaling

Intra-frequency cell reselection is a two-step

Figure 15: Cell access barring and cell reselection signaling

Intra-frequency cell reselection is a two-step

RedCap UE reads SIB1.

RedCap-speciﬁc cell access restrictions (1 or 2 RX UE)

These priorities are used to determine which FeatureCombinationPreambles the UE should

Reduced capability UE may be permitted to indicate RedCap in Msg1 transmission already.

The network may conﬁgure a PRACH resource for RedCap indication

Radio frame … SFN #1 … SFN #5 … SFN #9 … SFN #1017 … SFN #1021

Preamble format B1 CP SEQ SEQ GP

Figure 17: RRM measurement relaxation

To reduce complexity and energy consumption, the network

Relaxed measurement rules for intra-frequency,

Relaxed measurement criterion for stationary RedCap UE (RRC connected):

(SrxlevRefStationary – Srxlev) < SSearchDeltaP-Stationary

6.2.1 Discontinuous reception (DRX)

A NEW CLASS OF 5G DEVICES