# 5G NR 波束失败恢复（BFR）机制全链拆解：从 BFD 检测到 CFRA 重建 ## 一、为什么 5G NR 必须发明 BFR？ 5G NR 在 FR2（毫米波，24.25–52.6 GHz）频段普遍采用模拟波束成形（Analog Beamforming），下行通过 SS/PBCH Block（SSB）或 CSI-RS 形成窄波束轮询覆盖，UE 与 gNB 之间依赖一个"最优波束对（Beam Pair Link, BPL）"维持控制面和数据面连接。与 LTE 全向/宽波束覆盖截然不同，毫米波波束宽度通常只有 5°–15°，一旦 UE 高速移动、人体遮挡（body blockage）、旋转手柄，或对面反射体环境突变，原有 BPL 的能量可能在毫秒级时间内衰减 20–40 dB，导致 UE 完全收不到 PDCCH。 在 LTE 时代，这种链路质量突变只能依赖**无线链路失败（RLF）+ RRC 重建立**来兜底，整个过程涉及 T310/T311 计时器、小区重选，端到端时延可达数百毫秒甚至秒级，对 eMBB 体验已是伤害，对 URLLC 更是不可接受。3GPP 在 TS 38.213 第 6 章和 TS 38.321 第 5.17 节专门定义了一套**亚层间、不触发 RRC 重建立**的快速恢复机制——**Beam Failure Detection & Recovery（BFD/BFR）**，让 UE 在检测到波束失败的瞬间，直接在一条候选波束上发起无竞争随机接入（CFRA），在数毫秒内把"波束对"切换到新方向，而 RRC 连接、安全上下文、PDU 会话状态全部保持不变。这就是 BFR 的设计本源：**把"波束级"的链路中断，从 RRC 层下沉到 MAC/PHY 层来愈合**。 本文按"检测 → 候选识别 → 恢复请求（BFRQ）→ 恢复响应 → MAC CE 确认 → 完成"六个阶段，逐 IE 拆解 TS 38.213/38.321/38.331 中定义的完整机制，并补充 Rel-16/17 引入的 SCell BFR 增强。 --- ## 二、整体状态转换与责任分层 BFR 是一个跨 PHY/MAC/RRC 三层的协作过程，需要先建立宏观状态视图，再进入逐消息拆解。 ```mermaid stateDiagram-v2 [*] --> 正常波束通信: 初始激活BPL 正常波束通信 --> BFD计数累加: 所有BFD-RS质量 < Qout BFD计数累加 --> 正常波束通信: 任一BFD-RS质量恢复(计数清零) BFD计数累加 --> 波束失败声明: 连续计数 = beamFailureInstanceMaxCount 波束失败声明 --> 候选波束识别: 测量candidateBeamRSList 候选波束识别 --> BFRQ发送: 找到RSRP >= 阈值的候选 候选波束识别 --> RLF重建立: 无合格候选波束 BFRQ发送 --> 等待BFR响应: CFRA(Msg1)或CBRA 等待BFR响应 --> BFR成功: 收到C-RNTI加扰PDCCH 等待BFR响应 --> RLF重建立: preambleTransMax耗尽 BFR成功 --> 正常波束通信: 新BPL接管 RLF重建立 --> [*]: T310/T311流程 ``` 这里的关键设计哲学是**双重保险**：BFR 是 RLF 之前的一道"快速止血带"。只有当 BFR 也失败（候选波束全无、或 PRACH 攀升到 `preambleTransMax` 仍未获响应），UE 才回退到传统 RLF 流程。两者之间通过 MAC 计数器隔离，互不干扰。 --- ## 三、阶段一：波束失败检测（BFD） ### 3.1 检测依据：Qout 与"假想 PDCCH BLER" BFD 的核心难点在于：UE 此时已经收不到 PDCCH 了，它怎么知道是"波束坏了"而不是"没被调度"？3GPP 给出的答案是**基于参考信号的假想 PDCCH BLER**。 UE 被 RRC 配置一个或多个 **BFD-RS 集合（failureDetectionResources）**，通常包含与 PDCCH DMRS 具有准共址（QCL）关系的 CSI-RS 或 SSB 资源。UE 在这些资源上估计能量，映射到一个假想的 PDCCH（聚合等级 AL、TBS 固定）上计算 BLER： - **Qout（失效阈值，out-of-sync）**：对应假想 PDCCH BLER = **10%** 的能量边界。当所有被监测 BPL 的质量都低于 Qout 时，PHY 向 MAC 上报一次 **BFI（Beam Failure Instance，波束失败实例）**。 - **Qin（同步阈值，in-sync）**：对应假想 PDCCH BLER = **2%** 的能量边界（与 RLF 的 Qout/Qin 复用同一思想）。 ### 3.2 MAC 计数器与去抖动逻辑 收到一个 BFI 后，MAC 实体按 TS 38.321 §5.17 执行： 1. 启动/重启 `beamFailureDetectionTimer`； 2. 将计数器 `BFI_COUNTER` 加 1； 3. 若 `BFI_COUNTER >= beamFailureInstanceMaxCount`，则**声明波束失败（Beam Failure）**，立即触发阶段二。 `beamFailureInstanceMaxCount` 由 RRC 配置（典型取值 2/3/4/5/6/8/10/20），它本质是一个**时间去抖动**窗口——避免一次瞬时阴影（如车辆驶过）就误判失败。计数器在收到任一 in-sync 指示、或高层重配时清零。 > **设计意图**：把"链路质量"判定从绝对的 RSRP 绝对值，转换为相对的"PDCCH 可解调概率"，使其天然适配任意频段、任意波束宽度、任意 MCS，无需为每条链路单独标定能量门限。 ```mermaid flowchart TD A[PHY测量BFD-RS集合] --> B{所有BPL < Qout?} B -- 否 --> C[可能上报in-sync,计数清零] B -- 是 --> D[PHY上报BFI实例] D --> E[MAC: 启动/重启beamFailureDetectionTimer] E --> F[BFI_COUNTER + 1] F --> G{BFI_COUNTER >= MaxCount?} G -- 否 --> A G -- 是 --> H[声明波束失败 → 进入候选识别] C --> A ``` --- ## 四、阶段二：候选波束识别（Candidate Beam Identification） 声明失败后，UE 并非盲目发起随机接入，而是要先**自检是否有一条可用的新波束**，否则发起 BFRQ 也是浪费。 UE 测量 RRC 配置的 **`candidateBeamRSList`**（同样由 CSI-RS 和/或 SSB 组成），对每个资源计算 RSRP，并与 `rsrp-ThresholdBFR`（CSI-RS 和 SSB 可分别配置）比较： - 若存在某资源 RSRP ≥ 阈值，则该资源对应的波束被选为**候选波束（candidate beam）**，进入阶段三； - 若遍历全部资源都低于阈值，UE 直接**放弃 BFR，触发 RLF**（因为连"候选"都没有，说明整个区域信号都塌了）。 候选波束识别的成功与否，决定了后续使用 **CFRA（无竞争）** 还是 **CBRA（基于竞争）**： | 候选波束状态 | 是否配置专用前导码 | 采用的随机接入类型 | 说明 | |---|---|---|---| | 找到候选波束 | 该波束有 dedicated preamble | **CFRA** | 1:1 映射，Msg1 仅发一次，最快 | | 找到候选波束 | 无 dedicated preamble | **CBRA** | 回退到竞争接入，需 Msg3 冲突解决 | | 无候选波束 | — | 不发起 BFRQ | 直接 RLF | 这种"先自检、再动手"的设计，避免了在完全无覆盖区域发起无意义的 PRACH，节省 UE 功耗和上行干扰。 --- ## 五、阶段三：恢复请求（BFRQ）——四步 / 两步随机接入 BFRQ 本质是**一次 PRACH 随机接入过程**，但接入的目的不再是"初始接入网络"，而是"声明我换了波束，请在新波束上调度我"。 ### 5.1 CFRA（无竞争）——SpCell BFR 的首选路径 网络通过 `BeamFailureRecoveryConfig` 为每个候选波束（用其 SSB/CSI-RS 索引标识）预先分配一个**专用前导码（dedicated preamble）**和对应的 **PRACH 时机（RO, RACH Occasion）**。UE 在选定的候选波束对应的 RO 上发送该前导码，gNB 一看到这个特定前导码，就同时知道了**"是哪个 UE（C-RNTI）"+"UE 想换到哪个波束"**，因为映射是 1:1 的。 CFRA 仅发送**一次** Msg1（`preambleTransMax` 不适用），不进行功率攀升。 ### 5.2 CBRA（基于竞争）回退路径 若候选波束没有专用前导码，UE 在该波束的 RO 上随机选择一个**竞争前导码**发送，流程退化为标准 4-step RACH：Msg1（前导码）→ Msg2（RAR，分配 TC-RNTI 与 UL grant）→ **Msg3（携带 BFR MAC CE + C-RNTI MAC CE）** → Msg4（用 C-RNTI 加扰的 PDCCH 解决冲突）。 ### 5.3 完整 BFR 信令时序 ```mermaid sequenceDiagram participant UE participant PHY_UE as UE PHY participant MAC_UE as UE MAC participant gNB participant gNB_MAC as gNB MAC Note over UE,gNB: 阶段一：BFD检测 MAC_UE->>PHY_UE: 已配置BFD-RS集合(failureDetectionResources) PHY_UE->>MAC_UE: BFI实例(所有BPL>MAC_UE: BFI_COUNTER++, 重启beamFailureDetectionTimer PHY_UE->>MAC_UE: BFI实例(连续第N次) MAC_UE->>MAC_UE: BFI_COUNTER=MaxCount → 声明波束失败 Note over UE,gNB: 阶段二：候选识别 MAC_UE->>PHY_UE: 测量candidateBeamRSList PHY_UE->>MAC_UE: 候选波束X的RSRP >= rsrp-ThresholdBFR MAC_UE->>MAC_UE: 选中波束X(有dedicated preamble → CFRA) Note over UE,gNB: 阶段三：BFRQ(CFRA Msg1) MAC_UE->>gNB: PRACH Msg1: 专用前导码(映射波束X), 单次, 不攀升功率 Note over UE,gNB: 阶段四：BFR响应监测 gNB->>UE: PDCCH: RA-RNTI加扰 → RAR(含TC-RNTI/Timing Advance) Note over UE: UE在recoverySearchSpaceId搜索空间监听
而非普通RA搜索空间 Note over UE,gNB: 阶段五：MAC CE确认(Msg3) MAC_UE->>gNB: Msg3: BFR MAC CE(16bit) + C-RNTI MAC CE
指示已恢复到波束X Note over UE,gNB: 阶段六：完成 gNB->>UE: PDCCH: C-RNTI加扰(非TC-RNTI) Note over UE,gNB: BFR成功! 新BPL接管, RRC连接不变 ``` --- ## 六、关键 IE 深度拆解 ### 6.1 RRC 配置 IE：`BeamFailureRecoveryConfig` 该 IE 在 TS 38.331 中定义，通过 `RadioLinkMonitoringConfig` 的兄弟字段、或直接挂在 ServingCellConfig 下，承载全部 BFR 参数： | IE 字段 | 取值/类型 | 作用 | |---|---|---| | `beamFailureInstanceMaxCount` | enum: n1/n2/n3/.../n20 | BFI 计数上限，触发失败声明 | | `beamFailureDetectionTimer` | ms | BFI 计数去抖计时器 | | `rsrp-ThresholdBFR` | RSRP 索引 | 候选波束合格门限 | | `candidateBeamRSList` | SSB/CSI-RS ID 列表 | 候选波束测量资源集 | | `ssb-ResourceRSRP / csirs-ResourceRSRP` | 对应测量量 | 分别针对 SSB/CSI-RS 的 RSRP 上报 | | `recoverySearchSpaceId` | SearchSpace ID | **BFR 响应专用搜索空间**（区别于普通 RACH 搜索空间） | | `ra-Prioritization` | struct | BFR RACH 的优先级/功率提升 | | `msg1-SubcarrierSpacing` | SCS | BFR Msg1 子载波间隔 | ### 6.2 BFR MAC CE 结构（TS 38.321 §6.1.3.x） BFR MAC CE 是一个**固定 16 比特**的控制元素，通过 Msg3 上报，逻辑上紧跟一个 C-RNTI MAC CE（用于让 gNB 用旧 C-RNTI 定位 UE，而非 RAR 分配的临时 TC-RNTI）： ``` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SP / SI 域 | 候选波束索引域 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-RNTI (隐式, 单独MAC CE) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` - **SP（Spatial Relation）/SI 域**：指示所恢复到的候选波束对应的参考信号资源 ID（SSB 索引或 CSI-RS 索引），告诉 gNB "我接下来请用这个波束对我做 spatial filter"； - 该 MAC CE 通过 LCID 特定值标识（区别于普通 CCCH/DCCH 数据）。 > **为什么用 MAC CE 而非 RRC 信令？** 因为 BFR 必须在毫秒级完成，RRC 过程涉及 ASN.1 编解码、确认重传，时延不可控；MAC CE 走 MAC 子头复用，一条 Msg3 即可携带，是"快路径"的正确载体。 --- ## 七、阶段四/五/六：响应监测、确认与完成 ### 7.1 专用搜索空间（recoverySearchSpaceId） 一个极易被忽视但极其关键的细节：BFR 响应（RAR）的监听，**不使用普通 RACH 配置的搜索空间**，而使用 RRC 单独配置的 `recoverySearchSpaceId`。这样设计有两个好处： 1. gNB 可以用更激进的 PDCCH 聚合等级（更高 AL）和更密的监听周期，确保在最差波束条件下 UE 仍能解到响应； 2. 与普通 RACH/数据调度解耦，避免 BFR 期间被普通 DCI 抢占监听机会。 ### 7.2 成功判据：C-RNTI 加扰的 PDCCH BFR 完成的**唯一判据**是：UE 在 `recoverySearchSpaceId` 上收到一个**用其 C-RNTI 加扰的 PDCCH**（而非 RA-RNTI 或 TC-RNTI）。一旦收到，意味着 gNB 已经接受新波束、并开始在它上面正常调度该 UE，BFR 流程正式结束，MAC 计数器清零，RRC 层全程无感知。 ### 7.3 失败回退 若 `preambleTransMax`（CBRA 场景）或 CFRA 响应超时仍未收到任何 PDCCH，UE 放弃 BFR，置起 RLF 标志，进入 T310→T311 的 RRC 重建立流程——此时才真正动到 RRC 层。 --- ## 八、Rel-16/17 演进：从 SpCell BFR 到 SCell BFR ### 8.1 Rel-15：仅 SpCell Rel-15 的 BFR 只覆盖 **SpCell**（主小区组的主小区），因为只有 SpCell 承载 PDCCH 命令链路。 ### 8.2 Rel-16：SCell BFR（载波聚合下的辅小区波束恢复） 随着 CA（Carrier Aggregation）在毫米波广泛部署，一个 SCell 的波束也可能因遮挡失效。Rel-16（TR 38.812 立项，落地于 TS 38.213/38.321）引入 **SCell BFR**： - SCell 失败**不触发随机接入**（SCell 无 PRACH 配置），而是通过 **MAC CE 显式上报**：UE 在 SpCell 上发送一个 **BFR MAC CE**，其中带一个位图（bitmap）指示**哪个/哪些 SCell 失败**，以及对应的候选波束 ID； - gNB 收到后，在 SpCell 上对相应 SCell 重新配置 TCI 状态，完成波束切换； - 这把 SCell 的波束愈合时延从"等到 RLF"压缩到一次 MAC CE 往返。 ### 8.3 SpCell BFR 与 SCell BFR 对比 | 维度 | SpCell BFR | SCell BFR | |---|---|---| | 适用小区 | PCell / PSCell | 辅载波 SCell | | 恢复信令 | CFRA/CBRA 随机接入 | **MAC CE 上报**（在 SpCell 发送） | | 触发条件 | BFD-RS 全部 < Qout | 同 BFD 逻辑 | | 候选波束指示 | PRACH 专用前导码 1:1 | BFR MAC CE 中的位图 + 候选 ID | | 是否影响 RRC | 否 | 否 | | 引入版本 | Rel-15 | Rel-16 | --- ## 九、实战连接：抓包识别与排错 ### 9.1 抓包如何识别 BFR 流程 BFR 主要发生在 Uu 口（空口），在 UE 侧 log（如 Qualcomm QXDM、Mediatek Elayne、srsUE log）中的识别特征： 1. **BFI 计数日志**：连续出现 `BFI_IND` / `beam failure instance`，且 `BFI_COUNTER` 累加到 `beamFailureInstanceMaxCount`； 2. **PRACH 前导码索引异常**：在某 SSB/CSI-RS 对应 RO 上发送的前导码索引，落在专用前导码范围（非竞争区），且 `RA purpose = BFR`； 3. **搜索空间切换**：RAR 监听从普通 `ra-SearchSpace` 切到 `recoverySearchSpaceId`； 4. **Msg3 内容**：MAC PDU 中出现 LCID 指向 BFR MAC CE + C-RNTI MAC CE，而非 CCCH（这是与初始接入最显著的区别）。 在 gNB 侧（如 O-RAN O-DU log / 厂家基带日志），可看到：专用前导码接收 → TC-RNTI 分配 → C-RNTI 加扰 PDCCH 下发。 ### 9.2 常见故障点 | 现象 | 可能根因 | 排查方向 | |---|---|---| | BFI 频繁触发但始终未到 MaxCount | 边缘覆盖波动 | 检查 `beamFailureInstanceMaxCount` 是否过小，或 BFD-RS 配置是否合理 | | BFRQ 发出但无 RAR | 候选波束实际不可用 / RO 配置错误 | 核验 `candidateBeamRSList` 与 RO-SSB 映射；检查 UE 功率余量 | | RAR 收到但后续 PDCCH 无 C-RNTI | gNB 未识别 BFR MAC CE / 厂家兼容 | 检查 Msg3 LCID；查 gNB MAC CE 解析 | | 频繁 BFR 后仍 RLF | 候选波束全部低于阈值 | 整体覆盖问题，需 RF 优化而非参数调优 | ## 十、常见问题 **Q1：BFR 失败和 RLF 是什么关系？** A：BFR 是 RLF 的"前置快速止血"机制。BFD 声明失败后先尝试 BFR（亚层间恢复，不动 RRC）；只有 BFR 也失败（无候选波束或 PRACH 攀升耗尽），才升级为 RLF，触发 RRC 重建立。两者通过 MAC 计数器与时序隔离，BFR 成功则 RLF 流程完全不启动。 **Q2：CFRA 和 CBRA 在 BFR 中如何选择？** A：取决于候选波束是否被预分配了专用前导码。有则 CFRA（Msg1 单次、无竞争、最快）；无则回退 CBRA（标准 4 步接入，需 Msg3 冲突解决）。运营商/厂商通过 `BeamFailureRecoveryConfig` 中的专用前导码分配范围决定路径。 **Q3：为什么 BFR 响应要用单独的搜索空间 `recoverySearchSpaceId`？** A：因为波束失败时 UE 处于最差接收条件下，专用搜索空间允许 gNB 用更高聚合等级、更密监听周期下发 RAR，并与普通数据/RA 调度解耦，确保恢复信令在最差波束下也可解。 **Q4：SCell BFR 为什么不发起随机接入？** A：SCell 通常不配置 PRACH 资源（PRACH 主要在 SpCell），且 SCell 失效时 UE 仍可通过 SpCell 与网络通信。因此 SCell BFR 改用"在 SpCell 上发送 BFR MAC CE（带失败 SCell 位图 + 候选波束）"的方式上报，gNB 据此重配 TCI 状态，省去空口随机接入开销。 **Q5：BFR MAC CE 携带的 C-RNTI 起什么作用？** A：Msg3 中的 C-RNTI MAC CE 让 gNB 用 UE 的永久 C-RNTI 定位它（而非 RAR 临时分配的 TC-RNTI），随后 gNB 直接用 C-RNTI 加扰 PDCCH 完成冲突解决与调度，这是 BFR 与初始接入在 Msg3/Msg4 阶段的关键差异。 --- ## 参考来源 1. [3GPP TS 38.213 — NR; Physical layer procedures for control](https://www.3gpp.org/dynareport/38213.htm) — Section 6: Beam failure detection and recovery（PHY 层 Qout/Qin、候选波束 RSRP、PRACH 映射） 2. [3GPP TS 38.321 — NR; MAC protocol specification](https://www.3gpp.org/dynareport/38321.htm) — Section 5.17 BFD/BFR 过程、Section 6.1.3.x BFR MAC CE 定义 3. [3GPP TS 38.331 — NR; Radio Resource Control (RRC)](https://www.3gpp.org/dynareport/38331.htm) — `BeamFailureRecoveryConfig` 等 IE 定义 4. [ShareTechnote — 5G/NR Beam Failure Recovery](https://www.sharetechnote.com/html/5G/5G_BeamFailureRecovery.html) — BFR 流程图解与参数说明 5. [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 工具 6. [3GPP Explorer — BFR Glossary](https://3gpp-explorer.com/glossary/bfr/) — Rel-16 引入与规范索引 --- > 本文由「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 等场景全覆盖。