5G NR波束失败恢复（BFR）全流程拆解：从BFD检测到候选波束选择的完整信令链

一、BFR机制定位与设计动机

在5G NR毫米波（FR2）频段中，gNB与UE之间通过窄波束（Narrow Beam）进行数据传输。与Sub-6GHz的宽覆盖不同，毫米波波束宽度通常在10°~30°之间，这使得链路对UE移动、旋转、人体遮挡、雨衰等环境因素极其敏感。当服务波束质量急剧恶化时，传统的无线链路失败（RLF）检测需要等待T310定时器超时（通常数百毫秒到秒级），远不能满足毫米波场景下对快速恢复的要求。

3GPP为此设计了波束失败恢复（Beam Failure Recovery, BFR）机制，定义于TS 38.321 Section 5.17（MAC层规程）和TS 38.213 Section 6（物理层规程）。BFR是一个L1/L2层的快速恢复过程，在完整RRC连接仍存在的情况下，通过MAC层控制信令和随机接入过程完成波束切换，典型恢复时间在10~40ms量级，比RLF触发的RRC重建快一个数量级。

BFR机制的设计哲学可以概括为三层递进：

┌─────────────────────────────────────────────────┐
│              BFR 三层递进设计                     │
├─────────────────────────────────────────────────┤
│ Layer 1: BFD — 波束质量持续监测                  │
│          物理层假设PDCCH BLER超阈值 → 产生BFI    │
├─────────────────────────────────────────────────┤
│ Layer 2: 新波束识别 — 候选波束L1-RSRP评估        │
│          从candidateBeamRSList中选择满足Qin的波束 │
├─────────────────────────────────────────────────┤
│ Layer 3: BFRQ — 无竞争/竞争随机接入恢复           │
│          CFRA专用前导码或CBRA向gNB指示新波束      │
└─────────────────────────────────────────────────┘

二、完整BFR信令时序图

以下是基于TS 38.321 Section 5.17和TS 38.213 Section 6的完整BFR信令流程：

sequenceDiagram
    participant UE_PHY as UE PHY层
    participant UE_MAC as UE MAC层
    participant UE_RRC as UE RRC层
    participant gNB as gNB

    Note over UE_RRC,gNB: 步骤0: RRC配置阶段
    UE_RRC->>UE_MAC: RRC Reconfiguration<br/>BeamFailureRecoveryConfig
    Note right of UE_MAC: 配置参数:<br/>candidateBeamRSList<br/>rsrp-ThresholdSSB<br/>beamFailureInstanceMaxCount<br/>beamFailureRecoveryTimer<br/>recoverySearchSpaceId

    Note over UE_PHY,gNB: 步骤1: 波束失败检测(BFD)
    loop 每个BFD-RS周期
        gNB->>UE_PHY: SSB/CSI-RS (BFD参考信号)
        UE_PHY->>UE_PHY: 评估假设PDCCH BLER
        alt BLER > Qout阈值 (10%)
            UE_PHY->>UE_MAC: BFI (Beam Failure Instance)<br/>L1指示
            UE_MAC->>UE_MAC: BFI_COUNTER++
        else BLER ≤ Qout
            UE_PHY->>UE_MAC: 无BFI指示
            UE_MAC->>UE_MAC: BFI_COUNTER = 0
        end
    end

    Note over UE_MAC: 步骤2: 波束失败声明
    alt BFI_COUNTER ≥ beamFailureInstanceMaxCount
        UE_MAC->>UE_MAC: 声明Beam Failure
        UE_MAC->>UE_MAC: 启动beamFailureRecoveryTimer<br/>启动BFRQ传输
    end

    Note over UE_PHY,gNB: 步骤3: 新波束识别
    loop 遍历candidateBeamRSList
        UE_PHY->>UE_PHY: 测量候选SSB/CSI-RS的L1-RSRP
        alt L1-RSRP ≥ rsrp-ThresholdSSB (Qin)
            UE_MAC->>UE_MAC: 选择该候选波束
            UE_MAC->>UE_MAC: 确定RA_TYPE (CFRA/CBRA)
        else L1-RSRP < Qin
            UE_PHY->>UE_PHY: 跳过该候选波束
        end
    end

    Note over UE_MAC,gNB: 步骤4: BFRQ发送 (CFRA路径)
    alt CFRA资源配置存在
        UE_MAC->>gNB: PRACH Preamble (专用)<br/>ra-PreambleIndex关联候选波束
        Note right of gNB: gNB从preamble识别<br/>UE选择了哪个新波束
        gNB->>UE_MAC: PDCCH (C-RNTI)<br/>在recoverySearchSpaceId中
        UE_MAC->>UE_MAC: BFR成功<br/>停止timer
    else CFRA资源不存在 → CBRA
        UE_MAC->>gNB: PRACH Preamble (竞争)
        gNB->>UE_MAC: Random Access Response
        UE_MAC->>gNB: Msg3 (含C-RNTI MAC CE)
        gNB->>UE_MAC: Msg4 (竞争解决)
        UE_MAC->>UE_MAC: BFR成功
    end

    Note over UE_MAC: 步骤5: 失败处理
    alt beamFailureRecoveryTimer超时
        UE_MAC->>UE_MAC: BFR失败
        UE_MAC->>UE_RRC: 触发RLF或RRC重建
    end

三、波束失败检测（BFD）——物理层阈值与计数器机制

3.1 BFD参考信号配置

BFD的监测对象由RRC参数radioLinkMonitoringRS（TS 38.331）配置，支持两种参考信号：

在FR2高频段场景中，gNB通常通过波束扫描发送多个SSB，每个SSB对应一个空间方向。UE根据RRC配置对特定SSB索引（对应服务波束方向）进行BFD监测。Rel-16引入了BFD-RS集合（BFD-RS Set）概念，允许UE对一组参考信号进行联合监测。

3.2 Qout阈值——假设PDCCH BLER判定

BFD的核心判据不是简单的RSRP门限，而是一个假设PDCCH BLER判定（TS 38.213 Section 6.1）。其物理含义是：

如果当前波束质量恶化到在CORESET#0（或配置的CORESET）上以当前聚合等级（AL）接收PDCCH，假设的BLER超过10%（Qout阈值），则物理层产生一次BFI。

这一设计的精妙之处在于：BFD直接关联控制信道解码可靠性而非单纯的信号强度。即使RSRP尚可，如果波束方向偏移导致PDCCH解码成功率低于阈值，BFD依然会触发，确保UE能在真正丢失控制信道之前启动恢复。

Qout阈值的精确计算涉及： - SNR映射：参考信号质量映射到等效SNR - PDCCH假设BLER曲线：根据配置的聚合等级（AL=1/2/4/8/16）查询BLER-SNR映射表 - Qout_LR阈值：TS 38.133定义了对应的最低质量要求（对应~2%BLER等效质量）

3.3 BFI计数器与声明机制

stateDiagram-v2
    [*] --> Normal: RRC配置完成
    Normal --> BFI_Counting: 收到第1个BFI
    BFI_Counting --> BFI_Counting: 收到后续BFI<br/>BFI_COUNTER++
    BFI_Counting --> Normal: 收到non-BFI指示<br/>BFI_COUNTER = 0
    BFI_Counting --> BeamFailureDeclared: BFI_COUNTER >=<br/>beamFailureInstanceMaxCount
    BeamFailureDeclared --> NewBeamID: 启动新波束识别
    NewBeamID --> CFRA_BFRQ: 找到候选波束<br/>且CFRA资源配置存在
    NewBeamID --> CBRA_BFRQ: 找到候选波束<br/>无CFRA资源
    NewBeamID --> BFR_Failed: 未找到候选波束
    CFRA_BFRQ --> BFR_Success: 收到gNB响应<br/>(C-RNTI PDCCH)
    CFRA_BFRQ --> BFR_Failed: timer超时
    CBRA_BFRQ --> BFR_Success: 竞争解决成功
    CBRA_BFRQ --> BFR_Failed: timer超时
    BFR_Success --> Normal: 重置BFI_COUNTER<br/>恢复正常监测
    BFR_Failed --> [*]: 触发RLF/RRC重建

关键参数说明：

四、候选波束选择——新波束识别（New Beam Identification）

4.1 候选波束评估流程

波束失败声明后，UE必须立即在candidateBeamRSList中寻找满足条件的新波束。这是BFR最关键的步骤——如果找不到合适波束，BFR将直接失败。

候选波束选择算法（TS 38.321 Section 5.17步骤2）：

对于 candidateBeamRSList 中的每个参考信号 RS_i:
    测量 L1-RSRP(RS_i)
    如果 RS_i 是 SSB 类型:
        如果 L1-RSRP(RS_i) >= rsrp-ThresholdSSB:
            选择 RS_i 作为新波束
            break
    如果 RS_i 是 CSI-RS 类型:
        如果 L1-RSRP(RS_i) >= rsrp-ThresholdCSI-RS:
            选择 RS_i 作为新波束
            break

如果没有找到任何满足条件的候选波束:
    如果是 SpCell BFR:
        触发 RLF (T310相关流程)
    如果是 SCell BFR:
        触发 BFR MAC CE 上报 (如果配置)

4.2 候选波束与PRACH前导码的映射

当UE找到满足条件的候选波束后，需要确定如何向gNB指示选择的新波束。3GPP定义了两种路径：

路径A：无竞争随机接入（CFRA）

当RRC在BeamFailureRecoveryConfig中为候选波束配置了专用的PRACH前导码和PRACH时机时，UE使用CFRA。关键映射关系为：

gNB收到特定前导码后，根据前导码与波束的映射表，立即知道UE选择了哪个新波束。这是BFR最快的恢复路径——gNB无需额外信令即可在正确的波束方向上发送响应。

路径B：竞争随机接入（CBRA）

当候选波束没有对应的CFRA资源配置时，UE回退到CBRA。此时UE在候选波束对应的SSB的PRACH occasion上随机选择前导码发送，后续通过Msg3中的C-RNTI MAC CE标识自己。

4.3 CFRA与CBRA路径对比

flowchart TD
    A[波束失败声明] --> B[新波束识别]
    B --> C{候选波束<br/>L1-RSRP ≥ Qin?}
    C -->|否| D[BFR失败<br/>触发RLF]
    C -->|是| E{CFRA资源<br/>已配置?}
    E -->|是| F[CFRA路径]
    E -->|否| G[CBRA路径]

    F --> F1[发送专用PRACH前导码]
    F1 --> F2[gNB在recoverySearchSpace<br/>回复C-RNTI PDCCH]
    F2 --> H[BFR成功]

    G --> G1[发送竞争PRACH前导码]
    G1 --> G2[接收RAR]
    G2 --> G3[发送Msg3<br/>C-RNTI MAC CE]
    G3 --> G4[竞争解决]
    G4 --> H

    H --> I[重置BFI_COUNTER<br/>恢复正常监测]

五、BFR响应与完成——recoverySearchSpace机制

5.1 专用搜索空间监测

BFRQ（PRACH前导码）发送后，UE不再在原有的Type-PDCCH公共搜索空间中等待响应，而是切换到专用recoverySearchSpace（TS 38.213 Section 10.1）进行监测。

这个设计意图非常明确： 1. 原服务波束已失败——在原波束方向上的PDCCH已经无法可靠接收 2. 新波束方向已知——gNB从BFRQ的前导码已推断出UE选择的新波束 3. gNB在新波束方向上发送响应——使用recoverySearchSpace配置的控制资源集

gNB在recoverySearchSpace中发送的PDCCH使用UE的C-RNTI加扰，UE一旦成功解码该PDCCH（可能承载UL Grant或DL Assignment），即认为BFR成功完成。

5.2 beamFailureRecoveryTimer超时处理

如果beamFailureRecoveryTimer超时仍未收到gNB响应：

• SpCell（PCell）BFR：UE认为BFR失败，触发RLF，进而可能发起RRC连接重建
• SCell BFR（Rel-16增强）：UE触发BFR MAC CE上报，通过SpCell向gNB指示SCell的波束失败

六、Rel-16/17/18 BFR增强演进

6.1 Rel-16：SCell BFR

Rel-15仅支持SpCell（PCell/PSCell）的BFR。Rel-16扩展到SCell，引入了BFR MAC CE机制：

• UE在SCell上检测到波束失败后，不是发起随机接入，而是通过SpCell向gNB发送BFR MAC CE（LCID=56/57）
• BFR MAC CE中包含失败SCell的ServCellIndex和候选波束信息
• gNB收到后通过RRC重配置或MAC CE指示SCell的新波束

6.2 Rel-17：多TRP场景下的BFR

Rel-17引入了BFD-RS集合概念，支持多TRP部署场景下的独立波束失败检测：

6.3 Rel-18：多TRP同步BFR（sBFR）与面板特定BFR

Rel-18进一步引入了： - sBFR（Synchronous BFR）：多个TRP的BFR可以同步执行，减少恢复时延 - 面板特定BFR（Panel-specific BFR）：支持UE多个天线面板独立进行波束失败检测和恢复 - Inter-cell BFR预研：为Rel-19的L1/L2移动性（LTM）做铺垫，支持跨小区的波束恢复

七、RRC配置参数全表

以下是BeamFailureRecoveryConfig（TS 38.331）中与BFR直接相关的完整RRC参数：

八、抓包识别与排错实战

8.1 抓包识别BFR流程

在UE侧日志（如QXDM/Qualcomm log、 MediaTek ELT）中识别BFR：

gNB侧识别： - 检测到CFRA专用前导码接收 → 判定为BFRQ - 关联前导码索引到波束映射表 → 确定UE选择的新波束 - 在新波束方向上通过recoverySearchSpace发送C-RNTI PDCCH

8.2 常见故障点与排错思路

故障1：频繁触发BFR但恢复成功

症状：日志中反复出现BFR触发→恢复成功循环。

排错方向： - 检查BFD-RS配置是否与服务波束对应（SSB索引是否匹配） - 检查Qout阈值配置是否过于激进（误将正常波动判为失败） - 检查周围是否存在周期性遮挡（如旋转门、电梯、人体遮挡） - 核查gNB波束权值是否需要优化（静态权值 vs 动态权值）

故障2：BFR触发后无法找到候选波束

症状：BFR声明后，candidateBeamRSList中无一满足Qin阈值。

排错方向： - 检查候选波束列表是否覆盖了足够的空间方向（建议至少8个SSB方向） - 检查rsrp-ThresholdSSB是否设置过高 - 检查是否存在全局性覆盖盲区（非单波束问题） - 考虑是否需要gNB侧增加SSB波束数量或调整波束方向

故障3：CFRA前导码发送后无gNB响应

症状：BFRQ已发送，beamFailureRecoveryTimer超时。

排错方向： - 检查PRACH occasion配置是否与gNB侧一致 - 检查前导码索引到波束的映射表是否gNB/UE两侧对齐 - 检查recoverySearchSpace配置是否正确（ID、CORESET、监测时机） - 检查gNB是否在正确的新波束方向上发送了PDCCH

故障4：SCell BFR MAC CE未触发恢复

症状：SCell波束失败后BFR MAC CE已发送但gNB未响应。

排错方向： - 检查SCell的BFR配置是否完整（candidateBeamRSList等） - 检查BFR MAC CE中的ServCellIndex是否正确 - 检查SpCell的UL Grant是否及时分配用于MAC CE传输 - 核查gNB侧是否正确解析了BFR MAC CE

九、BFR与RLF的关系——为什么不直接用RLF？

这是理解BFR设计的关键问题。下图对比两种恢复路径：

flowchart TB
    subgraph BFR路径["BFR路径 (L1/L2)"]
        A1[波束质量恶化] --> A2[BFI计数达到阈值<br/>~10-30ms]
        A2 --> A3[候选波束选择<br/>~5ms]
        A3 --> A4[CFRA PRACH发送<br/>~2-5ms]
        A4 --> A5[gNB响应<br/>~2-5ms]
        A5 --> A6[BFR成功<br/>总时延: ~20-40ms]
    end

    subgraph RLF路径["RLF路径 (L3)"]
        B1[波束质量恶化] --> B2[T310定时器超时<br/>~100-1000ms]
        B2 --> B3[RLF声明]
        B3 --> B4[RRC连接重建请求<br/>涉及NG-C/N2信令]
        B4 --> B5[gNB/AMF处理<br/>~50-200ms]
        B5 --> B6[重建完成<br/>总时延: ~200-1500ms]
    end

    style BFR路径 fill:#e8f5e9
    style RLF路径 fill:#ffebee

BFR的设计本质是在不打破RRC连接的前提下，利用物理层和MAC层的能力快速完成波束切换。gNB和核心网（AMF/UPF）甚至感知不到BFR的发生——从NG接口看，RRC连接始终处于CONNECTED态。

十、BFR IE结构解析

10.1 BFR MAC CE格式（Rel-16 SCell BFR）

BFR MAC CE (LCID = 56):
┌───────────────────────────────────────┐
│  R  │  R  │  R  │  R  │  R  │  R  │AC│SP│  Oct 1
├───────────────────────────────────────┤
│            ServCellIndex              │  Oct 2
├───────────────────────────────────────┤
│  R  │  R  │  R  │  R  │  R  │  R  │ Candidate RS ID  │  Oct 3
└───────────────────────────────────────┘

字段说明:
- SP: SpCell字段（1=SpCell, 0=SCell）
- AC: Available Candidate（1=找到候选波束）
- ServCellIndex: 失败的小区索引
- Candidate RS ID: 候选波束参考信号ID（4 bits）

10.2 截断BFR MAC CE（Truncated BFR, LCID = 57）

当SCell发生波束失败但未找到候选波束时，UE发送截断BFR MAC CE：

Truncated BFR MAC CE (LCID = 57):
┌───────────────────────────────────────┐
│  R  │  R  │  R  │  R  │  R  │  R  │ 0│SP│  Oct 1
├───────────────────────────────────────┤
│            ServCellIndex              │  Oct 2
└───────────────────────────────────────┘

字段说明:
- AC = 0: 未找到可用候选波束
- 无Oct 3（不包含候选波束信息）

十一、常见问题

Q1: BFD检测的Qout阈值和RLF检测的Qout阈值是同一个吗？

A: 不是。虽然两者都使用"假设PDCCH BLER"判定逻辑，但BFD的Qout和RLF的Qout_LR是独立的参数，配置在不同的RRC信元中。BFD的Qout主要针对波束级质量恶化（单个波束方向不可用），而RLF的Qout_LR针对小区级链路质量恶化（整个小区的连接不可维持）。BFD的触发条件通常更灵敏，以便在RLF之前启动快速恢复。

Q2: BFR成功后，gNB是否需要发送RRC重配置？

A: 通常不需要。BFR成功后，gNB通过新波束方向上的PDCCH调度即可恢复正常通信。gNB内部会更新波束对应关系（下行TX波束和UE的上行RX波束）。但在某些实现中，如果BFR频繁触发，gNB可能主动发起RRC重配置来优化BFD-RS配置或候选波束列表。

Q3: FR1（Sub-6GHz）是否支持BFR？

A: 标准上支持（BFR不是FR2专属功能），但实际部署中FR1波束较宽，波束失败的概率远低于FR2。FR1场景中更多依赖传统的RLF机制或切换来处理链路恶化。部分运营商在FR1的毫米波热点覆盖区域会启用BFR。

Q4: SCell BFR失败后会发生什么？

A: 与SpCell不同，SCell BFR失败不会触发RLF。UE通过BFR MAC CE通知gNB后，如果gNB未能通过波束切换恢复SCell，gNB可以选择：①发起SCell释放（SCell Release MAC CE）；②发起SCell重配置（更换波束或参考信号）；③暂时保持SCell去激活态。用户的业务流量不会中断（会回退到SpCell或其他SCell承载）。

Q5: BFR和Beam Switching（PDCCH命令/MAC CE触发的波束切换）有什么区别？

A: BFR是UE自主触发的恢复机制——UE检测到波束失败后主动发起恢复，不需要gNB指令。而Beam Switching是gNB触发的主动波束管理——gNB通过TCI State指示、PDCCH命令或MAC CE命令UE切换到指定波束。BFR用于紧急恢复场景，Beam Switching用于日常波束优化。

参考来源

1. 3GPP TS 38.321 V18.1.0 — Section 5.17 Beam Failure Detection and Recovery procedure
2. 3GPP TS 38.213 V18.x — Section 6 Beam Failure Detection, Section 10.1 BFR Search Space
3. ShareTechnote — 5G Beam Failure Recovery — BFR流程图与参数详解
4. WirelessBrew — Beam Failure Detection and Recovery — 完整BFD/BFR规程分析
5. 3GPP Explorer — BFR Glossary — BFR术语与Rel演进总结
6. ITEC Spec — TS 38.321 Section 5.17 — Section 5.17规范原文在线查看
7. arXiv:2309.10575 — AI/ML for Beam Management in 5G-Advanced — AI辅助波束管理标准进展

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。