去年优化一个FR2 站点的时候最折磨我的问题不是站开不起来而是用户在室内靠近窗边的工位上业务吞吐量一会儿稳定在 1.2Gbps一会儿突然掉到几十Mbps持续几十秒又自己恢复。后台查了一圈干扰排查了、邻区关系核对了、核心网侧也看了一遍最后问题定位到波束切换不及时。也就是基站和终端之间明明有更合适的波束对但系统没有在合适的时机完成切换。这类问题在 5G 毫米波和部分高频段场景里非常典型背后的技术体系和调优逻辑就是今天要说的波束管理Beam Management。波束管理不是某一个单一参数、单一流程能说清楚的东西它是 NR 系统里从小区搜索到用户面数据传输再到移动性维护的一整套信令和测量机制。这篇内容适合刚接触 5G NR 物理层、在做基站算法或终端协议栈开发的工程师也适合网优侧正在处理 FR2 覆盖和体验问题的朋友。我会尽量把“为什么要这样做”“协议层的流程是怎样的”“实际上线时哪里容易踩坑”几个层面讲透全部来自实际项目的复盘和协议研读笔记。1. 高频段带来的覆盖难题为什么波束管理成了 5G 的命门1.1 毫米波频段传播损耗有多夸张无线通信系统频率越高自由空间路径损耗越大。根据弗里斯传输公式自由空间损耗正比于频率的平方也就是说频率提高 K 倍损耗增加 20lg(K) dB。以 3.5GHz 和 28GHz 做对比28GHz 相对 3.5GHz 的频率比值为 8路径损耗差约为 20lg(8) 18.06dB。这还只是自由空间的情况实际传播中还有雨衰、大气吸收、植被衰减以及建筑材料穿透损耗。FR2 频段发射信号穿过一堵普通玻璃窗损耗就能达到 3-5dB 甚至更高而穿混凝土墙的损耗轻松超过 20dB。如果用 LTE 时代全向天线辐射的思路去覆盖基站的功率再大也很难把这个链路预算撑起来。这就是毫米波系统必须采用波束成形的原因。波束成形通过天线阵列中各个阵元的相位加权把射频能量在空间上聚焦到某个特定方向相当于把原来“四面八方散出去的灯光”变成“一道集中的手电筒光束”。64 个天线阵元的理想阵列增益大概是 10lg(64) 18dB刚好能把 28GHz 相对 3.5GHz 多出来的那 18dB 损耗补回来。所以不是说毫米波天生覆盖差而是必须用对方法也就是用定向波束去做收发。1.2 “全向覆盖”思维到“定向波束”思维的转变LTE 时代小区级参考信号 CRS 是全向发送的终端在任何位置、任何一个时刻开机都能收到小区参考信号测量并驻留是一个相对被动的过程。但到了 NR 高频段基站侧如果同时把所有方向都发满每个方向能量都摊薄接收端根本解不出来。所以基站必须把同步信号和参考信号做成多个窄波束轮询地打向不同方向终端需要先找到一个“能收到”的方向才能完成驻留。这就把网络覆盖问题从“有没有信号”变成了“基站和终端之间能不能找到一对互相看得见的波束方向”。这个“互相看得见”不仅存在于网络接入阶段。网络接入后终端在小区里移动、旋转、甚至手指遮挡了天线模组都会导致原来的波束对失效系统必须重新测量、重新对准。于是就有了今天的主角——一套围绕波束发现、波束测量、波束指示、波束失败恢复的完整管理机制。可以说离开了波束管理毫米波系统只能是一个“在实验室里能通到了马路上就断”的玩具。现在回过来看 3GPP 标准里的波束管理定义其实核心就一句话让发送端和接收端都能确定并且动态维护一组合适的波束方向以维持控制信道和数据信道的可靠传输。标准里将波束管理流程分为 P-1、P-2、P-3 三个阶段这在后续第 2 部分会详细拆解。2. 波束管理的完整生命周期从小区级扫描到用户级跟踪2.1 初始接入阶段的波束扫描与小区级覆盖终端开机后的第一件事是小区搜索。NR 的 SSB同步信号块由 PSS、SSS 和 PBCH 组成基站会在一个 SSB burst set 里把多个 SSB 以时分复用的方式依次发出每个 SSB 对应一个不同的发射波束方向。终端扫描这些 SSB就能确定当前自己所在位置能收到哪些方向的基站波束并测量每个波束的信号强度。这一步属于典型的波束扫描。注意SSB 最多可以有 64 个FR2 场景、子载波间隔 120kHz/240kHz 时可容纳 64 个 SSB index但实际配置几个波束要综合站点场景和终端能力去权衡。我在实际部署中见过一个典型的配置选择郊区覆盖型站点扇区角度相对窄波束数量可以做得少一些比如 8 个这样每个波束扫描周期短终端接入更快但在市中心高楼环境下垂直维度和水平维度都需要覆盖波束数量往往要加到 32 甚至 64 个波束更窄增益更高但整套 SSB 扫描一遍的时间也更长。这里要提一个很多初学者会忽略的点SSB 波束扫描周期ssb-periodicityServingCell直接决定了终端初始接入的快慢。如果配置了 64 个 SSB 波束而周期又拉得很长那么终端开机后可能要等更久才能收到一轮完整的波束扫描小区搜索时延会明显增加。反之扫描周期太短SSB 占用的资源变多会影响数据信道的可用资源。这个矛盾在波束维度的优化里会反复出现。终端完成 SSB 波束扫描后会向基站上报波束级别的 L1-RSRPLayer 1 Reference Signal Received Power。这一步就是 3GPP 定义的 P-1 流程目的是让收发两端通过宽波束完成粗对准确定一个大致的“可通信方向”。2.2 波束测量、上报与 P-1/P-2/P-3 流程P-1 流程完成后系统已经知道了大方向但宽波束的对准精度有限增益也不是最优的。这时需要进入波束细化阶段。NR 的波束细化主要靠 CSI-RS信道状态信息参考信号来完成。基站可以给终端配置一套 CSI-RS 资源每个资源指向不同方向的波束终端对这些 CSI-RS 做测量把 L1-RSRP 上报给基站。P-1 阶段基站使用宽波束轮询发送终端粗测不同波束方向完成收发两端的大致对准。这个阶段的波束是覆盖级的数量少、单个波束宽度大。P-2 阶段基站侧使用多个更窄的波束在 P-1 确定的较小角度范围内发射 CSI-RS终端测量后上报基站据此选择更精确的发射波束。这个阶段主要是发送端波束细化。P-3 阶段发送端波束固定为 P-2 选出的较优波束终端侧在同一波束上通过不同的接收波束做测量找出终端侧的最优接收方向。这个阶段是接收端波束细化。从通信知识的角度可以这样理解P-1 找到的是“大概方向”P-2 是对准发送端、P-3 是对准接收端。整个过程可以类比成人站在山顶喊话找人先朝四面八方喊一轮P-1听到回音后确定对方在东边再朝东边细分几个角度喊P-2最后人再转动耳朵找最佳听音方向P-3。CSI-RS 的测量上报可以按周期、半持续、非周期三种方式配置。工程上最常用的是周期上报上报周期和 CSI-RS 的发送周期需要匹配得当。如果上报周期太长基站更新波束的速度就慢终端一移动就容易失配周期太短上行反馈开销增大而且 L1-RSRP 的变化并不需要那么高的跟踪频率。通常建议 P-2/P-3 阶段的周期设置在 20ms 到 80ms 之间具体要看终端的移动速度和信道变化特性。2.3 TCI 状态与 QCL 关系波束指示的核心机制从测量到真正把基站和终端的波束部署到数据传输上中间还有一个关键环节基站如何告诉终端“我准备用哪套波束来发数据”。这个指令就是通过 TCITransmission Configuration Indicator状态来完成的。TCI 状态本质上是把“目标参考信号”和“源参考信号”建立一种准共址QCL假设。QCL 的意思是如果目标参考信号与源参考信号的某类信道大尺度参数相同或者相似那么终端就可以借助源参考信号的测量结果去接收目标参考信号。QCL 关系分为四类QCL 类型包含的大尺度参数用途TypeA多普勒频移、多普勒扩展、平均时延、时延扩展用于时频同步类参数推导TypeB多普勒频移、多普勒扩展用于多普勒类参数推导TypeC平均时延、多普勒频移用于平均时延和频移推导TypeD空间接收参数决定了终端用哪个接收波束来收目标信号在波束管理里最核心的就是 QCL-TypeD。基站配置某个 PDCCH 或 PDSCH 的 TCI 状态时如果该状态关联的源 RS 是某个 SSB 或 CSI-RS且 QCL 类型包含 TypeD那么终端就会使用接收该源 RS 时所用的接收波束去接收对应的 PDCCH 或 PDSCH 信号。这个过程可以理解成基站说“你之前听某个方向很清楚我现在还是从那个方向发你继续往这个方向听”。TCI 状态对 PDCCH 和 PDSCH 分别由不同信令控制。PDCCH 的 TCI 状态主要通过 MAC CE 激活PDSCH 的 TCI 状态同样用 MAC CE 做动态指示。这也带来一个工程上的经典问题TCI 状态切换的调度延迟。从基站发出 MAC CE到终端完成状态切换并开始使用新的波束接收这个过程中间如果基站贸然用新波束调度大量数据终端很可能因为还没反应过来而解调失败。所以实际基站实现中MAC CE 下发后往往要等到终端 ACK 确认再等待一段保护时间然后才切换传输波束。这个保护时间的长度不同厂商实现不一样但思路是一样的调度器要感知终端波束切换的状态避免误调度。3. 波束失败恢复NR 里最容易忽略的可靠性保障3.1 为什么高频段必须有独立的波束失败检测机制LTE 时代的无线链路失败RLF依赖终端对下行参考信号的长期统计一旦检测到链路质量低于门限就触发 RLF然后终端重新发起随机接入做 RRC 重建。但在毫米波场景下问题在于波束被遮挡时链路质量可能在几十毫秒内急剧恶化但波束可能只是暂时性的“换个方向”就可能恢复。如果一碰到波束失配就直接跌到 RLF再重建整个过程耗时太长用户业务中断严重而且网络也无法区分是小区级覆盖问题还是波束级失配问题。所以 NR 引入了一套比 RLF 粒度更细、恢复更快的机制——波束失败检测Beam Failure Detection, BFD和波束失败恢复Beam Failure Recovery, BFR。它的目标不是重建整条无线链路而是快速找到一个新的合适波束把原来的链路“救回来”。这套机制可以理解为链路级故障的“快速换胎”而不是“整车报废再重造”。3.2 BFD 与 BFR 的完整流程波束失败检测的基础是终端周期性评估一组波束失败检测参考信号BFD-RS。BFD-RS 可以是周期性 CSI-RS也可以是 SSB具体由网络配置。终端根据 BFD-RS 的假设性 PDCCH BLER判断当前服务波束是否已经不可靠。这里有一个隐藏前提终端评估的其实是“用当前这个接收波束去解调 PDCCH成功率还够不够”。如果假想的 BLER 超过了一个实现相关的门限业界一般参考 10% 量级协议上称为 qout就计一次波束失败实例如果低于另一门限qin则认为波束恢复可用。连续多次波束失败实例后终端会触发波束失败恢复流程。流程大致分四步终端自行搜索候选波束。网络会提前给终端配置一个候选波束 RS 列表candidateBeamRSList终端在这个列表里测量所有可能是“可用”的新波束选出最好的一个。终端通过专用随机接入资源PRACH 资源称为 BFR-PRACH向基站发送波束失败恢复请求并在请求中关联自己选出的候选波束。这里注意SpCell主小区的 BFR 请求是用 PRACH 发的而 SCell辅小区的 BFR 请求是通过 MAC CE 上报给基站的。基站在收到 BFR 请求后会重新配置 PDCCH 的 TCI 状态把控制信道的接收波束切到终端上报的那个新波束上。终端用新波束继续监听 PDCCH确认恢复成功。整个流程的设计目标是把波束失配的恢复时间控制在几十毫秒量级。实际效果取决于 BFR-PRACH 的资源时机、候选波束测量的周期、以及基站侧响应 BFR 的调度速度。在现网问题排查中如果发现某个终端频繁出现“上行不发数据、下行不解调”的片段很可能就是 BFR 没有触发成功或者触发了但候选波束里没有真正可用的波束。3.3 实测中的波束失败问题一次完整排查链路上面提到的那次 FR2 站点优化最后定位到的问题就在 BFR 环节。现场用户场景是人坐在窗边但窗户是低辐射镀膜玻璃对毫米波衰减特别大稍微偏一点角度服务波束信号就迅速跌到噪声底部。我们用测试终端复现时观察到的现象是SS-RSRP 显示还有 -90dBm 左右但业务速率间歇性塌陷。排查链路如下这里以连排障的顺序和要点给同样在踩坑的同行一个参考第一步先确认是否频繁发生波束失败。终端侧日志里有波束失败实例计数和服务波束切换记录。实测中发现终端在 20 秒内出现了 4 次波束失败实例触发了多次 BFR基本坐实了波束失配问题。第二步检查候选波束列表配置。BFR 触发后终端要选一个新波束但如果候选列表里配的 SSB/CSI-RS 本身测量信号就弱终端选不出一个优于当前服务波束的新方向整个 BFR 就会失败或反复触发。这里有个很容易踩的坑配置 candidateBeamRSList 时只覆盖了理想路线的几个方向没有把窗户附近强反射方向对应的 CSI-RS 纳入候选。也就是说网络认为该处“不应该有用户”但现实是用户就在那个位置。发现问题后我们把该站点的候选波束列表扩展到了包含室内二次反射方向和窗户边缘绕射方向的波束并重点验证了这些方向上的 L1-RSRP 是否满足 BFR 的 qin 要求。第三步核查 BFR-PRACH 资源与多用户碰撞问题。BFR-PRACH 如果配置得太少多个用户在同一时间触发 BFR 就会出现随机接入竞争冲突导致恢复请求发不出去。优化时我们把 BFR-PRACH 的周期从 80ms 缩短到 40ms并增加了一个专用的前导码序列组确保并发触发时能容忍一定的碰撞重发。第四步调整波束失败实例门限beamFailureInstanceMaxCount。这个参数表示终端连续检测到多少个失败实例后触发 BFR。默认值通常是 1 或 2但现场场景中如果波动比较快设置过小会导致 BFR 过于灵敏终端频繁在波束间来回切换反而增加开销和中断。我们最终把它定为 2配合 10ms 的波束失败检测周期既能快速响应真实失配又能过滤快速落深衰落的偶发事件。经过这轮调整实测中业务吞吐量低谷出现的频次从每分钟数次下降到几乎消失。这个案例也说明波束管理的参数调优没有“一劳永逸”的配置必须结合站点环境和用户行为做针对性打磨。4. 实际组网中的波束优化从路测数据到参数调优4.1 从路测看波束覆盖问题做高频段网络优化路测是基本功。但在 FR2 场景下路测的解读方式跟 LTE 完全不同。LTE 路测看 RSRP 和 SINR 就能大致判断覆盖和干扰而高频路测必须要结合波束索引一起看。同一位置不同的波束索引对应完全不同的接收效果。常见的问题是“波束空洞”和“波束乒乓切换”。波束空洞指的是某个位置上所有 SSB 波束的测量值都低于接入门限物理上就是盲区。这种情况调整波束方向可能效果有限往往需要新增站点或者增加反射体。波束乒乓切换则表现为终端在同一位置连续在两个波束索引之间来回切换每次切换都伴随一次 TCI 状态更新和可能的 PDSCH 调度空档。观察终端 log 里波束切换的时间线如果发现两个波束索引在几百毫秒内反复交替出现就是典型的波束切换抖动。处理波束切换抖动一个方向是给波束选择增加滞后余量hysteresis避免终端在两个相近强度的波束间反复跳另一个方向是调整 L1-RSRP 上报的周期和颗粒度让基站侧看到更加平滑的波束强度变化。不过要注意波束切换的迟滞不能加得太大否则终端已经进入另一个波束的优势区域了还在死守旧波束最终可能导致波束失败。这个分寸感只能靠实测迭代去摸。再补充一个关于测量上报的重要细节L1-RSRP 上报是量化后的实际协议中 L1-RSRP 的量化范围是 [-140, -44] dBm粒度 1dB。也就是说终端上报的值是精量化的索引值并非绝对精确的测量值。在做波束间比较时差值小于 1dB 的波束实际上可以认为是“并列”的不要为了这一两个 dB 去做过于敏感的切换判定。4.2 工程参数调整经验波束管理相关的参数实际网优和系统优化中最常动的几个可以整理成一张表参数作用调整倾向风险点SSB 波束数量决定小区级扫描覆盖方向和粒度覆盖空洞多则加波束数波束过多导致扫描时间长SSB 周期决定小区搜索和初始接入时延用户体验敏感则调短周期过短增加参考信号开销CSI-RS 波束数量决定连接态波束细化精度移动性场景多则加密度资源开销和测量复杂度上升波束失败实例最大次数决定 BFR 触发的灵敏度波动频繁则调大调过大时恢复变慢波束测量上报周期决定基站波束更新的频度高速移动则调短上行反馈开销增大候选波束列表长度决定 BFR 可选方向的覆盖范围复杂环境则加长列表过长导致测量选择变慢参数调整有一个核心原则所有跟时间相关的参数必须先理清它们之间的级联关系再动数值。举个例子你缩短了 CSI-RS 上报周期但基站侧处理上报的算法循环仍然很慢那么上报再频繁也没有用。又比如你把 BFD 检测周期调短了但 beamFailureInstanceMaxCount 没有调那么终端触发 BFR 的总耗时反而变短了判断逻辑的灵敏度是整体变化的不是孤立参数。另外参数配置要区分“小区级”和“用户级”。SSB 波束数量、SSB 周期属于小区级动一发牵全身影响所有接入用户所以调整要非常谨慎通常在批量修改前要做覆盖仿真和定点测试。CSI-RS 波束配置、TCI 状态配置、BFR 候选列表则可以是用户级或用户组级的对于重点保障的高价值用户可以单独配置更密集的波束管理资源。4.3 移动性场景波束管理与切换的协同波束管理和移动性管理的关系很多人理解是割裂的波束管理是连接态日常做的切换是跨小区才做的。但实际在高频组网里这两者深度耦合而且耦合的失败点最容易出现在小区边缘。终端从小区 A 往小区 B 方向移动时小区 A 内的服务波束角度会越来越大信号越来越弱小区 B 的信号逐渐变强。如果没有做好小区边缘附近的波束切换终端的数据传输会经历一段“服务小区信号弱但迟迟不切”的尴尬时期。NR 里有个概念叫波束级测量报告L1-RSRP report它主要服务于波束管理但小区切换决策的基础是 L3 滤波后的测量结果。L3 滤波时间常数太长就会让基站侧看到的波束质量变化滞后于实际信道。这里面涉及一个时间尺度匹配问题L1 波束测量快、用于波束级调整L3 小区级测量慢、用于切换决策。但如果终端已经移动很快L1 报告里的最优波束已经从波束 1 变成了波束 6而 L3 的滤波结果还停留在几秒前的水平那么基站可能做出两个矛盾的动作一方面波束管理认为当前波束方向已不可靠另一方面切换判决认为信号还可以。最终用户的体验就是“波束切换和小区切换都没及时做吞吐量一路下跌”。实践中解决思路是让 L3 滤波和 L1 波束切换保持一个合理的级差。L3 滤波的滞后时间不要过长终端高速移动场景下通常建议把 L3 滤波系数调小同时结合波束失败恢复机制终端在服务波束严重劣化时能主动通过 BFR 换到相邻小区的波束方向这在多小区场景下可以缩短切换前的“无人管”窗口。更进一步NR Rel-16 以后引入了条件切换CHO终端提前拿到切换条件和目标小区配置在满足条件时直接执行切换并完成波束选择这能大幅缩短切换时延。5. 多 TRP 协作与 AI 波束预测波束管理的演进方向5.1 多 TRP 场景下的动态波束选择单站点的波束管理本质上是在“一个基站的多根天线面板”范围内选择最优波束方向。到了多 TRPTransmission Reception Point协同场景情况发生了变化多个物理位置的发送接收点可以同时给同一个终端服务同一时间不同 TRP 可以用不同波束发不同数据流或相同数据流从而获得空间分集或空间复用增益。多 TRP 对波束管理最直接的影响是“波束对”从一对变成了多对。终端可以同时维持与 TRP1 的波束对 A、与 TRP2 的波束对 B系统需要独立维护每一条波束链路的状态。如果一个 TRP 方向上的波束失败终端只对这条链路做 BFR而不影响另一个 TRP 的传输。这就把可靠性从“单链路保障”提升到了“多链路协同”。不过真正的工程难点是终端实现复杂度和反馈开销。多 TRP 场景下原本只需要上报一个最优波束现在可能需要上报多个 TRP 对应的多个最优波束而且每个波束的测量和跟踪都要消耗终端基带处理资源和电池。实际系统的做法通常是主链路始终维持高精度的波束跟踪辅助链路的波束管理降低频率和精度只有在主链路质量下降时才临时提高辅助链路的跟踪精确度。这种“非对称波束管理”思路在终端功耗和性能之间能取得更好的平衡。多 TRP 还要求 TCI 状态的管理从单状态变为状态组。终端接收 PDSCH 时不同传输时机可以采用来自不同 TRP 的 TCI 状态。调度器需要动态决定当前时隙的 PDSCH 用哪套波束来发送。这已经不是简单的“换波束”问题了而是波束维度调度的范畴。越往这层走越需要把波束状态和资源调度联合起来做算法设计基站侧再也不可能靠静态配置打天下了。5.2 基于 AI 的波束预测与定位辅助高频段网络的一个天然痛点波束管理开销和时延随波束数量增加而增加。为了降低这个开销业界从 Rel-17 开始重点关注基于终端位置信息辅助波束管理而 Rel-18 及后续进一步增强的 AI 赋能的波束预测已经成为明确的研究方向。AI 波束预测的核心逻辑是终端信道环境并非完全随机它在某个位置的波束信道特征与历史测量存在相关性。系统可以利用终端上报的历史 L1-RSRP 序列、终端移动轨迹、传感器数据通过机器学习模型预测下一段时间最优波束方向减少终端扫描波束的次数和时间。打个比方一个老练的足球守门员在扑点球时不会等球完全出来再反应而是根据罚球者动作和过往记录预判方向。AI 波束预测就是让网络学到这类“预判能力”。这套方案的现实可行性取决于三个前提足够多的波束级测量数据做训练、时延足够的推理框架、以及可解释性足够强的置信度输出。比如预测模型给出“下一阶段最可能是波束 3置信度 87%”网络可以优先调度波束 3但同时需保留波束 1 和波束 5 的兜底测量防止模型预测偏差导致链路断掉。从我个人的角度看AI 波束预测短期内更适合作为现有波束管理的“加速层”而不是完全替代。毕竟现网环境千差万别等比波束扫描的可靠性在很长一段时间里仍是不可替代的底线保障。但 AI 如果能做到“在 80% 的普通场景下帮系统省掉 40% 的波束扫描开销”这就已经非常有工程价值了。真正做商用产品的时候我更关注的不是这个模型在仿真集上有多准而是它在现网一个月的数据里能不能保持稳定以及在罕见但关键的车载、遮挡场景下会不会做出离谱的预测。这是任何从仿真走向商用的波束算法都必须跨过的门槛。