Description
Candidate Beam Detection (CBD) is a foundational beam management mechanism defined within the 5G New Radio (NR) framework, specifically for operation in Frequency Range 2 (FR2), which includes millimeter wave (mmWave) bands. Its primary function is to proactively identify alternative, high-quality beam pairs that can serve as backups if the currently active serving beam fails or degrades significantly. This procedure is executed by the User Equipment (UE) under the configuration and control of the gNodeB (gNB). The gNB configures the UE with a set of resources (e.g., specific Synchronization Signal Blocks (SSBs) or Channel State Information Reference Signals (CSI-RS)) corresponding to candidate beams. The UE then continuously or periodically measures the signal quality (e.g., Reference Signal Received Power (RSRP)) of these configured candidate beams while maintaining its primary connection on the serving beam.
The architectural implementation of CBD is integrated into the broader Layer 1 (physical layer) and Layer 2 (MAC layer) procedures. The gNB sends configuration parameters via Radio Resource Control (RRC) signaling, specifying the resources for candidate beam measurement, reporting criteria (thresholds), and reporting formats. The UE's physical layer performs the measurements, and upon meeting predefined conditions—such as a candidate beam's RSRP exceeding the serving beam's RSRP by a certain offset or the serving beam's quality falling below an absolute threshold—the UE triggers a measurement report. This report is sent via uplink control information (e.g., on the PUCCH or PUSCH) and contains identifiers (e.g., SSB Resource Indicator (SSBRI) or CSI-RS Resource Indicator (CRI)) and the measured quality of the candidate beams.
The role of CBD within the network is critical for mobility and robustness. It feeds essential information to the gNB's beam management algorithms, enabling decisions for beam refinement, beam switching (within a cell), or inter-cell beam handover. By maintaining an up-to-date list of viable alternative beams, the network can execute beam recovery procedures with minimal latency, often without needing to fall back to slower, cell-level radio link failure (RLF) detection and re-establishment processes. This is particularly vital for supporting ultra-reliable low-latency communication (URLLC) services and for maintaining consistent throughput in dynamic mmWave environments where obstacles can abruptly block the line-of-sight path of a narrow beam.
Key components involved in the CBD procedure include the configured reference signals (SSBs for initial access and idle/inactive mode, CSI-RS for connected mode), the measurement and filtering mechanisms within the UE's receiver, the reporting triggers and criteria, and the gNB's algorithms for interpreting reports and initiating beam management commands. The procedure operates in conjunction with other beam management functions like beam measurement, beam determination (at the gNB), and beam reporting, forming a closed-loop control system for maintaining optimal beam alignment.
Purpose & Motivation
Candidate Beam Detection was created to address the fundamental challenges introduced by the use of high-frequency mmWave spectrum in 5G NR. While mmWave bands offer vast bandwidth for multi-gigabit data rates, they suffer from severe propagation characteristics, including high path loss and sensitivity to blockages (e.g., by buildings, vehicles, or even a user's hand). To overcome these losses, 5G employs beamforming with highly directional antennas, creating narrow pencil beams. However, this very solution creates a new problem: the link on a narrow beam is fragile and can be broken instantly by a moving obstacle.
Previous cellular systems (3G, 4G) operating at lower frequencies used wider, sector-level beams. Mobility management and handovers were primarily based on cell-level measurements. The sudden failure of a single beam was not a common failure mode. In early 5G designs, relying solely on radio link failure (RLF) detection and re-connection was deemed insufficient for mmWave. The RLF process involves detecting failure, breaking the connection, searching for a new cell, and performing random access—a sequence that introduces significant latency (hundreds of milliseconds) and service interruption, unacceptable for mission-critical and high-throughput applications.
Therefore, the purpose of CBD is to enable proactive and fast beam-level mobility. It solves the problem of beam fragility by allowing the UE and network to always be aware of alternative beam paths before the primary one fails. This shifts the paradigm from reactive failure recovery to proactive link maintenance. The motivation was to ensure that the theoretical advantages of mmWave—high speed and capacity—could be realized in practical, mobile deployment scenarios with the necessary reliability and quality of service. CBD is a key enabler for the 5G vision of seamless connectivity in high-frequency bands.
Key Features
- Proactive identification of backup beam pairs before active beam failure
- Configuration-based measurement of SSB or CSI-RS resources for candidate beams
- Event-triggered reporting based on serving beam quality and candidate beam offset thresholds
- Enables fast beam switching and recovery, minimizing service interruption latency
- Integral part of the beam management framework for mmWave (FR2) operation
- Supports both intra-cell beam refinement and inter-cell beam-level handover preparation
Evolution Across Releases
Introduced the foundational Candidate Beam Detection framework as part of the initial 5G NR specification for mmWave. Defined the basic procedures for gNB configuration of candidate beam resources (SSBs), UE measurement and reporting criteria (e.g., events B1, B2 for beam measurement), and reporting mechanisms via L1/L2 signaling. Established CBD as essential for beam failure recovery (BFR) procedures, enabling rapid recovery from beam failure without full RLF.
Defining Specifications
| Specification | Title |
|---|---|
| TS 38.106 | 3GPP TR 38.106 |
| TS 38.133 | 3GPP TR 38.133 |
| TS 38.174 | 3GPP TR 38.174 |
| TS 38.176 | 3GPP TR 38.176 |