5G NR在FR2频段(24.25GHz–52.6GHz)采用波束赋形技术实现高速数据传输,但毫米波信号的高方向性使其极易受到遮挡影响——一个人体转身、一辆卡车经过都可能导致服务波束瞬间中断。如果每次波束质量恶化都触发传统的无线链路失败(RLF)重建流程,终端将经历数秒级的服务中断,这对于FWA(固定无线接入)、工业物联网等场景是致命的。
3GPP从Rel-15开始引入波束失败恢复(Beam Failure Recovery, BFR)机制,其核心思想是:在L1/MAC层实现亚百毫秒级的波束级恢复,避免触发RRC层RLF重建。这一机制直接决定了毫米波网络的用户体验和运营商的投资回报。
行业影响层面,全球运营商的毫米波部署策略与BFR性能密切相关: - 美国:Verizon的毫米波FWA覆盖全美超1亿户家庭,BFR恢复时延直接影响宽带可靠性指标 - 欧洲:意大利、德国运营商在3.5GHz+毫米波双频组网中,BFR是保障eMBB体验连续性的关键 - 中国:工信部2023年释放24.75–27.5GHz毫米波频段,《5G规模化应用"扬帆"行动升级方案》明确推动毫米波在工业互联网中的落地,BFR性能成为设备入网测试的核心考核项
BFR机制涉及物理层(TS 38.213)→ MAC层(TS 38.321)→ RRC层(TS 38.331)三层协同,本文将从标准条文出发,逐层拆解其完整信令链路。
BFR机制横跨三个协议层,各层职责清晰划分:

图表 1
BFD的检测依据是波束失败检测参考信号(BFD-RS)的质量。根据TS 38.213 Section 6.17的规范定义,BFD-RS可以是以下两种类型:
| BFD-RS类型 | 配置信元 | 适用场景 | 检测精度 |
|---|---|---|---|
| SS/PBCH Block | beamFailureDetectionRS中配置SSB索引 |
默认场景,覆盖较大区域 | 较低(SSB周期较长) |
| CSI-RS | beamFailureDetectionRS中配置CSI-RS资源 |
精细化场景,高频高速移动 | 较高(CSI-RS更密集) |
检测的核心逻辑(TS 38.213 Section 6.17):
当所有配置的BFD-RS的假设PDCCH BLER均超过10%(即质量低于Qout_LR阈值)时,物理层向MAC层发送一个波束失败实例指示(Beam Failure Instance indication)。
需要强调的是,这里的"质量评估"不是直接测RSRP,而是通过BLER映射间接评估——这是一种保守设计,确保只有真正影响PDCCH解调可靠性时才触发BFI。
BFD-RS通过TS 38.331中的BeamFailureDetectionConfig IE进行配置:
BeamFailureDetectionConfig ::= SEQUENCE {
beamFailureDetectionRS RS_Config, -- BFD参考信号列表
beamFailureInstanceMaxCount ENUMERATED {n1, n2, ..., n256}, -- BFI最大计数
beamFailureDetectionTimer ENUMERATED {pbfd1, pbfd2, ..., pbfd2560} -- 检测定时器
}
关键参数解读:
| 参数 | 含义 | 典型配置值 | 工程调优建议 |
|---|---|---|---|
beamFailureInstanceMaxCount |
连续BFI指示达到此值声明波束失败 | n2–n10 | 高速场景用较大值避免误触发 |
beamFailureDetectionTimer |
BFI计数器重置定时器 | 10ms–100ms | 与UE移动速度匹配 |
rsrp-ThresholdSSB |
SSB型BFD-RS的RSRP门限 | -110dBm ~ -85dBm | 取决于频段和场景 |
rsrp-ThresholdCSI-RS |
CSI-RS型BFD-RS的RSRP门限 | -110dBm ~ -85dBm | 通常比SSB门限高3–5dB |
MAC层收到物理层的BFI指示后,执行以下逻辑(TS 38.321 Section 5.17):

图表 2
设计意图分析: beamFailureDetectionTimer的存在是为了防止偶发性的波束质量恶化被累积计数。例如,当UE经过一个短暂的遮挡物(如行人走过),只会产生1-2次BFI,定时器超时后计数器清零,不会误触发BFR。只有持续性的波束恶化(如UE转入遮挡区域)才会累积达到beamFailureInstanceMaxCount。
根据TS 38.321 Section 5.17.1,BFI计数器在以下任一条件下被重置:
| 重置条件 | 触发原因 | 协议章节 |
|---|---|---|
beamFailureDetectionTimer超时 |
短暂恶化后恢复 | TS 38.321 §5.17.1 |
| BFR成功完成 | 新波束已生效 | TS 38.321 §5.17.2 |
收到BeamFailureRecoveryConfig重配 |
网络侧更新参数 | TS 38.321 §5.17 |
触发RLF(T310超时或随机接入失败) |
波束级恢复失败升级为链路级 | TS 38.321 §5.17 |
| SpCell切换完成 | 切换隐含波束更新 | TS 38.321 §5.17 |
在声明波束失败后,UE必须首先找到一个质量足够好的候选波束。TS 38.321 Section 5.17.2定义了新波束识别(New Beam Identification)过程:
UE扫描candidateBeamRSList中配置的参考信号(SSB或CSI-RS),如果某个候选波束的L1-RSRP满足rsrp-ThresholdSSB或rsrp-ThresholdCSI-RS门限(即Qin_LR),则该波束被视为可用候选。
如果没有找到任何满足门限的候选波束——这是一个严重的场景: - SpCell场景:UE触发RLF重建(TS 38.331 Section 5.3.10.3) - SCell场景:UE通过SpCell发送BFR MAC CE报告失败(Rel-16+)
以下是SpCell BFR基于4-step CFRA的完整信令流程:

图表 3
对于SCell BFR(Rel-16引入),UE不通过PRACH恢复,而是通过在SpCell上发送BFR MAC CE来报告SCell的波束失败:
BFR MAC CE(固定长度):
┌─────────────────────────────────┐
│ R │AC│SCell ID (5bit)│ R │BI│
├─────────────────────────────────┤
│ Candidate Beam Index (8bit) │
└─────────────────────────────────┘
| 字段 | 比特数 | 含义 |
|---|---|---|
| AC (Additional Candidate) | 1 bit | 是否有额外的候选波束信息 |
| SCell ID | 5 bits | 发生波束失败的SCell标识 |
| BI (Beam Index) | 1 bit | 候选波束资源类型(0=SSB, 1=CSI-RS) |
| Candidate Beam Index | 8 bits | 新候选波束的资源索引 |
设计意图: SCell BFR使用MAC CE而非PRACH的原因是——SCell可能没有配置PRACH资源(尤其在CA场景下),通过SpCell转发BFR报告是最可靠的路径。
BFR随机接入支持两种模式,选择逻辑如下:
| 维度 | CFRA(无竞争) | CBRA(基于竞争) |
|---|---|---|
| 前提条件 | 候选波束配置了专用preamble | 候选波束未配置专用preamble |
| 信令流程 | 2-step(Msg1 + RAR) | 4-step(Msg1/2/3/4) |
| 恢复时延 | ~10–20ms | ~30–50ms |
| 碰撞概率 | 无 | 存在 |
| 可靠性 | 高 | 中 |
| 网络配置开销 | 需预分配preamble和RO | 无需预配置 |
| 典型场景 | 网络规划良好的FR2部署 | 候选波束覆盖不足的边缘区域 |
这是理解BFR机制最重要的对比。很多工程师混淆这两个概念,但它们的恢复层级和时延差异巨大:
| 维度 | BFR(波束失败恢复) | RLF(无线链路失败) |
|---|---|---|
| 检测层级 | L1/MAC层 | L3/RRC层 |
| 触发条件 | 所有BFD-RS质量低于Qout_LR | T310超时(基于RLM-RS) |
| 恢复范围 | 波束级切换 | 小区级重建立 |
| 恢复时延 | 10–50ms | 500ms–数秒 |
| 是否保持RRC连接 | 是 | 否(需RRC重建) |
| 数据中断 | 短暂(仅上行) | 长时间(需重新建立安全上下文) |
| 信令开销 | 极小(1个PRACH+1个DCI) | 大(RRC Setup + Security + Reconfig) |
| 规范章节 | TS 38.321 §5.17 | TS 38.331 §5.3.10 |
关键洞察: BFR是在RLF之前的一道"防线"。如果BFR成功,永远不会触发RLF。只有在BFR失败(如beamFailureRecoveryTimer超时、无候选波束可用)后,才会升级为RLF。
TS 38.331定义的BeamFailureRecoveryConfig IE是BFR过程的核心配置:
| 参数 | 类型 | 含义 | 影响BFR的哪个阶段 |
|---|---|---|---|
candidateBeamRSList |
列表 | 候选波束参考信号集合 | 新波束识别 |
rsrp-ThresholdSSB |
整数 | SSB候选波束的L1-RSRP门限 | 新波束识别 |
rsrp-ThresholdCSI-RS |
整数 | CSI-RS候选波束的L1-RSRP门限 | 新波束识别 |
ra-PreambleIndex |
整数 | 每个候选波束关联的专用preamble | BFR随机接入 |
ra-OccasionList |
列表 | 每个候选波束关联的PRACH occasion | BFR随机接入 |
recoverySearchSpaceId |
整数 | BFR响应的搜索空间标识 | gNB响应接收 |
beamFailureRecoveryTimer |
枚举 | BFR恢复定时器(ms级) | BFR失败判断 |

图表 4
FWA(固定无线接入)是毫米波最先规模商用的场景。以Verizon为例,其毫米波FWA需要满足固网宽带的SLA要求(如99.9%可用性),BFR参数配置直接影响这一指标:
场景分析: 一个位于城市边缘的FWA CPE,主服务波束被新建建筑遮挡:
- beamFailureInstanceMaxCount = n3(连续3次BFI声明失败):恢复启动快,但可能因短暂遮挡误触发
- beamFailureInstanceMaxCount = n10(连续10次BFI):减少误触发,但持续恶化场景下恢复时延增加
- 工程折中: 对于固定位置的CPE,建议n3–n5;对于移动场景(车载FWA),建议n8–n10
工信部2023年批复24.75–27.5GHz频段用于5G毫米波试验,并在《5G规模化应用"扬帆"行动升级方案》中提出: - 推动毫米波在工业互联网、智慧矿山、FWA等场景的规模化应用 - 设备入网测试中,BFR相关性能(恢复时延、成功率)是必测项 - 运营商集采对毫米波基站的BFR恢复时延要求:<50ms(CFRA模式)
在5G NR L1/L2抓包(如使用高通QXDM、罗德斯施瓦茨的5G信令分析仪)中,BFR相关的关键事件标识:
| 抓包事件 | 含义 | 对应标准章节 |
|---|---|---|
NR5G MAC BFI Indication |
物理层发送BFI到MAC | TS 38.213 §6.17 |
NR5G MAC BFR Triggered |
MAC层声明波束失败并启动BFR | TS 38.321 §5.17 |
NR5G MAC BFR RA Initiated |
BFR随机接入过程启动 | TS 38.321 §5.17.2 |
NR5G MAC BFR Msg1 Sent |
PRACH preamble发送 | TS 38.321 §5.1 |
NR5G MAC BFR Success |
BFR成功完成 | TS 38.321 §5.17.2 |
NR5G RRC RLF Indication |
BFR失败升级为RLF | TS 38.331 §5.3.10 |
故障1:BFR频繁触发但始终失败
现象:日志中反复出现BFR Triggered → BFR RA Initiated → beamFailureRecoveryTimer Expired → RLF。
排查方向:
1. 检查candidateBeamRSList是否包含覆盖当前UE位置的候选波束
2. 检查rsrp-ThresholdSSB/CSI-RS门限是否设置过高
3. 检查候选波束关联的PRACH occasion是否被其他UE占用(CFRA场景罕见,但可能)
4. 检查gNB侧recoverySearchSpaceId配置的搜索空间是否正确映射到新波束
故障2:BFR误触发(频繁声明但质量实际正常)
排查方向:
1. beamFailureInstanceMaxCount值过小
2. beamFailureDetectionTimer值过小
3. BFD-RS资源配置不合理(如仅配置了1个SSB,该SSB短暂波动即触发BFI)
4. 检查是否存在外部干扰导致BFD-RS测量不准确
故障3:BFR成功但数据面未恢复
排查方向: 1. gNB侧未将新波束映射到PDSCH/PUSCH的TCI state 2. 波束恢复后的第一个DCI仍指向旧波束(gNB实现bug) 3. MAC CE调度在新波束上失败(如TA不合适)
| Release | 增强特性 | 核心规范 | 实际价值 |
|---|---|---|---|
| Rel-15 | SpCell BFR基本框架(CFRA/CBRA) | TS 38.321 §5.17 | 基础波束恢复能力 |
| Rel-16 | SCell BFR(通过MAC CE报告) | TS 38.321 §5.17.3 | CA场景下SCell波束恢复 |
| Rel-16 | 基于CBRA的BFR增强 | TS 38.321 §5.17.2 | 候选波束无专用preamble时的恢复 |
| Rel-17 | Multi-BFR(多TRP同时恢复) | TS 38.321 §5.17.4 | 提升multi-TRP鲁棒性 |
| Rel-18 | L1/L2移动性中的BFR集成 | TS 38.321/38.213 | 波束恢复与小区间切换协同 |
Q1: BFR中的CFRA preamble与普通随机接入的dedicated preamble有什么区别?
A: 本质上PRACH preamble格式相同,区别在于用途和关联关系。BFR的CFRA preamble通过BeamFailureRecoveryConfig中的ra-PreambleIndex配置,与特定候选波束(SSB/CSI-RS索引)绑定——UE选择哪个候选波束,就使用该波束关联的preamble。普通随机接入的dedicated preamble通过RACH-ConfigDedicated配置,用于切换等场景。两者不能冲突,网络侧需确保preamble索引在BFR和普通RACH之间不重复分配。
Q2: BFR失败后一定会触发RLF吗?有没有重试机制?
A: 根据TS 38.321 Section 5.17,对于SpCell BFR,当beamFailureRecoveryTimer超时时,MAC层直接将BFR失败指示给RRC层,RRC层启动RLF流程(TS 38.331 §5.3.10.3)。标准中没有定义BFR的重试机制——这是因为BFR失败意味着所有候选波束都无法接入,重试意义不大。但UE在RLF重建成功后,会在新小区上重新开始BFD监测。
Q3: SCell BFR为什么不使用PRACH而使用MAC CE?
A: 两个原因:(1)SCell可能没有配置PRACH资源——在CA场景下,通常只有SpCell配置PRACH,SCell仅用于数据传输;(2)即使SCell有PRACH,通过SpCell发送MAC CE的时延更可控(SpCell链路质量通常优于发生波束失败的SCell)。MAC CE方式避免了在"已失败"的SCell上发起随机接入的悖论。
Q4: BFR搜索空间(recoverySearchSpaceId)为什么要独立配置?
A: 因为BFR发生在当前服务波束已失败的时刻,UE无法在原波束的PDCCH搜索空间上接收响应。recoverySearchSpaceId指向新候选波束对应的搜索空间,确保gNB的BFR响应能够在新波束方向上被UE正确接收。如果复用原有搜索空间,响应会在UE无法接收的波束上发送,导致BFR必然失败。
Q5: 毫米波FWA场景下,BFR参数应该如何优化?
A: FWA CPE位置固定,波束失败主要由环境变化(车辆、树木生长、建筑施工)导致。推荐配置:(1)beamFailureInstanceMaxCount = n3(固定场景下误触发概率低,可快速响应);(2)beamFailureDetectionTimer = 20ms(不宜过长);(3)candidateBeamRSList至少包含6–8个候选波束(覆盖CPE周围各方向);(4)优先使用CSI-RS作为BFD-RS和候选波束参考信号(精度更高)。同时建议FWA CPE支持TR 36.913定义的波束恢复时延<30ms的KPI。
本文由「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 等场景全覆盖。
