★ FEATURED ARTICLE 在5G QoS参数这堆缩写里GFBR是最让人安心的一个名字叫“保证流比特率”字面意思就是网络给GBR业务画了一条保底线。可真正吃过亏的人会提醒你多看一眼它旁边的MFBR。MFBRMaximum Flow Bit Rate最大流比特率和GFBR一起出现在参数表里却几乎永远被当成附属项。它和GBR业务绑定却专门负责设置上限——这条上限一旦被触发轻则削峰限速重则直接丢包。我觉得它不是配角它是一把悬在GBR业务头顶的达摩克利斯之剑尤其是你在做5G专网交付、核心网QoS策略配置或无线侧速率问题排查时MFBR往往就是那个让所有业务指标“看起来很对跑起来不对”的隐藏变量。这篇内容主要解决三件事MFBR到底是什么、它在5G协议栈里怎么被执行、以及配置MFBR时最容易踩的坑和取值方法。适合核心网协议开发、网络规划优化、5G专网集成交付的工程师还有正在学5G QoS模型的人。1. 从4G承载到5G QoS FlowMFBR坐在参数族里的哪个位置1.1 EPS承载时代的MBR为什么到5G变成了MFBRLTE时代的QoS粒度是EPS承载EPS Bearer一个承载分默认承载和专用承载。GBR承载上有两个成对出现的速率参数GBR和MBR。GBR代表保证比特率MBR代表最大比特率定义上很像如今5G里的GFBR和MFBR。但4G时代MBR的执行力度很弱很大程度上它只是一个核心网侧的概念gNB当时还叫eNB调度器未必严格按照MBR去控制单承载速率更多时候MBR被填成和GBR一样或者直接留给核心网网关去限速。到了5GC承载模型被QoS Flow模型取代。一个PDU会话内可以有多个QoS Flow每个QoS Flow用QFI标识粒度比承载细得多。同一个PDU会话里可以同时跑语音、视频、普通上网它们各自属于不同的QoS Flow各自有独立的QoS参数。GFBR和MFBR就是在这个模型下重新定义的速率边界GFBR是保证流比特率MFBR是最大流比特率。名字变了语义也变强了。MFBR不再只是核心网网关的事。它在终端协议栈、gNB调度器、UPF用户面三个位置都有对应执行逻辑。也就是说在5G里你想绕过MFBR基本不可能它从配置到落地是一条完整的链路任何一个节点对着同样的数值在执行业务表现就会和预期不一致。1.2 MFBR的基本定义方向、单位、适用对象MFBR全称Maximum Flow Bit Rate中文通常翻译成最大流比特率。它的作用对象是单个GBR QoS Flow并且只对GBR和Delay-critical GBR这两类资源类型的QoS Flow生效。non-GBR QoS Flow没有MFBR这个参数它们被Session-AMBR和UE-AMBR管着。一个GBR QoS Flow的完整速率描述有四个值UL GFBR上行保证速率DL GFBR下行保证速率UL MFBR上行最大速率DL MFBR下行最大速率上行和下行是独立配置的单位一般在信令里用kbps表示日常规划时大家习惯说Mbps。很多人配置模板时顺手把四个值填成一个数这是很大的隐患因为很多业务上下行需求根本不是对称的比如直播推流上行是主需求云游戏下行是主需求。规范对MFBR的定义表达得很克制它表示网络期望该QoS Flow不会超过的比特率如果实际流量超过MFBR网络可以丢弃过多数据也可以进行限速。注意“可以”这个词具体是丢还是限取决于设备厂商实现但共同点是超出的流量不再被承诺稳定传输。这跟GFBR有本质区别后者是网络要尽力保障的速率。1.3 为什么它是“悬在头顶”的参数用类比来理解GFBR像劳动合同里写的最低工资MFBR像公司允许你拿到的月度奖金上限。最低工资保证你饿不死但奖金上限决定了你就算再努力也不可能突破那个数。GBR业务有了GFBR保底不等于它可以无限拿资源——MFBR就是那道封顶。更准确地说MFBR悬在GBR业务头顶的含义是业务正常跑在GFBR和MFBR之间时网络按调度规则尽力服务一旦业务突发速率超过MFBR那超出部分会立刻被处理掉没有任何情面可讲。而这种“超出”在很多场景下不是用户主动叠加流量造成的而是编码器瞬时码率抖动、TCP拥塞窗口探涨、视频帧率突变这类完全正常的业务行为。所以从业务角度看GFBR是你能预期的下限MFBR是你看不见的上限。这张上限设置得不合理比GFBR设置得不合理更危险因为GFBR给低了至少能被发现MFBR给低了只会让业务莫名其妙地卡在某个速率极难定位。2. 保底与封顶GFBR、MFBR、AMBR三者到底管什么2.1 GFBR承诺的“保底”到底保在什么层面GFBR的全称是Guaranteed Flow Bit Rate它的含义是网络为这个QoS Flow保证的最小比特率。在gNB调度器里GFBR参与资源预留计算当小区出现拥塞时调度器会优先把资源分配给还没达到GFBR的数据流保证它们能获得最低限度的速率支撑。但这不等于“任何时刻都保证”。GFBR和5QI里的Packet Delay Budget、Packet Error Rate共同构成一个QoS契约。如果一个GBR QoS Flow的GFBR长期无法满足且该QoS Flow开启了Notification ControlgNB会向核心网发通知告诉SMF“这个流的GFBR我保不住了”由核心网决定是否调整策略或触发切换。也就是说GFBR保留了一部分弹性空间不是绝对红线。GFBR带给用户的体验是在信号正常、小区容量允许的情况下业务速率不应该低于这个值。它是一个下限契约超过下限的部分属于尽力而为的范围网络不给你任何承诺。2.2 MFBR是一条“分流大坝”MFBR的作用可以理解成一条分流大坝。GFBR是死水位保证最底线MFBR是汛限水位超过这个水位的流量要泄洪。泄洪的方式包括丢弃和限速两种具体取决于实现。为什么不能把超过MFBR的数据缓存下来慢慢传因为GBR业务大多有时延敏感属性。你把数据缓存重排时延和抖动会立刻恶化对语音、实时视频、工业控制这些都是灾难。MFBR的价值就是干脆利落地在不该占用资源的地方切一刀防止某个QoS Flow吃掉整个小区的资源。还有一个容易被忽略的点丢包会直接影响TCP拥塞控制。TCP流一旦丢了包发送方感知到拥塞后会主动降低速率于是MFBR还能间接触发TCP的降速机制。但对UDP/RTP类的实时视频流丢包就是丢画面丢声音终端用户感受非常直接。所以MFBR的设计语义对不同传输层协议实际效果差异巨大。2.3 AMBR与MFBR的边界两套账本不要混AMBR有Session-AMBR和UE-AMBR两个层级。Session-AMBR限制的是一个PDU会话内所有non-GBR QoS Flow的聚合速率UE-AMBR限制的是一个UE所有non-GBR QoS Flow的聚合速率通常是所有会话加起来。注意这两个AMBR都只作用于non-GBR业务GBR业务不受AMBR限制GBR业务走的是GFBR和MFBR。需要特别厘清的一个场景一个UE同时开语音电话和刷网页语音属于GBR QoS Flow网页属于non-GBR QoS Flow。语音按它自己的GFBR/MFBR执行网页按Session-AMBR和UE-AMBR执行两套计量体系独立。语音就算跑到MFBR上限也不会去占用网页在AMBR里的配额反过来网页流量把Session-AMBR吃满了也不会影响语音的GFBR保障。参数粒度适用对象主要执行点超出后果GFBRQoS FlowUL/DLGBRgNB调度尽力保障无法保障时通知核心网MFBRQoS FlowUL/DLGBRUPFDL、UEUL、gNB调度丢包或限速Session-AMBRPDU会话non-GBRUPF限速UE-AMBRUEnon-GBRUPF、RAN限速这样的分工在5G QoS模型里非常清晰GBR业务看GFBR/MFBR这一对non-GBR业务看AMBR这一代。配置的时候先分清业务属于哪一类再决定动哪个参数。3. 从策略下发到丢包执行MFBR在5G协议栈里的完整旅程3.1 参数从哪里来PCF到SMF再到各节点的完整路径MFBR不是手写在基站上的它是一条贯穿控制面的完整策略链PCF策略控制功能根据业务签约和策略决定某个QoS Flow需要的QoS参数通过N7接口发给SMF。SMF确定GFBR和MFBR的取值通过N4接口给UPF下发QoS Enforcement RuleQER携带上下行速率控制参数。SMF通过NAS信令PDU Session Establishment或Modification把QoS Flow Description下发给UE包含UL/DL GFBR和MFBR。SMF通过N1/N2接口把QoS参数交给AMF再由AMF转发给gNBgNB建立QoS Flow上下文用于无线资源调度。这条路径决定了MFBR是一个全链路参数UPF要在用户面执行下行速率限制UE要在协议栈执行上行速率限制gNB要在空口调度中参考GFBR和MFBR。任何一个环节的实际行为和配置不一致业务表现就会和预期偏离。实际交付中经常遇到的情况是核心网SMF侧已经按模板下发了正确的MFBR但旧的QoS模板还在UE侧缓存或者gNB的相关上下文在切换时没同步导致同一套参数在不同节点看起来都是对的跑起来却五花八门。所以排查MFBR问题时四个节点都要看。3.2 下行链路UPF的速率计量与丢包策略下行方向UPF从N6接口收到来自数据网络的IP包根据PDR匹配到对应的QoS Flow再根据QER获取该QoS Flow的DL MFBR。UPF内部通常用令牌桶做速率计量令牌以MFBR对应的速率生成数据包通过消耗令牌通过当桶里没有令牌时超出速率的数据包无法通过。这时UPF有两种处理策略Discard直接丢弃超出部分适合实时性要求高的业务。Rate Limit把超出的包加上较低优先级或者做轻微缓存尝试分段转发适合有一定容忍度的业务。多数核心网实现默认以丢弃为主因为MFBR的语义就是“超过这个速率网络不承诺稳定传输”。如果你在UPF的统计里看到某个QoS Flow存在大量下行丢包并且丢包规律与速率强相关基本可以判定是MFBR触发了执行。值得注意的是UPF的MFBR执行是作用在QoS Flow粒度的不是作用在单个用户IP地址或单个GTP-U隧道上的。这要求PDR和QER的匹配关系配置准确一旦规则里的QFI匹配错了MFBR就可能作用到错误的业务流上。3.3 上行链路UE侧整形和gNB调度双重限制上行方向比下行多一道限制。第一道在UE侧UE通过NAS消息收到UL MFBR之后在协议栈做流量整形限制该QoS Flow上行的发送速率。不同终端厂商的实现方式有差异有的直接丢包有的在应用层和PDCP层之间做缓冲有的对上层表现为发送窗口被压缩。但共同点是UL MFBR以下的数据才能顺利通过终端发送队列。第二道在gNB调度侧。gNB收到UE的Buffer Status Report后知道UE缓存里有多少上行数据待传但分配上行授权UL Grant时不会给某个QoS Flow分配超过UL MFBR对应速率的资源。也就是说即使UE缓存里有大量上行数据gNB的调度器也不会让这个QoS Flow超过MFBR的平均速率。这两道限制叠加的结果是上行方向超过MFBR的流量通常还没出空口就被处理掉了表现为上行速率被牢牢钉在一个上限上。你从核心网N6接口灌包测下行看得出来但从外部往上行灌包不一定能测出真实效果因为限制发生在终端和基站这一侧。3.4 无线侧调度gNB眼中的“双边界”无线调度本身是瞬时的、带信道相关性的。UE信道质量好时一个RB能传更多数据信道质量差时同样的速率需要更多的RB。gNB调度算法在维护QoS Flow上下文时会把GFBR和MFBR翻译成两个调度边界以GFBR为“最低资源保证目标”在资源紧张时优先满足这个目标。以MFBR为“最大资源授权上限”即使UE信道很好、上行有积压也不能让这个流超过MFBR对应的平均授权速率。用5QI里的优先级、Packet Delay Budget、权重因子来调节不同QoS Flow排队时的先后顺序。不同厂商的调度算法实现细节差异很大有的偏比例公平有的偏优先级绝对但MFBR作为授权上限这点是一致的。因此从用户角度看即使核心网侧UPF没有丢包业务速率也可能先被gNB空口调度限制住。这就是后面排查案例里“核心网没丢包但业务就是上不去”的典型原因——限速点不在核心网而在无线调度器。4. 剑落下来的现场三个MFBR误配置案例与完整排查链路4.1 案例一视频推流上行卡顿MFBR被复制成了GFBR某园区5G专网项目部署多路高清摄像头做实时推流监控。现场无线信号满格下行网页浏览、视频点播都正常但摄像头画面一到有人或车辆移动时就开始卡顿、花屏上行码率始终上不去。排查链路从最简单的开始在园区用手持终端做上下行灌包下行能跑到800Mbps上行也能跑150Mbps以上排除无线覆盖和基础容量瓶颈。换用摄像头同款通信模组直接灌包结果显示上行速率被封在2Mbps左右。这个现象已经很可疑了因为灌包流量是持续的不存在编码器突发问题。抓NAS信令看PDU会话建立和修改消息在QoS Flow Description里发现UL GFBR2MbpsUL MFBR2Mbps。继续核对业务实际参数该摄像头1080P/60fps编码器的峰值码率在4Mbps到6Mbps之间明显超过了2Mbps的MFBR。到SMF侧查这个QoS模板的来源发现是从一个通用视频会议模板改出来的当时只改了GFBRMFBR沿用了和GFBR相同的值。把UL MFBR调到8Mbps后画面恢复。这个案例值得记一辈子GFBR保底2Mbps不代表只能跑2MbpsMFBR才是那个“最高速率”。很多人看到GFBR2Mbps都觉得“保底够用就行”完全没去想业务突发码率早就撞上了MFBR。这类问题在现网里出现频率极高。4.2 案例二MFBR配成0VoNR通话像在过隧道一次VoNR外场测试IMS呼叫能正常接通但通话质量极差主叫能听到被叫被叫几乎听不到主叫而且断断续续。排查步骤先看IMS域抓包RTP流正常建立媒体面信令没有明显异常实时传输协议层的丢包率看起来也不高。再看gNB侧发现这个QoS Flow的上行授权分配异常小上下文里UL MFBR0kbps。调度器认为这个流不应该有任何上行速率。回溯SMF侧发现VoNR的QoS模板是从旧版本数据迁移过来的MFBR字段没有显式填写数据库默认值为0。语音媒体流上行一到终端和基站就被限制。修正模板UL/DL GFBR改成32kbpsMFBR改成64kbps通话恢复正常。这个案例最坑的地方在于5QI1对了ARP对了IMS信令全通唯独一个看起来“没填就算了吧”的MFBR直接让媒体面废掉。MFBR0不是“没有限制”而是“只允许0速率”。这把剑不是悬在头顶等业务超量时落下来而是直接横在业务的必经之路上。4.3 案例三MFBR设得太大多个GBR业务互相挤兑另一类反直觉的坑是MFBR设得过大。一个专网项目为每一路视频流配置GFBR4MbpsMFBR100Mbps规划人员的想法是“MFBR反正只是上限给大点不容易受限”。结果在一个并发12路视频流的小区里所有视频出现集体卡顿每路实际平均只有2Mbps左右。原因并不复杂MFBR是上限但它也会影响gNB调度器的资源分配。12路GBR流量同时存在每一路都允许跑到100Mbps小区总容量却被物理资源限制在一个数值上。调度器做加权计算时各路QoS Flow都有巨大的资源诉求可可用PRB就那么多最后没有任何一路能接近100Mbps连GFBR对应的保证资源也因为全体资源预算被MFBR的潜在峰值顶穿而难以维持。结论很明确MFBR不是越大越好它应该被设置成业务真实峰值的上限同时要和所在小区的容量、切片资源预算做对齐。如果一个小区总容量只有80Mbps你把每路MFBR设成100Mbps逻辑上就不可能被满足剩下的只是谁先受影响。4.4 排查工具与关键信息位回到工程实践排查MFBR相关问题有一套固定顺序先做空口速率测试确认是不是无线覆盖或干扰问题。这一步能排除大量无关变量。抓NAS信令直接看QoS Flow Description里的GFBR和MFBR。这是最直观的定位手段。到核心网侧看SMF策略、N4会话里的QER参数以及UPF统计里的丢包计数确认下行是否有MFBR触发的丢包。到gNB侧看QoS Flow上下文和调度统计看上行授权是不是被MFBR卡住了。必要时抓UE日志确认终端协议栈是否执行了UL MFBR的流量整形。我把这条链路反复用了很多次结论是速率上不去的业务八成都轮不到去怀疑无线设备性能先查QoS参数往往能省掉一整个下午的现场测试。5. 上线前比踩坑更好MFBR的取值方法论与验证闭环5.1 常见GBR业务的MFBR/GFBR参考配置MFBR没有统一的标准答案不同运营商、不同设备厂商、不同业务场景都会给出不同取值。但常见业务确实存在一套比较合理的参考范围下面这张表可以作为起点实际操作里要以业务实测为准业务典型5QI/资源类型GFBR参考MFBR参考设定逻辑VoNRAMR-WB5QI1GBR32kbps64kbps语音编码码率通常低于32kbpsMFBR留一倍余量高清视频通话5QI2GBR1Mbps4Mbps基础清晰度1Mbps突发FEC和高帧率时给4Mbps移动直播上行5QI4或定制GBR2Mbps8-10Mbps按推流峰值码率测算留30%以上余量云游戏下行5QI3或Delay-critical GBR10Mbps30-50Mbps按游戏最高画质码率加缓冲峰值设定工业相机/AGV5QI82/83Delay-critical GBR2Mbps20Mbps确定性时延业务GFBR按平均码率MFBR按突发数据量这些数值确实只是参考直接照抄到生产环境之前一定要先做业务侧抓包统计。5.2 取值方法论先量业务峰值再定MFBR我比较推荐的做法分四步在现网或者测试环境跑一段时间的真实业务负载抓包统计出该业务的码率分布重点看99.9%分位的峰值速率而不是平均速率。在峰值速率基础上增加20%到30%的余量作为MFBR的初值。原因是编码器动态码率在运动场景下很容易产生瞬时波动余量太小会在每次波动时触发限速。GFBR按平均码率的80%到90%设置不要定得太高因为GFBR太高会挤占调度器能自由分配的资源空间反而影响多路业务的共存。如果一个终端上同时跑多种GBR业务注意各QoS Flow的MFBR之和不要超过终端接口能力或切片资源上限否则物理层早就达不到。MFBR的核心语义是“期望峰值上限”不是“平均速率”这一条想清楚了取值就不会太离谱。5.3 高频错误清单我总结了配置MFBR时最容易犯的错误这些坑几乎每个项目都出现过把MFBR直接填成GFBR的值。最常见等于把业务上限焊死在保底线。MFBR字段不填写数据库默认0业务直接瘫痪或严重劣化。5QI选对了但没有按业务类型单独调整GFBR/MFBR继续沿用过时模板。上下行共用一个值忽略了很多业务上下行需求不对称的事实。多个业务流共用一个QoS模板没有给它们分别建模板。只调MFBR不看切片资源预算导致MFBR配了等于没配。每一条我都见过对应的线上故障。建议把这张清单作为模板评审的必查项。5.4 验证的完整闭环参数改完不代表工作结束验证必须形成闭环信令确认在NAS消息里能看到预期的GFBR和MFBR值SMF、gNB、UPF三侧参数一致。单业务测试在好、中、差三种无线环境下跑真实业务记录吞吐、时延、丢包率。触发测试主动把业务速率推到MFBR以上确认网络按预设策略丢包或限速且不会影响同小区其他用户。回归测试把MFBR临时调小观察业务是否出现速率封顶现象确认限速拐点和预期一致后再调回。这套闭环在业务上线前就能把绝大多数MFBR问题暴露出来比上线后等投诉再救火高效得多。5.5 一个容易忽视的联动切片与资源预算5G专网和网络切片场景里MFBR取值不能脱离切片资源独立讨论。一个切片的资源预留、最大聚合速率、最小分配资源都会影响MFBR的实际效果。如果切片总速率预算只有20Mbps那MFBR配成50Mbps没有意义因为物理资源决定了它永远跑不到这个值。调优时要跨层对齐三类资源QoS参数里的GFBR/MFBR、切片的资源预算、小区可用PRB。这三层一致了GBR业务才能真正按预期工作。任何一层掉链子最后用户感知到的都是速率不达标或时延抖动。做了这么多QoS参数校验之后我个人最大的体会是MFBR在规划阶段总被当成一个附属项在投诉阶段却往往是最直接的“凶手”。第一次遇到视频推流限速时我也怀疑过基站、怀疑过核心网转发性能最后发现只是参数表里一个数字写错了。所以把GFBR和MFBR写进模板之前花五分钟确认业务的真实码率比事后追查省力得多。如果你在做GBR业务速率规划时也遇到过类似的坑欢迎在评论区一起聊聊。
阅读完成 · 觉得有帮助？
