在5G NR高频段(FR2,24.25GHz–52.6GHz)部署中,波束赋形(Beamforming)是物理层的核心传输手段。然而,高频信道对遮挡、人体移动、雨衰等因素极其敏感,服务波束可能在毫秒级突然恶化——这不是小区级无线链路失败(RLF),而是波束级的链路中断。
如果每次波束失败都触发RRC重建,时延高达数百毫秒,完全无法满足URLLC等场景的可靠性要求。为此,3GPP在TS 38.321 Section 5.17引入了Beam Failure Recovery(BFR)机制——一个纯MAC层的快速恢复过程,目标是在几十毫秒内完成波束切换,无需RRC介入。
BFR的设计哲学可概括为三层递进:
与LTE的同步/失步指示不同,NR BFD采用假设PDCCH BLER作为判决基准。物理层为每个BFD-RS资源计算一个"假设在当前波束质量下PDCCH的误块率":
BFD-RS可以是: - SSB(SS/PBCH Block):默认参考信号,无需额外配置 - CSI-RS:周期性配置,精度更高,适用于Rel-16+增强场景
flowchart TD
A[UE持续监测BFD-RS] --> B{假设BLER > Q_out?}
B -->|是| C[向MAC层发送BFI指示]
B -->|否| D[不发送BFI<br>当前波束质量正常]
C --> E[MAC层: BFI_COUNTER++]
E --> F{BFI_COUNTER ≥<br>beamFailureInstanceMaxCount?}
F -->|否| G[等待下一个BFD评估时机]
F -->|是| H[触发波束失败指示<br>Beam Failure Indication]
D --> A
G --> A
H --> I[启动新波束搜索<br>New Beam Identification]
BFD-RS资源通过RRC Reconfiguration中的BeamFailureRecoveryConfig和RadioLinkMonitoringConfig配置:
| RRC参数 | 含义 | 典型取值 |
|---|---|---|
beamFailureDetectionTimer |
BFI计数器重置定时器 | 10/20/40/80/160/320 ms |
beamFailureInstanceMaxCount |
触发BFR所需的最大BFI计数 | 1/2/3/4/5/6/7/8 |
failureDetectionResources |
BFD-RS资源列表(SSB/CSI-RS索引) | 配置的SSB或CSI-RS |
rsrp-ThresholdSSB |
SSB候选波束的L1-RSRP门限 | -140 ~ -44 dBm |
rsrp-ThresholdCSI-RS |
CSI-RS候选波束的L1-RSRP门限 | -140 ~ -44 dBm |
candidateBeamRSList |
新波束候选列表 | SSB/CSI-RS资源集合 |
recoverySearchSpaceId |
BFR响应的PDCCH搜索空间 | 专用SearchSpace ID |
beamFailureRecoveryTimer |
BFR整体恢复定时器 | 1/2/4/8/16/32/64/128 ms |
当MAC层确认波束失败后,UE立即执行候选波束扫描。UE对candidateBeamRSList中配置的所有参考信号进行L1-RSRP测量:
rsrp-ThresholdSSB → 该波束合格rsrp-ThresholdCSI-RS → 该波束合格UE选择RSRP最强的合格波束作为恢复目标。此时面临一个关键分支——CFRA与CBRA的选择。
flowchart TD
A[波束失败指示触发] --> B[扫描candidateBeamRSList]
B --> C{候选波束中是否有<br>专用Preamble分配?}
C -->|有: BFR-SSB-Resource<br>或BFR-CSIRS-Resource已配置| D[选择CFRA路径<br>Contention-Free RA]
C -->|无: 该候选波束<br>未分配专用Preamble| E[选择CBRA路径<br>Contention-Based RA]
D --> F[在目标波束上<br>发送专用PRACH Preamble]
E --> G[在目标波束上<br>随机选择PRACH Preamble]
F --> H[启动beamFailureRecoveryTimer<br>监听recoverySearchSpace]
G --> H
H --> I{收到C-RNTI加扰的DCI?}
I -->|是| J[BFR成功<br>重置BFI_COUNTER]
I -->|Timer超时| K{重传次数<最大?}
K -->|是| F
K -->|否| L[BFR失败<br>触发RLF→RRC重建]
CFRA(Contention-Free Random Access)是BFR的首选路径。gNB通过RRC为每个候选波束预分配专用的PRACH Preamble和对应的PRACH时频资源:
ra-PreambleIndex(专用Preamble索引)ra-ssb-OccasionMaskIndex或CSI-RS关联的PRACH时机确定当以下条件满足时,UE回退到CBRA:
1. 所选候选波束未配置专用Preamble
2. CFRA尝试失败(Timer超时且无gNB响应)
3. candidateBeamRSList中无合格波束(需在任意波束上尝试)
CBRA走完整的四步RA流程(Msg1→Msg2→Msg3→Msg4),时延更长且存在碰撞风险。
sequenceDiagram
participant UE as UE (MAC/PHY)
participant gNB as gNB
Note over UE,gNB: Phase 1: Beam Failure Detection
UE->>UE: 监测BFD-RS (SSB/CSI-RS)
UE->>UE: 假设BLER计算 > Q_out
UE->>UE: PHY→MAC: BFI指示 #1
UE->>UE: BFI_COUNTER = 1
Note over UE: beamFailureDetectionTimer运行中
UE->>UE: PHY→MAC: BFI指示 #2
UE->>UE: BFI_COUNTER = 2
UE->>UE: PHY→MAC: BFI指示 #N
UE->>UE: BFI_COUNTER = N ≥ maxCount
UE->>UE: 触发Beam Failure Indication
Note over UE,gNB: Phase 2: New Beam Identification
UE->>UE: 测量candidateBeamRSList
UE->>UE: 选择L1-RSRP最强的合格波束
alt CFRA路径(首选)
Note over UE,gNB: Phase 3a: CFRA BFR
UE->>gNB: Msg1: PRACH Preamble (专用)<br>在新波束对应的RO上发送
Note over UE: 启动beamFailureRecoveryTimer<br>监听recoverySearchSpace
gNB->>UE: BFR Response: PDCCH DCI 1_0<br>C-RNTI加扰
Note over UE: BFR成功, BFI_COUNTER重置为0
else CBRA路径(回退)
Note over UE,gNB: Phase 3b: CBRA BFR
UE->>gNB: Msg1: PRACH Preamble (随机选择)<br>在共享RO上发送
gNB->>UE: Msg2: RAR (RA-RNTI加扰)<br>含TA、UL Grant、TC-RNTI
UE->>gNB: Msg3: RRC连接恢复请求 / C-RNTI MAC CE
gNB->>UE: Msg4: 竞争解决 (TC-RNTI/C-RNTI加扰)
Note over UE: BFR成功, BFI_COUNTER重置为0
end
Note over UE,gNB: Phase 4: 恢复正常通信
gNB->>UE: 后续下行数据在新波束上传输
UE->>gNB: 后续上行数据在新波束上发送
stateDiagram-v2
[*] --> Normal: RRC连接建立<br>BFD-RS配置完成
Normal --> BFI_Counting: 收到第1个BFI<br>BFI_COUNTER=1<br>启动BFD_Timer
BFI_Counting --> Normal: BFD_Timer超时<br>且BFI_COUNTER < maxCount<br>重置BFI_COUNTER=0
BFI_Counting --> BeamFailure: BFI_COUNTER ≥ maxCount<br>触发Beam Failure Indication
BeamFailure --> NewBeamSearch: 立即启动候选波束扫描
NewBeamSearch --> CFRA: 找到合格波束<br>且有专用Preamble
NewBeamSearch --> CBRA: 找到合格波束<br>但无专用Preamble
NewBeamSearch --> BFR_Failure: 无合格候选波束<br>或搜索超时
CFRA --> BFR_Success: 收到C-RNTI DCI响应
CFRA --> BFR_Failure: beamFailureRecoveryTimer超时<br>且重传耗尽
CBRA --> BFR_Success: Msg4竞争解决成功
CBRA --> BFR_Failure: RA整体失败
BFR_Success --> Normal: BFI_COUNTER重置<br>新波束生效
BFR_Failure --> RLF: 通知RRC层<br>触发RLF/RRC重建
RLF --> [*]
| 定时器 | 启动条件 | 停止条件 | 超时后果 |
|---|---|---|---|
beamFailureDetectionTimer |
收到首个BFI | 正常到期(不重启) | 若BFI_COUNTER < maxCount → 重置计数器 |
beamFailureRecoveryTimer |
发送BFR PRACH Preamble | 收到有效C-RNTI DCI | BFR失败,可重传或触发RLF |
ra-ContentionResolutionTimer |
发送CBRA Msg3 | 收到Msg4竞争解决 | CBRA失败,回退 |
| PRACH回退定时器 | CFRA失败 | — | 决定是否重试PRACH |
| 维度 | CFRA(Contention-Free) | CBRA(Contention-Based) |
|---|---|---|
| Preamble来源 | gNB预分配专用索引 | UE从公共池随机选择 |
| 消息步数 | 2步(Msg1 + gNB Response) | 4步(Msg1→Msg2→Msg3→Msg4) |
| 时延 | ~10-20ms | ~30-50ms |
| 碰撞风险 | 无(专用资源) | 有(多UE可能选同一Preamble) |
| 适用波束 | 已配置专用资源的候选波束 | 任意波束(含未配置专用资源的) |
| gNB识别方式 | Preamble→UE映射 | Msg3中携带C-RNTI MAC CE |
| 响应搜索空间 | recoverySearchSpace(专用) | 正常RA SearchSpace |
| Rel-15支持 | PCell only | PCell only |
| Rel-16增强 | 扩展至SCell | 扩展至SCell |
gNB通过RRC消息为每个候选波束分配专用Preamble,映射关系如下:
candidateBeamRSList中的每个条目:
├── SSB索引 (ssb-Index) 或 CSI-RS资源索引 (csi-RS-Index)
├── 对应的专用Preamble (ra-PreambleIndex)
├── 对应的PRACH时机掩码 (ra-ssb-OccasionMaskIndex)
└── PRACH前导码接收目标功率 (ra-PreambleTransPower)
UE选择候选波束后,直接查找该映射关系,获取专用Preamble并在对应的PRACH时机发送。gNB收到该Preamble后,通过Preamble索引反查UE身份,直接以C-RNTI加扰DCI进行响应。
Rel-16将BFR能力扩展到SCell(辅小区),关键变化包括:
在Multi-TRP部署中,不同TRP的波束可能独立失败:
Rel-18引入了L1/L2移动性框架,BFR作为其中的一个子过程:
在协议分析仪(如Wireshark + srsRAN、QXDM、TEMS)中识别BFR流程:
| 抓包层 | 关键标识 | 说明 |
|---|---|---|
| PHY层 | PRACH Preamble发送 | 在非正常RA时机出现Preamble → 疑似BFR |
| MAC层 | BFR MAC CE(LCID=52/53) | SCell BFR的明确标识 |
| RRC层 | BeamFailureRecoveryConfig 出现 |
BFR功能启用的标志 |
| L1层 | BFI指示(厂商私有日志) | PHY→MAC的BFI通知 |
| PDCCH | recoverySearchSpace中的DCI 1_0 | BFR响应的明确标识 |
场景1:BFR反复触发但无法恢复
- 现象:BFI_COUNTER持续到达maxCount,CFRA/CBRA均失败
- 根因:candidateBeamRSList配置的候选波束质量均不佳,或覆盖存在盲区
- 排查:检查所有候选波束的L1-RSRP测量报告,调整候选列表
场景2:CFRA成功但数据传输中断 - 现象:gNB回复了BFR Response,但后续数据传输仍失败 - 根因:recoverySearchSpace配置错误,或新波束的TCI State未正确更新 - 排查:验证recoverySearchSpace的CORESET配置,检查TCI State激活MAC CE
场景3:SCell BFR MAC CE被gNB忽略 - 现象:UE发送BFR MAC CE后,gNB未执行波束切换 - 根因:MAC CE格式错误(如截断BFR的bitmap不正确),或gNB不支持该特性 - 排查:对比MAC CE比特级解析结果与TS 38.321 Section 6.1.3格式定义
BFR是波束级恢复机制,位于MAC层;RLF/RRC重建是小区级恢复机制,位于RRC层。两者关系如下:
波束质量恶化 → BFD检测 → BFI累加 → BFR触发
│
BFR成功 → 恢复正常(无需RRC介入)
│
BFR失败 → MAC通知RRC
│
RRC触发RLF → RRC Reestablishment
关键区别:BFR成功后,UE的C-RNTI不变、安全上下文不变、PDU Session不变——这是一个零感知的底层恢复过程。而RRC重建意味着连接中断、上下文重建,上层业务感知明显。
Q1: BFR和RLF有什么区别?什么时候触发BFR而不是RLF?
A: BFR是MAC层的波束级恢复,针对的是"当前服务波束失败但小区仍可接入"的场景。RLF是RRC层的链路级恢复,针对"整个小区信号不可用"的场景。只要gNB配置了BeamFailureRecoveryConfig且存在合格候选波束,UE优先触发BFR。只有BFR也失败后,才会升级为RLF。
Q2: CFRA的专用Preamble数量有限,如何保证BFR的可靠性?
A: gNB通过RRC为每个候选波束分配1个专用Preamble。在波束管理较好的网络中,同时发生波束失败的UE数量有限,专用Preamble通常够用。如果网络运维发现Preamble冲突频繁,可增大candidateBeamRSList中的波束数量(从而增加专用Preamble池),或调整BFD门限减少误触发。
Q3: SCell波束失败为什么不用随机接入恢复?
A: SCell上不传输PUCCH/PRACH(除非特殊配置),因此无法执行随机接入。Rel-16引入的SCell BFR使用BFR MAC CE在PCell上上报SCell的波束失败信息,gNB收到后通过TCI State更新来切换SCell的波束——整个过程不涉及随机接入。
Q4: BFR对URLLC场景有什么特殊意义?
A: URLLC要求端到端时延<1ms、可靠性>99.999%。BFR的CFRA路径可在~10-20ms内恢复波束,远优于RRC重建的数百毫秒。在Rel-17/18中,BFR与Multi-TRP冗余传输结合,即使一个TRP的波束失败,另一个TRP仍可维持传输,进一步保障URLLC可靠性。
Q5: beamFailureDetectionTimer和beamFailureRecoveryTimer有什么区别?
A: beamFailureDetectionTimer控制BFI计数器的重置——如果在该Timer周期内BFI计数未达到maxCount,计数器清零。beamFailureRecoveryTimer控制BFR恢复过程的超时——UE发送BFR Preamble后启动该Timer,若到期未收到gNB响应则判定BFR失败。前者是"检测阶段"的Timer,后者是"恢复阶段"的Timer。
本文由「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 等场景全覆盖。
