5G波束失败恢复（BFR）信令全链拆解：从BFD检测到MAC CE确认的毫米波生命线

一、为什么需要BFR：毫米波时代的"链路自救"

在5G NR FR2（毫米波，24.25–52.6 GHz）部署中，gNB与UE之间采用窄而高的定向波束（directional beam）通信。波束虽带来了高增益，却也带来了一个致命弱点：波束遮挡（beam blockage）。一个人体转身、一辆卡车驶过、一片树叶飘动，都可能让服务波束的信号质量在毫秒级内崩溃。

在LTE时代，UE检测到无线链路恶化会触发无线链路失败（RLF），进而进入RRC连接重建（RRC Re-establishment）流程——这是一个耗时数百毫秒、且必然中断用户面、可能切换服务小区的"重操作"。对于毫米波这样频繁的遮挡场景，若每次遮挡都触发RLF+重建，连接稳定性将灾难性下降。

3GPP因此引入了波束失败恢复（Beam Failure Recovery, BFR）机制，其核心思想是：

链路失败后不要立刻重建，而是先尝试在同一个服务小区内换一个新波束恢复连接。

BFR定义在 TS 38.213 Section 5.17（物理层过程）、TS 38.321 Section 5.x（MAC过程与MAC CE）以及 TS 38.331（RRC参数 BeamFailureRecoveryConfig）中。它是一个PHY-MAC-RRC跨层协同机制，与RLF在状态机上完全独立——BFR成功则RRC连接毫发无损，BFR失败才上升为RLF。

flowchart TD
    A[服务波束质量持续恶化] --> B{BFD: BFI计数 ≥ beamFailureInstanceMaxCount?}
    B -->|否| A
    B -->|是| C[声明波束失败 Beam Failure Declared]
    C --> D{CBD: 存在候选波束 RSRP ≥ Qin?}
    D -->|否| E[无候选波束 → 触发RLF/重建]
    D -->|是| F[选择新波束 C-BEAM]
    F --> G[在新波束上发起专用RACH BFRQ]
    G --> H{gNB在recoverySearchSpace响应?}
    H -->|否, 超时| I[BFRQ重传至maxAttempt]
    I -->|仍失败| E
    H -->|是| J[收到C-RNTI MAC CE / 授权]
    J --> K[BFR成功 恢复正常通信]

    style C fill:#ffd6d6
    style K fill:#d6ffd6
    style E fill:#ffcccc

二、四阶段拆解：BFD → CBD → BFRQ → BFR完成

阶段1：波束失败检测（Beam Failure Detection, BFD）

UE持续监测服务波束质量。监测对象由RRC信元 radioLinkMonitoringRS 配置，可以是 SS/PBCH Block（SSB） 或 CSI-RS。物理层以一个假想的"不可靠接收"门限 Qout（对应BLER ≈ 10%的信号质量，约对应很低的SINR）作为判据。

每当UE判定被监测RS的质量低于Qout，物理层上报一个波束失败实例指示（BFI, Beam Failure Instance Indication）给MAC层。MAC层维护一个计数器与一个定时器：

• beamFailureInstanceMaxCount（BFI计数上限）
• beamFailureDetectionTimer（BFI计数窗口定时器）

其状态机逻辑（TS 38.213 5.17与38.321 5.17）为：

stateDiagram-v2
    [*] --> NoFailure: BFI计数 = 0
    NoFailure --> Counting: 收到第1个BFI\n启动beamFailureDetectionTimer
    Counting --> Counting: 又收到BFI (timer未超时)\n计数+1
    Counting --> NoFailure: timer超时\n计数清零
    Counting --> FailureDeclared: BFI计数 ≥ beamFailureInstanceMaxCount
    FailureDeclared --> [*]: 触发Candidate Beam Detection

设计要点：定时器+计数的滑动窗口确保瞬时衰落（如快速多径）不会误判为波束失败，只有"持续"恶化才认定遮挡发生。beamFailureInstanceMaxCount典型取值如 q1/q2/q3...对应1/2/3...次，beamFailureDetectionTimer可配置为e.g. 10ms、20ms等。

阶段2：候选波束检测（Candidate Beam Detection, CBD）

波束失败声明后，UE并不直接放弃，而是在同一服务小区内寻找可用的新波束。gNB通过RRC信元 candidateBeamRSSCellList（或失败检测资源列表）配置了一组候选波束参考信号资源。

UE测量这些候选RS的RSRP，与门限 Qin（对应BLER ≈ 2%的高质量门限，由 rsrp-ThresholdSSB 或 rsrp-ThresholdCSI-RS 给出）比较：

• 若至少一个候选波束 RSRP ≥ Qin → 选定该波束作为 C-BEAM，进入阶段3；
• 若所有候选波束都不满足 → UE无法在该小区恢复，转而触发RLC达到最大重传 / RLF → RRC重建。

Qin与Qout的设计形成滞回（hysteresis）：恢复所要求的质量（Qin）高于失败门限（Qout），避免在临界质量附近反复横跳。

阶段3：波束失败恢复请求（BFRQ）

这是BFR最巧妙的部分——UE复用随机接入（PRACH）来同时实现"请求"与"新波束标识"。gNB为每个候选波束预配置了专用的无竞争随机接入（CFRA）资源：

• rach-ConfigDedicated → CFRA：包含每个SSB/CSI-RS索引对应的前导码（preamble）与RACH时机（RO, RACH Occasion）映射。

UE在选定的C-BEAM对应的专用资源上发送BFRQ preamble。gNB一旦在某个波束的RO上收到该专用preamble，立刻就知道： 1. 该UE发生了波束失败； 2. UE当前在哪个新波束上可被服务。

这就把"失败通知+波束选择报告"压缩成了一次PRACH发送，极为高效。若未配置专用资源，UE回退到基于竞争的随机接入（CBRA）。

阶段4：恢复响应与BFR完成

UE发送BFRQ后，在一个专用搜索空间 recoverySearchSpaceId（区别于普通PDCCH搜索空间）上监听gNB响应。gNB以 C-RNTI加扰的PDCCH 下发上行授权（或携带 C-RNTI MAC CE 用于CBRA竞争解决）。

收到该响应后，UE重置BFI计数、停止定时器，BFR即告成功——RRC连接保持，业务面在毫秒级内于新波束上恢复。整个过程不触发任何RRC状态变更。

三、关键信令时序图（含SCell BFR）

以下时序图完整呈现SpCell波束失败恢复，并叠加Rel-17引入的SCell BFR增强：

sequenceDiagram
    participant UE
    participant gNB
    Note over UE: RRC已配置: BFD-RS, candidateBeamRSList,<br/>rach-ConfigDedicated(CFRA), recoverySearchSpace

    rect rgb(255,235,235)
    Note over UE,gNB: 阶段1-2: BFD 与 CBD
    UE->>UE: 监测服务波束RS, 质量低于Qout → 产生BFI
    UE->>UE: BFI计数累加, 启动/重启beamFailureDetectionTimer
    UE->>UE: BFI ≥ beamFailureInstanceMaxCount → 声明Beam Failure
    UE->>UE: 测量候选波束RS, 选定RSRP≥Qin的新波束 C-BEAM
    end

    rect rgb(235,245,255)
    Note over UE,gNB: 阶段3: BFRQ (专用RACH)
    UE->>gNB: 在C-BEAM的专用RO上发送专用preamble (Msg1)
    Note right of gNB: 由preamble+RO识别出UE与新波束
    gNB->>UE: 在专用RO上回随机接入响应 (Msg2/RAR)
    end

    rect rgb(235,255,235)
    Note over UE,gNB: 阶段4: 恢复响应与完成
    UE->>gNB: (可选) Msg3 携带 BFR MAC CE / 截断BFR MAC CE
    gNB->>UE: recoverySearchSpace内, C-RNTI加扰PDCCH下发UL授权
    UE->>UE: 收到响应 → BFI计数清零, BFR成功
    Note over UE: RRC连接保持, 新波束恢复通信
    end

    opt SCell发生波束失败 (Rel-17)
    UE->>UE: 在SCell上检测到BFI计数超限 → 触发SCell BFR
    UE->>gNB: 在SpCell上发SR请求UL资源
    UE->>gNB: 发送SCell BFR MAC CE (含SCell ID + 新波束ID)
    gNB->>UE: 通过SpCell PDCCH下发响应
    Note right of UE: gNB收到BFR MAC CE的HARQ新传授权 → SCell BFR完成
    end

四、BFR MAC CE 比特级结构（TS 38.321 6.1.3.x）

BFR MAC CE是SCell BFR与SpCell BFR完成确认的核心载体。其结构如下：

flowchart LR
    subgraph BFR MAC CE (SpCell)
        R1[保留位] --> AC[AC字段: 是否包含SpCell<br/>候选波束信息]
        AC --> CI1[CI: 候选波束ID]
    end
    subgraph 截断BFR MAC CE
        T1[仅当无UL授权<br/>容纳完整MAC CE时使用] --> T2[省略候选波束字段]
    end
    subgraph SCell BFR MAC CE
        R2[保留位] --> SI[SI: SCell索引位图<br/>指示哪些SCell失败]
        SI --> AC2[AC: 是否含候选波束]
        AC2 --> CI2[CI: SCell候选波束ID]
    end

BFR MAC CE各字段含义表（TS 38.321 6.1.3.x）：

触发BFR MAC CE传输的关键判定：当UE在PDCCH上收到指示该BFD-RS集合BFR MAC CE所对应HARQ进程的新传UL授权时，对应BFD-RS集合的波束失败恢复即视为完成。

五、关键RRC参数与物理层参数总览

BeamFailureRecoveryConfig（TS 38.331）核心参数表：

六、BFR vs RLF：两个独立又衔接的机制

设计哲学：BFR是RLF的前置"软恢复"层，把大量本不该升级的瞬时遮挡在物理/MAC层就地解决，只有真正的小区级链路崩溃才走RLF。

七、Rel-17/18演进：从SpCell到SCell BFR

早期BFR（Rel-15）仅支持SpCell（PCell/PSCell）。但CA（载波聚合）部署中，辅小区（SCell）同样使用定向波束，SCell波束遮挡会导致该载波吞吐量骤降却无快速恢复手段。

Rel-17（TR 38.812 → 正式规范）引入SCell BFR，其关键差异在于——SCell不能独立发PRACH，恢复请求必须经SpCell转发：

1. UE在SCell检测到波束失败；
2. UE在SpCell上发送调度请求（SR）申请上行资源（可配置专用BFR SR）；
3. 获得授权后，UE在SpCell上发送 SCell BFR MAC CE（携带SCell ID + 候选波束ID）；
4. gNB通过SpCell的PDCCH响应；
5. 收到BFR MAC CE对应HARQ进程的新传授权 → SCell BFR完成。

Rel-18进一步优化了L1/L2中心化的小区间移动性（LTM）与波束级MAC CE效率，BFR MAC CE的截断传输（truncated BFR MAC CE）机制也被强化以适配更紧凑的UL授权。

flowchart TD
    subgraph Rel15 [Rel-15]
        A1[仅SpCell波束失败恢复<br/>基于PRACH]
    end
    subgraph Rel17 [Rel-17]
        A2[新增SCell BFR<br/>SCell BFR MAC CE via SpCell]
        A3[专用BFR SR]
    end
    subgraph Rel18 [Rel-18]
        A4[BFR MAC CE截断传输优化]
        A5[与LTM/L1-L2移动性协同]
    end
    Rel15 --> Rel17 --> Rel18

八、抓包识别与实战排错

如何在抓包中识别BFR流程

BFR大部分在PHY/MAC层，传统NAS/S1/N2信令抓包看不到，需要UE侧日志（高通QXDM/XCAL/MTE）或gNB侧L1日志：

1. BFRQ识别：在MAC UL日志中寻找专用preamble发送，其RA目的字段标记为"BFR"而非"Initial/HO"；或在PRACH日志中看到非SI请求、非初始接入的preamble。
2. recoverySearchSpace监听：L1日志中UE切换到recoverySearchSpaceId对应的CORESET/SearchSpace监听PDCCH。
3. BFR MAC CE：在MAC CE解码中可见LCID指示BFR/截断BFR MAC CE，含AC、CI字段。
4. 成功标志：BFI计数清零、beamFailureDetectionTimer停止，且无RLF/Re-establishment记录。

常见故障点与排错思路

Q1: BFR和RLF到底什么关系？BFR失败后会怎样？ A: BFR是RLF的"前置软恢复"层。服务波束恶化时优先触发BFR，若BFR成功（找到候选波束并完成恢复）则连接保持、不触发RLF；若BFR失败（无候选波束，或BFRQ多次重传无响应），则升级为RLF，进而可能触发RRC连接重建。两者在状态机上独立衔接。

Q2: BFRQ为什么复用PRACH而不是单独定义一个信令？ A: 复用PRACH一举两得：专用preamble+专用RO的映射既携带了"失败请求"语义，又通过"在哪个波束的RO上发送"隐式上报了UE选定的新波束（C-BEAM），无需额外信令字段。这最大化复用了已有的随机接入硬件与流程，设计极为经济。

Q3: SCell BFR为什么不能像SpCell那样直接在SCell上发PRACH？ A: SCell在协议设计上不承载上行PRACH（SCell的上行主要用于数据/PUCCH），且SCell波束失败时该载波链路已不可用。因此SCell BFR必须借用健康的SpCell来发送SR和SCell BFR MAC CE，把恢复请求"代理"转发给gNB，再由gNB为该SCell重配波束。

Q4: Qin和Qout为什么要设计成不同门限（滞回）？ A: Qin（恢复门限，对应BLER≈2%）高于Qout（失败门限，对应BLER≈10%），形成滞回区间。这避免UE在临界质量处反复在"失败-恢复"间振荡，保证只有真正稳定可用的新波束才会被选中，提升恢复后链路的鲁棒性。

Q5: 如何在抓包中确认一次BFR成功而非RLF？ A: 关键看是否出现RRC Re-establishment/Reconfiguration相关消息。若L1/MAC日志显示专用BFRQ preamble发送→recoverySearchSpace收到C-RNTI PDCCH响应→BFI计数清零，且全程无RRC重建消息，则判定BFR成功；若出现Re-establishment Request则已升级为RLF。

参考来源

1. 3GPP TS 38.213 — NR; Physical layer procedures for control — Section 5.17 Beam failure detection and recovery procedures
2. 3GPP TS 38.321 — NR; MAC protocol specification — Section 5.x BFR MAC procedure 与 6.1.3.x BFR/Truncated BFR/SCell BFR MAC CE
3. ShareTechnote — 5G/NR Beam Failure Recovery — BFD/CBD/BFRQ逐步图解与流程
4. WirelessBrew — Beam Failure Detection and Recovery Procedure in 5G NR — BFR参数与BFR MAC CE字段详解
5. 知乎专栏 — 5G通信中的波束失效检测与恢复机制分析 — SCell BFR与多BFD-RS集合失败处理分析

本文由「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 等场景全覆盖。