# 5G NR 波束失败恢复（BFR）机制深度拆解 > 聚焦 3GPP TS 38.321 §5.17、TS 38.213 §6/§17、TS 38.331 `BeamFailureRecoveryConfig`，从 PHY/MAC/RRC 跨层视角拆解波束失败检测、候选波束识别、CFRA/CBRA 恢复，并覆盖 Rel-16 两步 RA 与 Rel-17 SCell BFR 的演进。 ## 一、为什么需要 BFR：毫米波方向性链路的"脆弱性"问题 5G NR 在 FR2（毫米波频段）采用模拟波束赋形，下行 PDCCH/PDSCH、上行 PUCCH/PUSCH 都通过窄而高的方向性波束收发。波束增益换来的代价是**链路对方向极度敏感**：行人遮挡、车辆驶过、树叶摆动、终端旋转，都可能在毫秒级时间内把当前波束的信号质量压垮。一旦承载 PDCCH 的当前波束被阻断，UE 收不到调度信令，整条连接瞬间"失聪"——但此时物理层之上的 RRC 连接、PDU 会话、加密上下文都完好无损，远没到需要 RRC 重建的程度。 BFR（Beam Failure Recovery，波束失败恢复）就是为这种"物理层波束丢失但高层连接尚存"的场景设计的**快速、本地化、跨层协同的自愈机制**。它的核心设计目标是： - **不要触发 RRC 重建**：避免重建带来的接入网重配置、UPF 路径切换、数十毫秒级中断，把恢复控制在 PHY/MAC 层。 - **快速换波束**：在新波束上用一次随机接入"敲门"，让 gNB 知道 UE 已切到哪个波束，随后在新链路上继续通信。 - **兼顾可靠与效率**：为常用候选波束预配专用无竞争前导码（CFRA），减少冲突；无专用资源时退化为竞争接入（CBRA）兜底。 理解 BFR 的关键，是把握它**贯穿 PHY、MAC、RRC 三层**的分工：PHY 负责"判失败 + 找新波束"，MAC 负责"计数 + 触发 + 执行随机接入 + 收尾"，RRC 负责"提供配置参数与失败后的重建兜底"。 ## 二、BFR 总体流程与三阶段架构 BFR 在逻辑上分为三个连续阶段，下图给出完整判定与执行链路： ```mermaid flowchart TD A["UE正常接收PDCCH
当前波束质量良好"] --> B{"PHY层监测BFD-RS
假设PDCCH BLER > Qout?"} B -- 是 --> C["PHY向MAC发送
BFI波束失败实例指示"] B -- 否 --> Z["继续正常监测"] C --> D["MAC: BFI_COUNTER++
启动/重启beamFailureDetectionTimer"] D --> E{"BFI_COUNTER >=
beamFailureInstanceMaxCount?"} E -- 否 --> F{"beamFailureDetectionTimer
超时?"} F -- 是 --> G["BFI_COUNTER清零
回到正常监测"] F -- 否 --> B E -- 是 --> H["声明波束失败
进入候选波束识别(CBI)"] H --> I{"存在L1-RSRP > Qin的
候选波束?"} I -- 是 --> J["选定新波束
发起BFR随机接入"] I -- 否 --> K["无可用候选波束
可能演变为RLF"] J --> L{"接入成功?
recoverySearchSpace收到C-RNTI DCI"} L -- 是 --> M["BFR成功
切换到新波束正常通信"] L -- 否 --> N["重试耗尽/失败
触发RRC重建立"] ``` 三个阶段分别对应：**波束失败检测（Beam Failure Detection, BFD）→ 候选波束识别（Candidate Beam Identification, CBI）→ 恢复（Recovery via PRACH）**。下面逐层拆解。 ## 三、阶段一：波束失败检测（BFD） ### 3.1 BFD-RS：拿什么信号来判断波束死了？ BFD 的第一性问题是用什么参考信号来评估当前波束的健康度。3GPP 给出的方案是 **BFD-RS（Beam Failure Detection Reference Signal）**，它可以是 SSB 或 CSI-RS。RRC 既可显式配置 BFD-RS 列表，也可不显式配置——**若未显式配置，UE 自动取 CORESET 激活 TCI 状态所关联的 RS（即承载 PDCCH 的那组波束）作为 BFD-RS**。这一设计意图很明确：检测对象就是"正在用于收 DCI 的波束"，因为 DCI 收不到才是真正的失败。 显式配置 BFD-RS 的好处是允许配置**两个或更多 BFD-RS**（对应多波束 PDCCH），只要其中任何一个仍可用，就不算失败；只有当集合内所有 BFD-RS 都恶化时，PHY 才产生一次失败实例。相比依赖 SSB（周期 20ms、波束数量有限），用 CSI-RS/专用 RS 可以做到更密、更精细的波束级监测。 ### 3.2 PHY 层判定：Qout 与"假设 PDCCH BLER" PHY 不直接测 RSRP 来判失败，而是基于 TS 38.213 §6 定义的 **Qout** 参考点——即"在当前 BFD-RS 质量下，假设的 PDCCH 误块率（BLER）达到 10%"所对应的信号水平（可理解为"链路不可用门槛"）。当某 BFD-RS 的质量低于 Qout 对应水平时，PHY 认为该波束已无法可靠承载 DCI。**当集合内全部 BFD-RS 都低于 Qout，PHY 向 MAC 上报一次 BFI（Beam Failure Instance Indication，波束失败实例指示）。** 注意：单次 BFI 只是"疑似抖动"，不立即触发恢复——可能只是瞬时的多普勒或干扰。MAC 层需要做计数与去抖。 ### 3.3 MAC 层计数与去抖：BFI_COUNTER 与计时器 MAC 收到 BFI 后执行经典计数逻辑，这是一个典型的"滑动窗口式"误判抑制状态机： ```mermaid stateDiagram-v2 [*] --> Normal: 波束质量正常 Normal --> Counting: 收到第1个BFI
BFI_COUNTER=1
启动beamFailureDetectionTimer Counting --> Counting: 再收BFI
计数+1,重启Timer Counting --> Normal: beamFailureDetectionTimer超时
计数清零 Counting --> BeamFailure: BFI_COUNTER≥beamFailureInstanceMaxCount BeamFailure --> Recovered: 恢复成功 BeamFailure --> RLF: 恢复失败 ``` 两个参数协同控制灵敏度： - **`beamFailureDetectionTimer`**：每收到一个 BFI 就启动或重启该计时器；若它超时（即一段时间内没再累积新的 BFI，说明只是瞬时抖动），计数清零，回到正常监测。 - **`beamFailureInstanceMaxCount`**：连续累积的 BFI 计数上限。一旦 `BFI_COUNTER` 达到该值且计时器仍在运行，MAC 正式**声明波束失败**并进入下一阶段。 这组参数体现了典型的"连续 N 次判定才确认"的鲁棒性设计。两个值越小，恢复越灵敏但越容易误触发（频繁的 BFR 会打断业务）；越大，越不容易误判但失败后响应慢。FR2 部署中通常需要结合路测统计折中取值。 ## 四、阶段二：候选波束识别（CBI） 声明波束失败后，UE 并非盲目接入，而是先确认"有没有可用的新波束可切"。UE 在网络预配的候选波束列表（SSB 或 CSI-RS）上测量 **L1-RSRP**，并与 **Qin 参考点对应的门限**比较——Qin 对应"假设 PDCCH BLER 为 2%"的信号水平，即"链路质量良好、足以承载 DCI"的标准。 对应 RRC 参数： - **`rsrp-ThresholdSSB`**：SSB 候选波束的 RSRP 门限。 - **CSI-RS 候选波束门限**：Rel-15 复用同一门限，Rel-17 引入 `candidateBeamThresholdList` 支持为每个 CSI-RS 候选单独配置门限。 只要存在至少一个候选波束的 L1-RSRP 高于门限，UE 就选定它（若有多个，通常选最优），进入恢复阶段；**若没有任何候选波束达标**，UE 无法立即恢复，将持续尝试或最终演变为无线链路失败（RLF），由 RRC 重建兜底。这一步实质是"先确认有路再敲门"，避免在死链上浪费接入资源。 ## 五、阶段三：恢复——通过随机接入"换波束" 恢复的核心动作是**在新波束上发起一次随机接入**，让 gNB 感知 UE 已切到该波束。3GPP 提供了两条路径：优先 CFRA（无竞争），无资源时退化为 CBRA（竞争）。 ### 5.1 CFRA 模式：专用前导码"一一映射"新波束 如果网络通过 `rach-ConfigBFR` 为候选波束预配了专用随机接入资源——即把**每个候选 SSB/CSI-RS 映射到一个专用前导码 + 一个 PRACH 时机**（`ssb-basedRACH-Resources` / `csi-RS-basedRACH-Resources`），UE 就走 CFRA。这种"波束↔前导码"的映射带来一个精妙的设计：**gNB 只要收到 p64 这个专用前导码，就隐含地知道 UE 选了 SSB#3 这个新波束**，无需 UE 再用 MAC CE 显式上报，省时省信令。完整时序如下： ```mermaid sequenceDiagram participant PHY as UE-PHY participant MAC as UE-MAC participant RRC as UE-RRC participant gNB as gNB Note over PHY,MAC: 已声明波束失败,候选波束SSB#3已选定 MAC->>RRC: 内部通知波束失败 RRC->>MAC: 提供rach-ConfigBFR
SSB#3→前导码p64+PRACH时机 MAC->>PHY: 触发BFR随机接入(CFRA)
指示发送p64 PHY->>gNB: Msg1: 专用前导码p64
(隐含指示新波束SSB#3) Note over MAC: 启动beamFailureRecoveryTimer gNB->>PHY: Msg2: RAR(RA-RNTI)
含TA与UL Grant gNB->>PHY: DCI(C-RNTI加扰)
在recoverySearchSpaceId对应CORESET PHY->>MAC: 检测到C-RNTI DCI → BFR成功 MAC->>RRC: BFR成功通知 Note over gNB,PHY: (可选)gNB下发TCI状态激活MAC CE
进一步精修下行接收波束 Note over PHY,gNB: 在新波束SSB#3上恢复正常PDCCH/PDSCH收发 ``` 成功确认的关键标志是：UE 在 **`recoverySearchSpaceId` 指定的"恢复专用搜索空间"** 上，于 `beamFailureRecoveryTimer` 运行期间收到一个 **用 C-RNTI 加扰的 DCI**。这个设计意图很巧妙——收到 C-RNTI 加扰的 DCI，既证明 gNB 收到了 BFR 请求、又证明 UE 在新波束上的下行链路确实可用（否则收不到该 DCI），一次确认完成两重验证。 ### 5.2 CBRA 回退：用 BFR MAC CE 显式上报新波束 当所选候选波束没有对应的专用 CFRA 资源时，UE 回退到普通竞争随机接入（CBRA）。此时"波束↔前导码"映射不存在，gNB 无法从前导码推断 UE 选了哪个波束，于是 UE 在 **Msg3 中携带 SpCell BFR MAC CE**，显式上报所选候选波束标识。竞争解决通过 gNB 用 C-RNTI 调度 Msg4 完成。CBRA 更慢（4 次消息往返），但作为兜底保证了"任何场景都能恢复"。 ### 5.3 两步 RA（Rel-16）与失败处理 Rel-16 引入两步随机接入后，BFR 也可配置走 2 步 RA：UE 在 **MsgA** 中同时携带前导码与 BFR MAC CE（载荷），gNB 用 **MsgB** 应答，成功标志仍是 C-RNTI。这进一步缩短了恢复时延，对 URLLC/工业场景价值显著。 收尾由 **`beamFailureRecoveryTimer`** 把控：它在发起 BFR 接入时启动，若在窗口内一直没收到 C-RNTI DCI，且随机接入尝试次数耗尽（受 `preambleTransMax` 等约束），MAC 向上层报告**波束失败恢复失败**，触发 RRC 重建立——这是 BFR 未能自愈时的最后兜底。 ## 六、Rel-17 演进：SCell BFR——辅小区也需要自愈 Rel-15 的 BFR 只覆盖 SpCell（主小区组的主小区）。但 CA（载波聚合）场景下，辅小区（SCell）同样使用方向性波束，同样会被遮挡。若 SCell 波束死了却不恢复，整个载波带宽白白浪费。Rel-17 引入 **SCell BFR**： - SCell 波束失败后，UE **不在 SCell 上发 PRACH**（SCell 本就不做接入），而是经由**链路正常的 SpCell** 上报。 - 上报载体是 **SCell BFR MAC CE**：它用一个**位图标识哪些 SCell 发生了波束失败**，并为每个失败 SCell 指出选定的候选波束。 - 当 PUSCH 资源不足以承载完整位图时，使用 **Truncated SCell BFR MAC CE**（截断版）只报最紧急的小区。 ```mermaid sequenceDiagram participant UE as UE(SpCell链路正常) participant gNB as gNB Note over UE: SCell#2波束被阻挡 UE->>UE: 经SpCell上的PUCCH/SR
申请PUSCH资源 UE->>gNB: SCell BFR MAC CE
(失败小区位图+候选波束) gNB->>UE: (可选)TCI状态激活MAC CE
为SCell#2激活新波束 Note over UE: SCell#2在新波束恢复
全程无需PRACH ``` SCell BFR 体现了"在不破坏现有接入架构的前提下扩展自愈范围"的演进思路：复用 SpCell 的控制面承载失败上报，避免给 SCell 引入复杂的接入逻辑。 ## 七、RRC 配置结构：`BeamFailureRecoveryConfig` 全景 BFR 的一切行为都由 RRC 驱动。关键 IE 都封装在 **`BeamFailureRecoveryConfig`**（承载于 `SpCellConfig`）中，结构如下： ```mermaid graph TD SCC["SpCellConfig"] --> BFRC["BeamFailureRecoveryConfig"] BFRC --> F1["beamFailureInstanceMaxCount
BFI计数上限N"] BFRC --> F2["beamFailureDetectionTimer
BFD去抖计时器"] BFRC --> F3["beamFailureRecoveryTimer
恢复监听计时器"] BFRC --> F4["rsrp-ThresholdSSB
候选波束Qin门限"] BFRC --> F5["ssb-basedRACH-Resources
SSB→专用前导码映射"] BFRC --> F6["csi-RS-basedRACH-Resources
CSI-RS→专用前导码映射"] BFRC --> F7["recoverySearchSpaceId
恢复专用搜索空间"] BFRC --> F8["rach-ConfigBFR
BFR专用RACH公共参数"] BFRC --> F9["ra-ContentionResolutionTimer
CBRA回退竞争解决计时器"] BFRC --> F10["candidateBeamThresholdList
CSI-RS候选门限(Rel-17)"] ``` ### 表 1：`BeamFailureRecoveryConfig` 关键字段说明 | 字段 | 作用层 | 含义 | 调优影响 | |------|--------|------|----------| | `beamFailureInstanceMaxCount` | MAC | 声明失败所需连续 BFI 数 N | 越小越灵敏、易误触；越大越迟钝 | | `beamFailureDetectionTimer` | MAC | BFI 去抖窗口 | 越短越快确认抖动结束；越长越容忍突发 | | `beamFailureRecoveryTimer` | MAC | 恢复尝试监听窗口 | 过短易误判恢复失败；过长拖慢兜底重建 | | `rsrp-ThresholdSSB` | PHY(CBI) | SSB 候选波束可用门限（对应 Qin） | 决定能否快速找到新波束 | | `ssb-basedRACH-Resources` | PHY/MAC | SSB 候选→专用前导码+PRACH 时机 | 决定能否走 CFRA 快速恢复 | | `csi-RS-basedRACH-Resources` | PHY/MAC | CSI-RS 候选→专用前导码+PRACH 时机 | 细波束级 CFRA 恢复 | | `recoverySearchSpaceId` | PHY | 恢复期监听 C-RNTI DCI 的搜索空间 | 隔离恢复监听与常规调度 | | `rach-ConfigBFR` | PHY/MAC | BFR 专用 RACH 公共参数 | 与常规 RACH 解耦，互不抢占 | | `ra-ContentionResolutionTimer` | MAC | CBRA 回退时的竞争解决计时器 | 影响回退路径时延 | ### 表 2：CFRA 与 CBRA 模式对比 | 维度 | CFRA（无竞争） | CBRA（竞争回退） | |------|---------------|------------------| | 前导码来源 | RRC 专用预配，每候选波束一个 | 随机选择 | | 新波束上报 | 前导码隐含指示（无需 MAC CE） | Msg3 携带 SpCell BFR MAC CE 显式上报 | | 竞争解决 | 不需要 | 需要（C-RNTI 调度 Msg4） | | 消息往返 | Msg1→Msg2，约 2 次 | Msg1→Msg4，约 4 次 | | 时延 | 快，确定性好 | 慢，存在冲突风险 | | 适用前提 | 所选候选波束有专用资源 | 兜底，任何场景可用 | ### 表 3：SpCell BFR 与 SCell BFR 对比 | 维度 | SpCell BFR（Rel-15） | SCell BFR（Rel-17） | |------|---------------------|---------------------| | 恢复路径 | 在失败 SpCell 上发 PRACH（新波束） | 经正常的 SpCell 上报，不发 PRACH | | 上报载体 | 前导码 + Msg3 BFR MAC CE | SCell BFR MAC CE（含失败小区位图） | | 是否依赖他链路 | 否（自愈） | 是（依赖 SpCell 可用） | | 失败后果 | BFR 失败→RLF→RRC 重建 | 该 SCell 带宽暂时不可用，SpCell 不受影响 | | 触发对象 | 承载 PDCCH 的主链路 | 仅辅载波 | ## 八、抓包与日志识别：如何确认一次 BFR BFR 主要发生在 PHY/MAC 内部，传统 IP 抓包看不到，需结合终端 L1/L2 日志与 gNB 侧信令跟踪： 1. **PHY 侧**：搜索"BFI indication"或"beam failure instance"，观察在哪个 BFD-RS（SSB/CSI-RS 索引）上连续出现；L1-RSRP 曲线可看到对应波束 RSRP 跌破 Qout。 2. **MAC 侧**：跟踪 `BFI_COUNTER` 的累加与 `beamFailureDetectionTimer` 的启动/超时；计数达到 `beamFailureInstanceMaxCount` 即正式声明失败。 3. **接入侧**：观察 PRACH 事件，识别"目的=beam failure recovery"的前导码；若该前导码命中 `ssb-basedRACH-Resources` 预配表，则为 CFRA，可反推出所选新波束 SSB 索引。 4. **恢复确认**：在 `recoverySearchSpaceId` 对应 CORESET 上找到 C-RNTI 加扰的 DCI，且时间在 `beamFailureRecoveryTimer` 窗口内，即一次成功 BFR。 5. **失败回退**：若未见 C-RNTI DCI、`beamFailureRecoveryTimer` 超时、PRACH 重传至 `preambleTransMax`，则 MAC 报 BFR 失败，日志中随后出现 RRC Reestablishment 流程。 **常见故障点**： - 所选候选波束无 CFRA 资源 → 被迫 CBRA，恢复时延陡增、易冲突； - `beamFailureInstanceMaxCount`/`beamFailureDetectionTimer` 配置激进 → 频繁误触发 BFR，打断业务、抬升丢包； - 候选波束列表过短或 `rsrp-ThresholdSSB` 过高 → 找不到可用新波束，BFR 失败演变为 RLF； - FR2 部署遮挡密集但 BFD-RS 仅配 SSB → 检测粒度粗、响应慢； - 反复 BFR 成功但每次都切回同一被阻波束 → 需排查 TCI 状态激活策略与 gNB 波束管理逻辑。 ## 十、设计意图小结 BFR 的整体设计哲学是**"分层自愈、能用本地层绝不惊动高层"**：PHY 用假设 BLER 与 Qout/Qin 参考点做精确的物理层判定，MAC 用计数+计时器做去抖与执行，RRC 只在配置与最终兜底时介入。CFRA 的"波束↔前导码"映射把一次接入变成了"新波束的隐含声明"，是整个机制最精巧的一笔——用最小的信令开销完成"我换到这个波束了"的双向确认。Rel-16 两步 RA 与 Rel-17 SCell BFR 则沿着"更快、覆盖更广"两个方向持续演进。 ## 常见问题 **Q1：BFR 与 RLF（无线链路失败）有什么区别？** A：BFR 是**物理层波束级**的自愈——当前波束不通但高层连接完好，UE 换个波束、敲一次随机接入即可恢复，全程不动 RRC。RLF 是更严重的**链路级失败**，需要 RRC 重建（重新接入、重新配置、可能触发切换）。当 BFR 自愈失败时，问题才会升级为 RLF。 **Q2：为什么 BFR 优先用 CFRA 而非普通竞争接入？** A：CFRA 的专用前导码与候选波束一一映射，既消除了竞争冲突，又能让 gNB 从前导码隐含获知 UE 选定的新波束，省去显式上报，时延更短、确定性更好——这对方向性链路的快速恢复至关重要。CBRA 只是"没有专用资源时的兜底"。 **Q3：SCell BFR 为什么不在 SCell 上发 PRACH？** A：SCell 在 3GPP 架构里**本就不承担随机接入**（接入只在 SpCell 做）。Rel-17 设计复用了这一既有原则：SCell 波束失败时，UE 经链路正常的 SpCell 用 SCell BFR MAC CE 上报，gNB 据此为该 SCell 激活新波束，无需给 SCell 引入接入逻辑。 **Q4：`beamFailureDetectionTimer` 和 `beamFailureRecoveryTimer` 有何区别？** A：前者在**检测阶段**用于 BFI 去抖（控制多快确认"连续失败"）；后者在**恢复阶段**控制 UE 等待 gNB 响应的窗口（收到 C-RNTI DCI 即成功，超时即失败）。二者一前一后，分别把控"判定灵敏度"与"恢复时延上限"。 **Q5：SpCell BFR MAC CE 在 CFRA 模式下还需要吗？** A：不需要。CFRA 模式下，专用前导码已隐含指示所选新波束，UE 不必再发 MAC CE。只有走 CBRA 回退（前导码与波束无映射）时，才需要在 Msg3 用 SpCell BFR MAC CE 显式上报候选波束。 ## 参考来源 1. [3GPP TS 38.321 (NR; MAC) §5.17 — Beam Failure Detection and Recovery](https://www.3gpp.org/dynareport/38321.htm) — MAC 层 BFD 计数、计时器与随机接入执行 2. [3GPP TS 38.213 (NR; PHY) §6 / §17](https://www.3gpp.org/dynareport/38213.htm) — Qout/Qin 参考点、PHY 层失败判定与 BFR 控制过程 3. [3GPP TS 38.331 (NR; RRC) — BeamFailureRecoveryConfig IE](https://www.3gpp.org/dynareport/38331.htm) — BFR 全部配置参数定义 4. [ShareTechnote — 5G Beam Failure Recovery](https://www.sharetechnote.com/html/5G/5G_BeamFailureRecovery.html) — 流程图与机制解读 5. [Wireless Brew — Beam Failure Detection and Recovery Procedure in 5G NR](https://wirelessbrew.com/5g-nr/beam-failure-detection-and-recovery-procedure-in-5g-nr/) — BFD/BFR 完整流程分析 6. [Techplayon — 5G NR BFR](https://www.techplayon.com/5g-nr-bfr-beam-failure-recovery/) — 跨层机制与实现要点 --- > 本文由「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 等场景全覆盖。