BFD

Beam Failure Detection

Radio Access Network →
Introduced in Rel-15

BFD is a mechanism in 5G NR that monitors beam quality to detect when a serving beam becomes unreliable, triggering recovery procedures to maintain connectivity.

Category
Radio Access Network
Introduced
Rel-15
Where
Radio Access Network › NG-RAN (5G)
Specifications
9 specs
BFD Description Purpose Detected Changes Specifications

Description

Beam Failure Detection (BFD) is a fundamental physical layer procedure in 5G New Radio (NR) that enables User Equipment (UE) to monitor the quality of its serving beam and detect when that beam becomes unreliable or fails. The mechanism operates by continuously evaluating the hypothetical Block Error Rate (BLER) of the Physical Downlink Control Channel (PDCCH) transmissions received on specific reference signals. The UE configures a beam failure detection reference signal (BFD-RS) resource set, typically consisting of Synchronization Signal Blocks (SSBs) or Channel State Information Reference Signals (CSI-RS), which represent the serving beam's quality. The UE measures the received signal quality (e.g., using Layer 1 Reference Signal Received Power (L1-RSRP)) on these BFD-RS resources and compares it against a configured threshold (Q_out). A beam failure instance is declared when the measured quality falls below this threshold. The UE maintains a beam failure detection counter that increments with each failure instance and resets upon a successful measurement above the threshold. When this counter reaches a configured maximum value (beamFailureDetectionTimer), a beam failure is declared, triggering the Beam Failure Recovery (BFR) procedure.

The BFD architecture involves coordination between the UE's physical layer (Layer 1) and higher layers (MAC and RRC). The gNB configures BFD parameters via RRC signaling, including the BFD-RS resource set, Q_out threshold, beamFailureDetectionTimer, and beamFailureInstanceMaxCount. The physical layer performs continuous measurements and reports beam failure instances to MAC, which manages the counter and timer. When beam failure is declared, MAC initiates the BFR procedure by triggering Random Access Channel (RACH) transmission on a candidate beam identified during the detection phase. The UE monitors candidate beam identification reference signals (CBI-RS) during BFD to identify alternative beams with sufficient quality, preparing for swift recovery.

BFD operates in conjunction with other beam management procedures like beam measurement, beam reporting, and beam switching. It's particularly crucial for Frequency Range 2 (FR2) operations above 24 GHz, where narrow beamforming is necessary to overcome severe propagation challenges. The detection mechanism must balance sensitivity (to detect actual failures quickly) with stability (to avoid false triggers from temporary fading). BFD parameters are typically configured based on deployment scenarios, mobility patterns, and service requirements. The procedure supports both connected mode (RRC_CONNECTED) and inactive mode (RRC_INACTIVE) operations, with different parameter sets possible for various bandwidth parts (BWPs) and component carriers.

The technical implementation involves specific physical layer processing where the UE evaluates the hypothetical PDCCH BLER based on BFD-RS measurements. This is calculated using established relationships between reference signal quality and control channel performance. The 3GPP specifications define detailed requirements for BFD accuracy and timeliness, including maximum detection times and false alarm probabilities. BFD works alongside Radio Link Monitoring (RLM) but serves a different purpose: while RLM monitors overall radio link failure at the cell level, BFD specifically addresses beam-level failures within a cell. This distinction is vital in multi-beam deployments where individual beams can fail while others remain viable, allowing for recovery without full radio link failure declaration.

Purpose & Motivation

BFD was created to address the fundamental challenges of millimeter wave (mmWave) communications in 5G NR, where directional beamforming is essential due to high path loss and atmospheric absorption. In traditional sub-6 GHz systems, omnidirectional or wide-beam transmissions could maintain connectivity even with signal degradation, but mmWave systems rely on narrow, high-gain beams that can be easily blocked by obstacles, human bodies, or environmental changes. Without rapid beam failure detection, mmWave connections would experience frequent drops, making them unreliable for mission-critical applications. BFD enables the system to quickly identify when a serving beam becomes unusable and trigger recovery procedures before the connection is completely lost.

The technology addresses limitations of previous cellular systems that lacked sophisticated beam management. In LTE and earlier technologies, beamforming was primarily used for capacity enhancement rather than basic connectivity maintenance. These systems used Radio Link Failure (RLF) procedures that operated at the cell level with relatively slow detection times (hundreds of milliseconds to seconds). For mmWave with its rapid channel variations, such slow detection would result in unacceptable service interruptions. BFD provides beam-level granularity with detection times on the order of tens of milliseconds, enabling swift beam switching that maintains seamless connectivity.

Historical context shows that beam management concepts evolved through 3GPP releases, with Rel-15 introducing basic BFD for initial 5G deployments, and subsequent releases enhancing it for more complex scenarios. The creation of BFD was motivated by the need to make mmWave practical for mobile communications, where user mobility and environmental dynamics cause frequent beam misalignment. By detecting beam failures early and triggering appropriate recovery actions, BFD enables the reliability necessary for 5G's promised use cases like enhanced mobile broadband, ultra-reliable low-latency communications, and industrial IoT applications in challenging radio environments.

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (54 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 16 changes

In Release 15, the Beam Failure Detection (BFD) function was newly introduced as part of beam management, failure detection and recovery procedures. Specifically, the release clarified SSB-based BFD and defined that a UE, if configured by the network, can perform beam failure detection on the SCG even while the SCG is deactivated. Furthermore, the specifications detailed BFD relaxation, where the network may configure a good serving cell criterion for BFD in the NR PSCell and/or SCell(s) for EN-DC, NGEN-DC, and NR-DC deployments.

  • Correction on SN configured NR measurements after SCG failure TS 37.340CR0025
  • RAN paging failure handling in SN TS 37.340CR0136
  • Correction on sending Failure Information via SRB3 TS 37.340CR0159
  • Beam management, failure detection and recovery TS 38.300CR0070
  • Clarification on SSB-based BM, RLM and BFD TS 38.300CR0102
  • Correction to beam failure detection in Stage-2 TS 38.300CR0103

+ 10 more changes

Rel-16 13 changes

In Release 16, the BFD (Beam Failure Detection) function was enhanced to allow its operation on a deactivated SCell, as indicated by the correction on BFD resource on SCell. Furthermore, new relaxation criteria for BFD were introduced, allowing the network to configure a "good serving cell criterion" in the PSCell and SCells for EN-DC, NGEN-DC, and NR-DC deployments. These changes enabled more efficient beam management and failure recovery in multi-connectivity scenarios.

  • Corrections on SCG/MCG failure handling TS 37.340CR0288
  • Clarification on RLF detection of source PCell TS 38.300CR0368
  • Corrections to failure type for MCGFailureInformation and SCGFailureInformation TS 38.331CR1737
  • CR on UE behavior with E-UTRA cell selection upon mobility from NR failure for enhanced EPS voice fallback TS 38.331CR1969
  • Adding notes for joint success and failure in crossRAT SL TS 38.331CR1995
  • Correction to NR-U Energy Detection Threshold configuration TS 38.331CR2042

+ 7 more changes

Rel-17 12 changes

In Release 17, key enhancements for Beam Failure Detection (BFD) included the introduction of relaxation procedures for BFD when two BFD-RS sets are configured. Furthermore, the release specified configurations for BFD relaxation reporting and clarified that BFD can be performed on the SCG even while it is in a deactivated state, provided the network configures it. These changes provided more robust and efficient beam failure management in multi-connectivity scenarios.

  • Correction on MRO for SN Change Failure TS 37.340CR0330
  • Failure handling for SCG MRO TS 37.340CR0356
  • Clarification on BFD-RS set based BFR TS 38.300CR0596
  • CR on 38.331 for BFD relxation when two BFD-RS sets are configured TS 38.331CR3709
  • RLM and BFD relaxation reporting configurations are missed in the field description of otherConfig while being configured for SCG TS 38.331CR3741
  • Clarification on BFD-RS configuration TS 38.331CR3938

+ 6 more changes

Rel-18 8 changes

In Release 18, the Beam Failure Detection (BFD) function was extended to support the new RA-SDT (Random Access - Small Data Transmission) procedure. Furthermore, enhancements were made to allow BFD relaxation to be configured based on a good serving cell criterion, applicable to the PSCell and SCells in various dual-connectivity scenarios. The release also clarified the interaction between RLM/BFD relaxation and the short DRX (Discontinuous Reception) cycle.

  • Introduction of Beam Failure for RA-SDT [RA-SDT_BeamFailure] TS 38.331CR4551
  • Addition of CPAC detection in stage 2 TS 37.340CR0396
  • Correction on CPA failure states and detection mechanism in stage 2 TS 37.340CR0400
  • Correction on conditional PSCell addition or change failure TS 37.340CR0407
  • Stage 2 correction on DL LBT failure information TS 38.300CR0971
  • Correction on handover failure due to unavailable candidate relay UE TS 38.300CR0972

+ 2 more changes

Rel-19 5 changes

In Release 19, the enhancements for Beam Failure Detection (BFD) specifically introduced updated test applicability and a new test case for a UE operating on a PCell with a 3 MHz bandwidth. This ensured that BFD and Link Recovery procedures were validated for operation in this narrower bandwidth scenario. Furthermore, the release clarified that BFD relaxation configurations, including the good serving cell criterion, can be applied in the NR PCell and/or SCell(s) for NE-DC/NR-DC deployments.

  • Recovery of N3mb path failure for unicast transport of multicast session TS 38.300CR1032
  • Addition of test applicability statement for BFD and LR test case for a UE operating on a PCell with 3 MHz BW TS 38.522CR0635
  • Updation of test applicability for Beam Failure detection and link recovery test case for a UE operating on a PCell with 3 MHz BW TS 38.522CR0669
  • Correction on setting timeSinceCHO-Reconfig when the failure is due to RLF TS 38.331CR5557
  • Correction on measurement results in indirect path failure information TS 38.331CR5612

Explore further

Broader topics and technologies where BFD plays a role.

Defining Specifications

3GPP specifications that define or reference BFD, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 37.340 vj00 Multi-Connectivity Operation Overview Rel-19
TS 37.816 vg00 RAN-centric Data Collection & Utilization Study Rel-16
TS 38.106 vj20 NR Repeater Radio Transmission and Reception Rel-19
TS 38.133 vj20 5G UE Radio Requirements for RRC_IDLE Mobility Rel-19
TS 38.174 vj10 NR Integrated Access and Backhaul Radio Spec Rel-19
TS 38.176 vj20 IAB Conformance Testing Specification Rel-19
TS 38.300 vj00 NG-RAN Overall Description Rel-19
TS 38.331 vj00 NR Radio Resource Control (RRC) Protocol Specification Rel-19
TS 38.522 vj11 UE Conformance Test Applicability Statement Rel-19