5G QoS机制深度解析：从QoS Flow到端到端优化实践

简介《5G网络优化QoS管理机制》PPT课件面向5G网络优化工程师、无线接入网运维人员及通信专业学习者系统讲解从4G EPS承载到5G QoS Flow的架构演进并对QFI、5QI、GBR/Non-GBR、GFBR/MFBR等关键参数的定义与用途逐一说明。内容涵盖UPF、RAN、UE三侧QoS映射原理gNodeB上下行DRB映射及NSA场景映射规则并介绍准入与抢占、上下行调度保障及non-GBR/GBR速率控制方法。课件按QoS原理、映射、gNodeB管理三大模块组织结合5QI优先级、包延迟预算、丢包率等参数表便于理解不同业务的差异化保障。包内含单个PPTX演示文稿约3.42MB图文对照适合培训讲解、自学笔记或团队内部分享。目前已有1290人学习使用是5G网络优化QoS专题的系统参考资料。1. 5G网络优化QoS管理机制先搞懂它管的是哪一层再动手调5G网络优化QoS管理机制这份PPT放在桌面上很多网优同事的第一反应是QoS不就是限速吗测速不达标就提AMBR直播卡了就提5QI还能有什么花头。真做完一张一线城市的5G优化工单你就会发现这个认知在5G时代已经过时——4G的QoS管到EPS承载这一级5G却把控制粒度下探到了QoS Flow。同一路视频里信令和媒体面可以走不同优先级同一个终端上业务A被保障业务B被限速。这套机制管的不再是给谁更多带宽而是每一路业务的时延、丢包、速率边界分别划在哪。这篇笔记不评价PPT的排版直接把这份材料背后能落地到核心网和5G基站侧的方案讲透适合正在扛5G网络优化指标、被投诉工单推着看参数的网优工程师以及刚接触切片和专网交付的项目成员。2. 从4G EPS承载到5G QoS Flow协议架构与关键参数2.1 4G的承载模型为什么在5G里不够用4G时代的QoS模型围绕EPS Bearer展开一个GBR承载对应一套QCI参数1到9UE发起业务后核心网PCCPCRF/PGW给为数不多的几个承载分配固定QCI网络把QCI当成调度和转发的等级标签。那个年代业务相对简单语音走QCI 1视频走QCI 2默认可上网业务全塞进QCI 8和9优化思路基本是别让某类业务饿死很少出现同一类业务内再分级的情况。到了5G视频电话、远程控制、物联网采集可以在同一个终端同一条PDU会话里并发如果还用一套承载只对应一种业务的模型核心网就得同时维护十几条承载。信令开销、空口DRB资源、切换时的重映射都会变成负担。3GPP在TS 23.501里引入QoS Flow概念一条PDU会话可以承载多条QoS Flow商用实现有数量上限每条QoS Flow用QFI区分并且可以共享同一个无线DRB。最关键的变化是4G里QCI决定了业务的转发优先级和时延预算承载与QCI基本一一对应5G里5QI只是QoS Flow的一个属性gNB拿到的是5QI、ARP、GBR、MBR、AMBR的组合它需要用调制编码和调度策略去满足这组目标而不是只打一个简单标签。这就是5G QoS管理机制和4G最本质的差别。维度4G EPS承载5G QoS Flow管理粒度承载级一个业务一个承载流级一条会话内可区分多路业务标识QCI1到95QI标准值远超9个DRB映射承载与DRB基本一一对应QoS Flow与DRB多对多策略下发S1承载建立TFT匹配NGAP下发QoS ProfileSDAP层做流映射业务识别TFT五元组QoS Rule可配合反射QoS动态生成规则这套表解释了很多网优兄弟的困惑为什么4G里把QCI一改就解决问题5G里改了5QI却不见效。因为5G的QoS决策点前移到了核心网SMFgNB只是执行方你在基站侧改调度参数核心网策略没有同步业务依然会被拉到旧的QoS Flow上。2.2 5QI、ARP、AMBR参数表把标准值抄下来用这一小节直接给能抄作业的参数表。标准5QI值基于3GPP TS 23.501商用现网以最新版本和厂商实现为准。5QI资源类型默认优先级PDB数据包时延预算PER数据包错误率典型业务1GBR20100ms1e-2IMS语音VoNR2GBR40150ms1e-3实时会话视频3GBR3050ms1e-3实时游戏、远程操控4GBR50300ms1e-6缓冲流媒体视频65GBR775ms1e-2关键任务语音对讲66GBR20100ms1e-2非关键任务PTT语音67GBR15100ms1e-3关键任务视频5Non-GBR1100ms1e-6IMS信令6Non-GBR6300ms1e-6基于TCP的视频、直播7Non-GBR7100ms1e-3交互语音、视频8Non-GBR8300ms1e-6Web、IM等默认数据9Non-GBR9300ms1e-6默认尽力而为这张表看的时候别只盯着5QI数字。PDB决定PDCP层丢弃定时器和HARQ重传次数的上限PER决定MCS选择和重传策略。比如5QI 3的PDB只有50ms如果gNB按默认数据流的方式配了150ms的discardTimer重传次数又设满那这个业务的实际时延永远做不到50ms优化就是把这两个参数往PDB上压。除了5QI还有三个参数必须理解ARP分配保留优先级数值范围1到15越小越优先。它有两组子属性——抢占能力pre-emption capability和可被抢占pre-emption vulnerability。业务建立和切换准入时gNB先看ARP决定让谁进、让谁出。很多高优先级业务起不来的故障问题不是5QI而是ARP的抢占属性组合配错了。GBR和MBRGBR是保证比特率MBR是最大突发比特率。对GBR业务调度器先满足GBR再尽力满足MBR对Non-GBR业务没有单流GBR只有会话级AMBR。AMBR分为会话级session-AMBR和UE聚合AMBR限制的是整条PDU会话下所有Non-GBR流的总速率。做5G网络优化时单用户限速查AMBR业务卡顿查5QI和PDB建立失败查ARP三条基本规则先记住。2.3 QoS Flow到DRB的映射与反射QoSQoS Flow是核心网视图DRB是空口视图中间由SDAP层做映射。映射规则不是随便定的要考虑PDB和PER的接近程度。两个PDB差异极大的QoS Flow放进同一个DRB短时延业务会被长时延业务拖累调度器没法同时满足两组预算。常见的映射方式是把同类型、参数接近的流合并把语音、信令、普通数据分开。下面是一个配置示意drbToQosFlowMapping drb id1 qosFlow qfi1/ /drb drb id2 qosFlow qfi6/ qosFlow qfi8/ /drb drb id3 qosFlow qfi5/ /drb /drbToQosFlowMapping逻辑说明DRB 1承载QFI 1即GBR语音PDB 100ms需要独占一个高优先级队列DRB 2承载QFI 6和QFI 8两者都是Non-GBR、PDB都是300ms合并后调度目标一致不会互相拖累DRB 3放QFI 5的IMS信令优先级最高保证语音通话的呼叫流程不受数据流影响。这里的参数说明只有一句话不要把PDB差一个数量级的流塞进同一个DRB是现网最常见的映射错误。语音和视频可以共用DRB吗不建议。实时视频PDB 150ms语音100ms感知上差异不大但HARQ重传和丢弃策略完全不同共用后语音包大概率被视频包挤占。反射QoS是5G新增的机制gNB在下行数据里带上RQI反射QoS指示和QFIUE看到后自动生成一条上行QoS规则省去NAS层显式信令。这个机制理想情况能降低建立时延但商用终端的支持度参差不齐后面避坑章节会专门讲它。3. 端到端配置与优化打法核心网策略、空口调度和切片联动3.1 核心网侧怎么把业务策略变成QoS Profile5G网络优化里改QoS参数第一步不是登到基站上敲命令而是回到核心网看策略。常见做法是PCF按套餐、业务识别结果生成PCC规则SMF把PCC规则转成QoS Rule和QoS Profile再通过NGAP透传给gNB。不同厂商的OM配置界面差别很大但最终下发到gNB的内容结构是统一的可以理解成下面这组JSON{ pduSessionId: 3, qosFlows: [ { qfi: 1, fiveQi: 1, arp: { priorityLevel: 1, preEmptionCapability: may_preempt, preEmptionVulnerability: not_preemptable }, gbrUlKbps: 52000, gbrDlKbps: 52000, mbrUlKbps: 64000, mbrDlKbps: 64000 }, { qfi: 2, fiveQi: 9, arp: { priorityLevel: 8, preEmptionCapability: may_not_preempt, preEmptionVulnerability: preemptable }, sessionAmbrDlKbps: 150000, sessionAmbrUlKbps: 50000 } ] }逻辑说明QFI 1是GBR语音流5QI1上下行各保证52kbps突发峰值不超64kbpsARP优先级1且不可被抢占这是关键时刻要保住的流QFI 2是默认数据流5QI9没有单流GBR靠会话级AMBR把下行总速率限制在150Mbps、上行50Mbps。gNB接收这些参数后相当于拿到了一张粮票它按5QI、ARP和速率需求做资源分配但不会自己发明参数。参数说明priorityLevel数值越小越优先preEmptionCapability表示这条流能不能抢占别人preEmptionVulnerability表示这条流能不能被别人抢。两个属性必须搭配看只调优先级不调抢占属性高优先级流照样可能被低优先级流挡住。实际配置时行业专网里GBR流的ARP建议设1到4普通数据流设8左右不要在同一个PDU会话里把两条流全设成1否则抢占关系就没意义了。3.2 空口侧把5QI翻译成调度策略gNB拿到QoS Profile后要把它变成空口可执行的调度配置。这个过程涉及四个核心参数逻辑信道优先级、PDCP Discard Timer、HARQ最大重传次数、上行调度周期。下面这张表是我在现网调优时常用的一组起步建议值业务/5QI典型PDB逻辑信道优先级建议PDCP discardTimer建议HARQ最大重传建议5QI 1语音100ms750ms4次5QI 2实时视频150ms680ms4到5次5QI 3实时游戏/控制50ms540ms3次5QI 5 IMS信令100ms240ms4次5QI 6/8/9数据300ms3到4150ms5到6次逻辑说明把IMS信令放到优先级2是为了保证呼叫控制消息在无线侧永远有资源5QI 3的PDB只有50msdiscardTimer建议压到40msHARQ重传次数减少到3次宁可丢包也不要拖到超时。数据类业务PDB宽松可以多放重传次数提升可靠性。这个表不是死的。比如高铁场景多普勒和频繁切换会导致重传增多语音的HARQ重传次数可以放宽到5次代价是极端情况下时延会往上顶。做优化时先看这个业务的核心诉求VoNR要保住呼叫不中断URLLC要保住时延不超标eMBB要保住速率和吞吐三个目标的参数取向完全不同。上行调度周期也是一个隐藏调整点。URLLC业务希望SR周期短、BSR上报频繁这样上行授权来得快但SR周期从20ms收到1ms会让PDCCH开销和终端功耗明显上升。普通eMBB小区不建议全网改只针对特定切片的DRB做配置覆盖。3.3 切片NSSAI与5QI的联动配置5G切片在网络侧按NSSAI区分SST1典型对应eMBBSST2对应URLLCSST3对应mMTC。切片负责的是资源域划分QoS Flow负责的是业务优先级划分两者是两层东西很多同学把切片和QoS混在一起调结果切片预留了资源业务还是按默认QoS跑。切片类型SST典型值常用5QI/ARP调度建议eMBB15QI 6/8/9ARP默认大带宽、多流合并URLLC25QI 3ARP设1到3独立调度队列降低SR周期mMTC35QI 9AMBR设小大连接、低速率、长周期调度URLLC切片里仍然要区分业务关键控制信令走5QI 3非关键告警上报走5QI 9。如果切片内不做QoS细分所有业务共享同一个调度队列控制包会被视频数据拖住URLLC的时延指标照样完不成。常用做法是给URLLC切片内的每条QoS Flow配置独立的调度队列和抢占关系让控制流能随时打断数据流。切片和QoS联动的另一个坑是AMBR。mMTC切片通常把session-AMBR设得很低很多NB类业务不需要大速率但如果这个切片里混入了视频监控AMBR不够会导致视频首帧延迟拉长。碰到这种需求应当把视频流单独配一个高AMBR的QoS Flow而不是全局抬高切片AMBR。4. QoS排查避坑指南五个实测里最容易翻车的参数坑4.1 高优先级业务建立失败ARP准入控制把用户挡在门外现象VIP用户视频通话在晚高峰建立不起来RRC显示连接成功但业务PDU会话建立失败普通用户反而正常。原因核心网给这条VIP流下发的ARP priorityLevel低于现网准入阈值或者preEmptionCapability设置成may_preempt但目标资源被一条preEmptionVulnerabilitynot_preemptable的流占住了。gNB准入判决时发现高优先级流也抢不动资源只能拒绝建立。解决核对ARP三要素——priorityLevel、preEmptionCapability、preEmptionVulnerability。把VIP流的ARP提到4以内同时把低优先级承载标记为preemptable。别只调priorityLevel这个参数是优化里最容易看漏的一半。4.2 时延突然劣化5QI没匹配到该有的PDB现象某行业客户远程控制业务平均时延从50ms涨到130ms客户质疑5G不达标。原因核心网TFT规则里没匹配该业务的端口流量全部落到默认5QI 9PDB是300ms。gNB按300ms的discardTimer和低优先级调度再好的无线环境也快不起来。解决在PCF/SMF模板里给目标端口段配置专用5QI工业控制类业务匹配5QI 3或厂家自定义的低时延Non-GBR 5QI同时检查PDCP discardTimer是否与5QI匹配。抓包确认UE实际建立的是哪个QFI不要只看核心网配置里写了什么。4.3 限速时快时慢会话AMBR与单流MBR边界混淆现象用户测速稳定在150Mbps上限调制方式256QAM、MCS很高无线环境没问题但速率就是上不去。原因PDU会话级下行AMBR被核心网控制在150Mbps用户套餐在SMF侧限制了速率。有人把MBR改成和GBR一样大发现没用因为MBR管单流AMBR管整条会话所有Non-GBR流的总和。解决在SMF或PCF的订阅数据里查session-AMBR的实际值。测速时在UPF边界抓GTP-U吞吐如果核心网出口就是150Mbps问题不在无线改基站参数无效。要提速就提升session-AMBR或者给高价值业务单独开一条高AMBR的QoS Flow。4.4 反射QoS的玄学不生效导致直播卡顿现象专网终端直播业务间歇性卡顿核心网侧能看到QoS Flow建立但gNB侧QFI统计没有按预期走。原因反射QoS要求UE在DL数据里读取RQI和QFI并自动生成上行规则很多终端没完整实现这个能力。核心网以为反射规则生效了实际UE还在用默认QoS Flow直播数据全走低优先级。解决不赌反射QoS核心网在PDU会话建立时对每条流显式下发QoS Rule最稳。如果确实要开启反射抓DL SDAP层数据确认SDAP头里带了RQI1并且终端在收到后生成了反向QoS规则再考虑使用。4.5 调度权重翻车保障一条流饿死一堆用户现象给VIP用户开了直播保障后同一小区普通用户网页打开要转圈TCP重传明显上升。原因保障时给VIP的GBR流配置了过高的逻辑信道优先级和比特率配额普通Non-GBR流长期抢不到调度机会高峰期几乎零资源。解决区分绝对保障和相对保障。GBR流的调度目标是满足GBR速率且不超PDB没必要把所有PRB都喂给它。普通数据流设置最低资源保障比如minimum PRB ratio 10%逻辑信道优先级不要给到0或1。上线前用小流量做两小时压测别拿VIP单用户测速通过就算完。5. 信令和KPI验证怎么证明QoS真的生效5.1 用tshark从NGAP信令里读5QI和AMBR参数调完要验证验证靠信令抓包。N2接口在gNB和AMF之间PDU会话建立时NGAP消息里带完整的QoS Flow配置用tshark可以快速提取关键字段tshark -r n2_trace.pcapng -Y ngap -T fields \ -e ngap.pdu_session_id \ -e ngap.qos_flow_setup_request_item.qos_flow_identifier \ -e ngap.qos_flow_setup_request_item.qos_flow_level_qos_parameters.five_qi \ -e ngap.qos_flow_setup_request_item.qos_flow_level_qos_parameters.arp.priority_level逻辑说明这条命令把每个PDU会话建立请求里的PDU会话号、QFI、5QI、ARP优先级一次性列出来直接对比核心网配置和实际下发的差异。它是只读操作不修改任何网络参数。参数说明tshark的协议字段名随版本有差异运行前先执行tshark -G fields | grep -i qos_flow查当前版本的字段名。如果抓包文件里只有SETUP消息没有后续MODIFY只能看到建链时刻的QoS参数业务切换5QI要看QoS Flow Modification消息不要拿SETUP的包说参数没改。5.2 KPI定义把QoS参数翻译成可监控指标指标定义建议阈值对出问题参数方向QoS Flow建立成功率核心网下发且gNB回复建立的Flow数除以请求数按5QI维度拆99.9%以上5QI、ARP冲突准入策略GBR业务时延达标率满足PDB的数据包占比按5QI维度拆98%以上PDCP discardTimer、HARQ重传次数QoS Flow异常释放比例空口抖动、切换导致Flow释放的比例0.5%以下DRB映射、ARP抢占AMBR限速事件数会话超过AMBR被限速的次数按套餐设计值评估session-AMBR、MBR抢占失败次数高优先级流尝试抢占却失败的次数越低越好preEmptionCapability/Vulnerability这些指标是现网优化排障的主要抓手。QoS Flow建立成功率低重点查核心网策略时延达标率低重点查无线侧调度参数异常释放比例高重点查切换和DRB重映射。KPI只能告诉你问题在哪一层定位到具体参数还得靠信令确认。5.3 路测验证清单参数改完别直接在后台看数据做一轮路测按业务类型逐个验证语音类VoNR呼叫接通率和MOS分确认5QI1的QoS Flow建立Ping包时延和抖动是否稳定在PDB内。 交互类Ping时延对比5QI 3和默认5QI 9下的差异URLLC业务要验证端到端时延低于目标值。 速率类单用户下行吞吐、上行吞吐确认到达AMBR的限速边界是否和配置一致。 切换类跨gNB切换后QoS Flow是否完整保留QFI和5QI是否在切换前后保持一致。5.4 参数改了怎么观察效果改QoS参数不是改完立刻测速就完事。PDU会话是长链接正在进行的业务不会因为模板变更而立即切换到新规则需要等待会话重建或UE重新发起业务。建议操作顺序是先改核心网模板再触发终端重新建立PDU会话抓NGAP确认新5QI已下发然后观察15分钟KPI趋势。千万不要在高峰期批量改全网模板如果某个逻辑信道优先级配错半小时内整个小区业务都会崩。小范围灰度确认无劣化再扩大这条规矩适用于所有QoS相关调整。6. 一条实用技巧从QFI的成功率判断QoS问题出在核心网还是无线当QoS Flow建立成功率下降时别急着抓全网信令先从QFI维度做一次聚合统计。面试时我常问一句话同一个PDU会话里同时下发了三条QoS Flow两条成功、一条失败问题大概率在哪一层答案很明确——若核心网意图下发多条流gNB只回了一条成功问题多半在空口映射或调度资源少数情况是DRB数量不够若gNB对整条会话直接拒绝问题多半在ARP准入或无线资源预留。这个判断逻辑能省掉一半排障时间。实际操作可以先做文本化导出把每次QoS Flow建立结果按QFI和状态记下来再用一个简单脚本聚合from collections import defaultdict stats defaultdict(lambda: {ok: 0, fail: 0}) with open(qos_flows.txt) as f: for line in f: line line.strip() if not line or , not in line: continue try: qfi, result line.split(,) ok result 1 stats[qfi][ok if ok else fail] 1 except ValueError: continue except Exception: continue for qfi, v in sorted(stats.items()): total v[ok] v[fail] if total 0: continue print(fQFI{qfi:2} success{v[ok]:4} fail{v[fail]:4} rate{v[ok] / total:.2%})逻辑说明这段脚本把二维表重新聚合成QFI维度的成功率输出示例类似QFI 1 success 998 fail 2 rate99.80%。如果某条QFI的失败集中在某个小区去查那个小区的逻辑信道优先级和资源预留如果全城市都失败去查核心网模板里这条流对应的5QI和ARP配置。按这个方向查比抓整个N2接口全量包要快得多。数据来源不一定是信令平台现网OM的QoS Flow统计导出CSV后简单清洗成每行一个QFI状态记录就能喂给脚本。验证完毕后还有一件容易忽略的事把改动前后的信令截图和KPI对比保存到工单里。QoS参数跨核心网、传输、基站三层两个月后回头看没人记得当时为什么把某条流的discardTimer从150ms改成80ms。我一直的习惯是每改一组参数就写一条为什么改、改了什么、用哪个指标验证、观察多久这份干下来的经验比PPT上任何一页都值钱。希望帮到你。本文还有配套的精品资源点击获取