# 5G NR 波束失败恢复（BFR）机制全链拆解：从 BFD 检测到候选波束切换的完整信令流 ## 引言：为什么毫米波/中频 Massive MIMO 必须有 BFR 5G NR 在 FR2（毫米波，>6GHz）乃至 FR1 的中高频段普遍采用基于模拟/混合波束赋形的窄波束（beam）进行收发。窄波束带来阵列增益，但也带来一个全新的失效模式——**波束失效（Beam Failure）**：当 UE 当前服务波束因为遮挡、旋转、gNB/gNB 侧权重变化等原因骤然衰落时，即使整体无线链路并未中断，UE 也可能瞬间"失联"。如果依赖传统的无线链路失败（RLF）流程来处理，UE 要经历 T310/T311 计时、RRC 重建，时延达数秒，业务必然掉线。 为此 3GPP 在 Rel-15 即引入了**波束失败检测与恢复（Beam Failure Detection and Recovery, BFD/BFR）**机制，定义在 **TS 38.321 §5.17（MAC 层过程）** 与 **TS 38.213（物理层：BFD 指示、BFR 专用随机接入资源与 recovery search space 监测规则）**，并在 **TS 38.331 的 `BeamFailureRecoveryConfig` IE** 中完成 RRC 参数配置。BFR 的核心思想是：在 RLF 触发之前，让 UE **自主检测**当前波束已不可用，**自主发现**一个可用的新波束，并**通过一次轻量随机接入或 MAC CE** 把接收权快速切换到新波束，从而把"掉话级"事件降级为"亚秒级"的自愈事件。 本文聚焦 BFR 在 PCell（基于 CFRA/CBRA 的随机接入恢复）与 SCell（基于 BFR MAC CE 上报，Rel-17 增强）两条恢复路径下的完整信令机制，逐 IE 拆解，并给出抓包/日志识别与排错思路。 --- ## 一、BFR 在 5G 协议栈中的定位 BFR 是一个**横跨 PHY–MAC–RRC 三层**的协作过程，这一点决定了它的复杂度： - **PHY 层（TS 38.213）**：周期性测量 BFD 参考信号（BFD-RS），当测量质量低于门限时，向 MAC 上报一个**波束失败实例指示（Beam Failure Instance, BFI）**；PHY 还负责在 candidate beam 对应的专用 PRACH 资源上发送 preamble，并在 recovery search space 监测 PDCCH。 - **MAC 层（TS 38.321 §5.17）**：维护 BFI 计数器与定时器，判断是否"声明波束失败"，并控制 BFR 过程的发起（CFRA 优先、CBRA 回退，以及 SCell 场景下的 BFR MAC CE 上报）。 - **RRC 层（TS 38.331）**：通过 `BeamFailureRecoveryConfig` 下发全部 BFR 参数与专用随机接入资源。 下图给出 BFR 的整体判断与分支流程： ```mermaid flowchart TD A["PHY 周期测量 BFD-RS
(SSB 或 CSI-RS)"] --> B{"所有 BFD-RS 质量
低于门限?"} B -- 是 --> C["PHY 上报 BFI 指示"] C --> D["MAC: 启动/重启
beamFailureDetectionTimer"] D --> E["MAC: BFI_COUNTER++"] E --> F{"BFI_COUNTER ≥
beamFailureInstanceMaxCount?"} F -- 否 --> A F -- 是 --> G["✅ 声明 Beam Failure"] G --> H["测量 candidateBeamRSList"] H --> I{"存在候选波束
RSRP ≥ rsrp-ThresholdBFR?"} I -- 否 --> J["等待 / 进入 CBRA 回退"] I -- 是 --> K{"该候选波束已配置
专用 PRACH 资源?"} K -- 是 --> L["CFRA BFR (PCell)
专用 preamble + recovery SS"] K -- 否 --> M["CBRA BFR (PCell)
竞争随机接入 Msg1~4"] J --> M L --> N["✅ BFR 成功
后续 TCI 切换到新波束"] M --> N ``` 设计意图很明确：**三层解耦**让 PHY 做最频繁的轻量测量（不消耗 PUCCH），MAC 做计数判断（避免单次抖动误触发），RRC 只在配置时介入一次（信令开销最小）。 --- ## 二、波束失败检测（BFD）机制 ### 2.1 BFD-RS 与 L1 BFI 指示 UE 并非监测"服务波束本身"，而是监测 gNB 显式配置的一组**波束失败检测参考信号（BFD-RS）**，它可以是 SSB，也可以是周期 CSI-RS（Rel-16 起支持 CSI-RS 作为 BFD-RS）。UE 对每个 BFD-RS 估算 RSRP/假想 BLER，当**该 BFD-RS 集合中所有 RS 的质量都低于预设门限**时，PHY 认为发生了"一次波束失败实例"，向 MAC 层上报一个 BFI。 注意 BFI 是 **Layer 1 指示**，不占任何 MAC 信令——这是 BFR 设计中至关重要的一点：检测本身零空口开销。 ### 2.2 MAC 层的计数与去抖 PHY 上报的 BFI 会瞬间抖动（一次人体遮挡可能只持续几十毫秒），因此 MAC 不能单凭一次 BFI 就声明波束失败。TS 38.321 §5.17 定义了去抖逻辑： 1. 收到一个 BFI → 启动或重启 `beamFailureDetectionTimer`，并令 `BFI_COUNTER` 加 1； 2. `beamFailureDetectionTimer` 超时 → 令 `BFI_COUNTER` 清零； 3. 当 `BFI_COUNTER ≥ beamFailureInstanceMaxCount` → **声明 Beam Failure**，并触发 BFR 过程。 定时器的作用是**只统计"连续密集"的 BFI**：若两次 BFI 间隔超过定时器，说明链路有恢复迹象，计数器归零，避免一次长遮挡后被间隔很远的零星 BFI 累积误判。 ### 2.3 关键 RRC 参数说明（表 1） | 参数（TS 38.331 `BeamFailureRecoveryConfig`） | 类型 | 典型取值 | 作用 | |---|---|---|---| | `beamFailureDetectionTimer` | INTEGER | n10~n2000（ms 量级） | BFI 计数去抖定时器；超时清零 `BFI_COUNTER` | | `beamFailureInstanceMaxCount` | ENUMERATED | n1, n2, n3, … n63 | 声明波束失败的 BFI 累计阈值 | | `candidateBeamRSList` | RS 列表 | SSB idx / CSI-RS | 候选波束参考信号，UE 在其中寻找可用新波束 | | `rsrp-ThresholdSSB` | RSRP | -100~-60 dBm | 候选 SSB 波束的"可用"门限 | | `rsrp-ThresholdCSI-RS` | RSRP | -100~-60 dBm | Rel-16 起候选 CSI-RS 波束门限 | | `recoverySearchSpaceId` | SearchSpaceId | 配置的搜索空间 | BFR 响应（C-RNTI 加扰 DCI）的监测空间 | | `rach-ConfigBFR` | RACH-ConfigDedicated | 专用 preamble+RO | CFRA 专用随机接入资源 | | `ra-Prioritization` | 结构体 | powerBoost 等 | 对 BFR 随机接入做优先级抬升 | `beamFailureInstanceMaxCount` 过小（如 n1）会因单次抖动频繁触发 BFR，浪费 PRACH；过大（如 n63）则反应迟钝，可能在真正 RLF 前都无法发起恢复。现网中 n2~n4 较常见。 --- ## 三、候选波束识别（Candidate Beam Identification） 声明 Beam Failure 后，UE 不能"乱发"随机接入，而必须先判断是否有**值得切换的新波束**。UE 测量 `candidateBeamRSList` 中的每个 RS： - 若存在某个候选波束 RSRP ≥ `rsrp-ThresholdSSB`（SSB 候选）或 ≥ `rsrp-ThresholdCSI-RS`（CSI-RS 候选），则认为**找到有效候选波束**，可发起恢复； - 若所有候选波束都低于门限（典型场景：UE 进入深度覆盖盲区），则无有效候选，BFR 无法通过专用资源完成，进入等待或回退路径。 这一步是 BFR 与普通随机接入最本质的区别：**BFR 的 Msg1 携带的不仅是"我要接入"，更隐含"我已经选好新波束"，而 preamble 所在的 PRACH 资源本身就与该波束绑定**（gNB 通过 UE 选的 RO 反推候选波束 ID）。 --- ## 四、PCell 的 BFR 恢复：CFRA 完整信令时序 PCell 是 UE 与网络保持信令连接的"生命线"，其 BFR 采用**专用资源优先（CFRA）、竞争资源回退（CBRA）**的双轨设计。下面给出 CFRA 路径的完整时序图： ```text sequenceDiagram autonumber participant UE_PHY as UE PHY participant UE_MAC as UE MAC participant gNB as gNB (MAC/PHY) Note over UE_PHY,gNB: 阶段0：配置阶段（业务进行中） gNB->>UE_MAC: RRC Reconfiguration
(BeamFailureRecoveryConfig:
BFD timer, maxCount,
candidateBeamRSList,
rach-ConfigBFR, recoverySearchSpace) Note over UE_PHY,gNB: 阶段1：波束失败检测 UE_PHY->>UE_MAC: BFI 指示 (RSRP < 门限) UE_MAC->>UE_MAC: 启动/重启 timer; BFI_COUNTER++ UE_PHY->>UE_MAC: BFI 指示 (连续第N次) UE_MAC->>UE_MAC: BFI_COUNTER ≥ maxCount → 声明 Beam Failure Note over UE_PHY,gNB: 阶段2：候选波束识别 UE_PHY->>UE_MAC: 测量 candidateBeamRSList
找到 RSRP ≥ 门限的候选波束 B_new Note over UE_PHY,gNB: 阶段3：CFRA 恢复 (Msg1 + 响应) UE_PHY->>gNB: Msg1 = 专用 preamble
在 B_new 对应的专用 PRACH RO 上发送 Note right of gNB: 由 RO 反推候选波束 B_new UE_MAC->>UE_PHY: 在 recoverySearchSpace 监测
C-RNTI 加扰的 PDCCH gNB->>UE_PHY: Msg2 = DCI (C-RNTI 加扰)
在 recovery SS 下发 UE_PHY->>UE_MAC: 收到 C-RNTI 响应 → BFR 成功 Note over UE_PHY,gNB: 阶段4：波束切换 gNB->>UE_MAC: TCI State Indication MAC CE / DCI
将上下行接收波束指向 B_new Note over UE_PHY,gNB: 业务在新波束上继续，无需 RRC 重建 ``` ### 4.1 关键 IE 与设计要点逐步解析 **第 1 步（Msg1 专用 preamble）**：CFRA BFR 不需要竞争解决。UE 在 `rach-ConfigBFR` 为该候选波束分配的专用 PRACH Occasion 上，发送专用 preamble。这里有一个精妙设计——**preamble 与候选波束通过 RO 绑定**，所以 Msg1 一个比特的 RRC 信令都不用带，gNB 收到 Msg1 就知道 UE 想切到哪个波束。 **第 2 步（C-RNTI 加扰响应）**：这是 BFR 与普通 RACH 最容易混淆、也最关键的差异。普通 4 步 RACH 的 Msg2 用 **RA-RNTI** 加扰，Msg3 之后切换到 **TC-RNTI/C-RNTI**；而 CFRA BFR 的响应直接用 UE 已有的 **C-RNTI** 加扰（因为 UE 本来就处于 RRC Connected，C-RNTI 有效）。UE 在 `recoverySearchSpace` 中只监测 C-RNTI 加扰的 DCI，一旦收到即认为 BFR 成功——**没有 Msg3、没有竞争解决**，CFRA BFR 实质是"两步完成"。 **第 3 步（失败回退）**：若在响应窗口内未收到 C-RNTI 响应，UE 会重传 preamble，重传次数达到 `preambleTransMax-BFR` 仍失败，则**回退到 CBRA**（见第六节）。 **第 4 步（TCI 切换）**：BFR 成功后，UE 的上下行收发波束通过 **TCI State Indication MAC CE** 或带波束指示的 DCI 更新到候选波束 `B_new`，业务无缝继续。 --- ## 五、SCell 的 BFR 机制（Rel-17 增强）：BFR MAC CE PCell 之外，载波聚合（CA）场景下的 SCell 同样会发生波束失败。但 SCell **没有独立的随机接入通道**——UE 的上行控制信令都走 PCell。因此 Rel-17（立项 TR 38.812）将 BFR 扩展到 SCell，采用与 PCell 完全不同的恢复路径：**通过 PCell 上报 BFR MAC CE**。 ### 5.1 SCell BFR 信令流 ```mermaid sequenceDiagram autonumber participant UE_MAC as UE MAC participant gNB as gNB Note over UE_MAC,gNB: 某辅小区 SCell_k 波束失败 UE_MAC->>UE_MAC: 对 SCell_k 声明 Beam Failure
(所有 BFD-RS set 失败) UE_MAC->>gNB: 在 PCell 上发 SR (调度请求)
请求上行授权 gNB->>UE_MAC: UL Grant (PDCCH) UE_MAC->>gNB: BFR MAC CE (上行 MAC PDU)
指示: SCell_k 失败 + 候选波束 id gNB->>UE_MAC: 响应: TCI State MAC CE / DCI
为 SCell_k 指示新波束 Note over UE_MAC,gNB: SCell_k 在新波束恢复 ``` SCell BFR 的核心是用一个 **BFR MAC CE** 把"哪个 SCell 失败、我建议切到哪个候选波束"打包上报。Rel-17 进一步引入 **Enhanced BFR（eBFR）**，支持每个 SCell 配置多个 BFD-RS set（对应多 TRP），可上报更精细的失败信息，对应新的 LCID。 ### 5.2 BFR MAC CE 结构（图解） BFR MAC CE 的逻辑结构如下（以 SCell BFR 为例）： ```mermaid flowchart LR subgraph MAC_SUBHEADER["MAC 子头"] R1["R"] ~~~ LCID["LCID = 56 (BFR)
或 57 (eBFR)"] end subgraph BFR_PAYLOAD["BFR MAC CE 载荷"] C["Ci 比特域
每个 SCell 1 bit
1=该 SCell 失败"] --> P1["对每个失败的 SCell_k:"] P1 --> P2["候选波束 id
(对应 candidateBeamRSList
中 RSRP≥门限的 RS)"] end MAC_SUBHEADER --> BFR_PAYLOAD ``` - **Ci 域**：一个比特图，第 i 位对应第 i 个 SCell，置 1 表示该 SCell 发生了波束失败（PCell 不在此图中，PCell 走随机接入）。 - **候选波束 id**：对于每个置 1 的 SCell，UE 附上为其选定的候选波束在 `candidateBeamRSList` 中的索引。 - **eBFR（Rel-17）**：进一步携带"哪个 BFD-RS set 失败"，以支持多 TRP 场景下的部分失败上报。 设计上，SCell BFR 复用了 PCell 的 SR 机制获取上行授权，避免了在 SCell 上开随机接入通道的复杂度——这是 Rel-17 用最小改动把 BFR 推广到 CA 场景的典型工程取舍。 --- ## 六、CBRA 回退路径 当 PCell 上**无专用 PRACH 资源**（`rach-ConfigBFR` 未为该候选波束配置），或 CFRA 重传耗尽，UE 回退到**基于竞争的随机接入（CBRA）**：执行标准 4 步 RACH（Msg1~Msg4），但**触发原因是 BFR**。CBRA BFR 与普通 RACH 的差别仅在触发源与部分计时器（可被 `ra-Prioritization` 抬升优先级），信令流程与普通 RACH 一致。若 CBRA 也失败，链路最终进入 **RLF → RRC Re-establishment**，此时已超出 BFR 自愈能力。 --- ## 七、RRC 配置 IE 树（BeamFailureRecoveryConfig） BFR 的所有参数都集中在 TS 38.331 的 `BeamFailureRecoveryConfig` IE（挂在 SpCell 配置 / SCell 配置下）。其结构如下： ```mermaid flowchart TD BFRC["BeamFailureRecoveryConfig"] --> RS["候选波束 RS 域"] BFRC --> TH["门限域"] BFRC --> DET["检测域"] BFRC --> RES["恢复资源域"] RS --> RS1["candidateBeamRSList
(SSB / CSI-RS, Rel-16)"] TH --> TH1["rsrp-ThresholdSSB"] TH --> TH2["rsrp-ThresholdCSI-RS"] DET --> DET1["beamFailureDetectionTimer"] DET --> DET2["beamFailureInstanceMaxCount"] RES --> RES1["recoverySearchSpaceId"] RES --> RES2["rach-ConfigBFR
(专用 preamble + RO)"] RES --> RES3["ra-Prioritization"] RES --> RES4["msg1-FrequencyStart /
ra-ssb-OccasionMaskIndex 等"] ``` 这套配置在 UE 进入 RRC Connected 后通过 **RRC Reconfiguration** 一次性下发；当 gNB 调整波束规划（如调整 SSB 发送图样）时，会通过 Reconfiguration 重配 `candidateBeamRSList`。 --- ## 八、三种恢复路径对比（表 2） | 维度 | PCell CFRA BFR | PCell CBRA BFR | SCell BFR (Rel-17) | |---|---|---|---| | 触发条件 | 有有效候选波束且配置专用 RO | 无专用 RO 或 CFRA 耗尽 | SCell 波束失败 | | 信令通道 | SCell/PCell 专用 PRACH | 竞争 PRACH | PCell 的 SR + UL Grant | | 关键消息 | Msg1（专用 preamble）+ C-RNTI 响应 | Msg1~Msg4（4 步） | BFR/eBFR MAC CE | | 响应 RNTI | **C-RNTI** | RA-RNTI → TC-RNTI/C-RNTI | 由 gNB 下发 TCI MAC CE 响应 | | 是否需竞争解决 | 否 | 是 | 否（MAC CE 走已授权资源） | | 时延 | 最低（亚帧级） | 较高 | 中等（依赖 SR 周期） | | 适用场景 | 连接态主波束切换 | 无专用资源时的兜底 | CA 场景辅小区波束自愈 | --- ## 九、实战：抓包/日志识别与排错 ### 9.1 如何在日志中识别 BFR BFR 的 PHY/MAC 过程**不会出现在 N2/N3 接口抓包里**（属于空口 L1/L2），需依赖 UE 侧的诊断日志（高通 QXDM、MTK Elsome、海思 HiSuite log）或 gNB 侧的 trace： - **UE 侧**：搜索 `BFI_COUNTER`、`beam failure instance`、`BFR procedure initiated`、`candidate beam found`、`PRACH for BFR`、`recovery search space`、`BFR success/failure`、`TCI state update` 等关键字； - **MAC CE**：在 MAC 层解析中查找 LCID = 56/57/58（BFR/eBFR/Truncated BFR）的 MAC CE； - **gNB 侧**：可观测到对应 UE 在专用 RO 上的 preamble 接收、C-RNTI 加扰 DCI 的下发。 ### 9.2 常见故障点 1. **`rsrp-ThresholdBFR` 门限设过高**：UE 始终找不到有效候选波束，CFRA 永远不触发，被迫回退 CBRA 甚至 RLF。表现为 BFR 发起率低但 RLF 高。 2. **`recoverySearchSpace` 配置错误/周期过长**：UE 发了 Msg1 却"等不到" C-RNTI 响应，CFRA 重传耗尽。表现为 preambleTransMax-BFR 频繁打满。 3. **`beamFailureInstanceMaxCount` 过小**：单次抖动就触发 BFR，PRACH 资源被无谓占用。 4. **SCell BFR 的 SR 资源不足或周期过长**：BFR MAC CE 迟迟拿不到上行授权，SCell 恢复时延劣化。 5. **`candidateBeamRSList` 与实际 SSB 发送图样不一致**：UE 测的候选波束根本没在发，候选识别永远失败。 ## 常见问题 **Q1：CFRA BFR 的响应为什么用 C-RNTI 而不是 RA-RNTI？** A：因为 UE 在 BFR 前已处于 RRC Connected，C-RNTI 始终有效。BFR 本质是"已有连接的波束切换"而非"全新接入"，用 C-RNTI 加扰可让 gNB 直接确认身份、免去竞争解决，因此 CFRA BFR 实际只需 Msg1 + 响应两步即可完成。 **Q2：SCell 波束失败为什么不直接在 SCell 上发随机接入？** A：SCell 不配置独立的随机接入资源（上行接入与控制信令统一走 PCell）。因此在 SCell 上发 RACH 不可行，Rel-17 改用"在 PCell 上发 BFR MAC CE 上报失败 + 候选波束"的方式完成，复用已有 SR/Grant 通道，改动最小。 **Q3：`beamFailureDetectionTimer` 超时把计数器清零，会不会导致真正的失败被漏判？** A：这是有意的去抖设计。若两次 BFI 间隔超过定时器，说明链路出现恢复迹象，历史抖动不应累积。只要真正持续衰落，BFI 会密集上报，计数器很快达到 `beamFailureInstanceMaxCount`，不会漏判；它过滤的是"间歇性"抖动。 **Q4：BFR 最终失败会怎样？** A：CFRA 失败 → 回退 CBRA；CBRA 再失败 → 触发 RLF，进入 RRC Re-establishment（TS 38.331）。此时业务会中断重建，已超出 BFR 的自愈范畴。这也是为何 `preambleTransMax-BFR` 与候选波束门限的调优对"保话"至关重要。 **Q5：候选波束只能用 SSB 吗？** A：Rel-15 仅支持 SSB 作为候选波束（`rsrp-ThresholdSSB` + SSB 索引）；Rel-16 起引入 CSI-RS 作为候选波束（`rsrp-ThresholdCSI-RS` + 对应 `rach-ConfigBFR` 专用资源），CSI-RS 候选可提供更密集、更灵活的波束粒度，适合多波束扫描场景。 --- ## 参考来源 1. [3GPP TS 38.321 §5.17 — Beam Failure Detection and Recovery procedure](https://itecspec.com/3gpp/38.321/s/5.17) — MAC 层 BFR/BFD 过程原文（Rel-19） 2. [ShareTechnNote — 5G/NR Beam Failure Recovery](https://www.sharetechnote.com/html/5G/5G_BeamFailureRecovery.html) — BFR 教学级流程与参数解析 3. [CafeTele — 5G NR Beam Management (SSB, CSI-RS, BFR)](https://www.cafetele.com/articles/article-5g-nr-beam-management.html) — 基于 TS 38.214/38.213/38.321 的工程师指南 4. [WirelessBrew — 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 步骤与参数详解（含在线 Sandbox） 5. [3glteinfo — 5G Beam Failure Recovery Procedure Call Flow](https://www.3glteinfo.com/call-flows/5g-beam-failure-recovery/) — BFR 呼叫流程与排错要点 --- > 本文由「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 等场景全覆盖。