企业官网建设流程全解析

简介：《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到9），UE发起业务后，核心网PCC（PCRF/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里把QCI一改就解决问题，5G里改了5QI却不见效。因为5G的QoS决策点前移到了核心网SMF，gNB只是执行方，你在基站侧改调度参数，核心网策略没有同步，业务依然会被拉到旧的QoS Flow上。

2.2 5QI、ARP、AMBR参数表：把标准值抄下来用

这一小节直接给能抄作业的参数表。标准5QI值基于3GPP TS 23.501，商用现网以最新版本和厂商实现为准。

这张表看的时候别只盯着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和MBR：GBR是保证比特率，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的映射与反射QoS

QoS Flow是核心网视图，DRB是空口视图，中间由SDAP层做映射。映射规则不是随便定的，要考虑PDB和PER的接近程度。两个PDB差异极大的QoS Flow放进同一个DRB，短时延业务会被长时延业务拖累，调度器没法同时满足两组预算。常见的映射方式是把同类型、参数接近的流合并，把语音、信令、普通数据分开。下面是一个配置示意：

<drbToQosFlowMapping> <drb id="1"> <qosFlow qfi="1"/> </drb> <drb id="2"> <qosFlow qfi="6"/> <qosFlow qfi="8"/> </drb> <drb id="3"> <qosFlow qfi="5"/> </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指示）和QFI，UE看到后自动生成一条上行QoS规则，省去NAS层显式信令。这个机制理想情况能降低建立时延，但商用终端的支持度参差不齐，后面避坑章节会专门讲它。

3. 端到端配置与优化打法：核心网策略、空口调度和切片联动

3.1 核心网侧怎么把业务策略变成QoS Profile

5G网络优化里改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语音流，5QI=1，上下行各保证52kbps，突发峰值不超64kbps，ARP优先级1且不可被抢占，这是关键时刻要保住的流；QFI 2是默认数据流，5QI=9，没有单流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最大重传次数、上行调度周期。下面这张表是我在现网调优时常用的一组起步建议值：

逻辑说明：把IMS信令放到优先级2，是为了保证呼叫控制消息在无线侧永远有资源；5QI 3的PDB只有50ms，discardTimer建议压到40ms，HARQ重传次数减少到3次，宁可丢包也不要拖到超时。数据类业务PDB宽松，可以多放重传次数，提升可靠性。

这个表不是死的。比如高铁场景，多普勒和频繁切换会导致重传增多，语音的HARQ重传次数可以放宽到5次，代价是极端情况下时延会往上顶。做优化时先看这个业务的核心诉求：VoNR要保住呼叫不中断，URLLC要保住时延不超标，eMBB要保住速率和吞吐，三个目标的参数取向完全不同。

上行调度周期也是一个隐藏调整点。URLLC业务希望SR周期短、BSR上报频繁，这样上行授权来得快；但SR周期从20ms收到1ms会让PDCCH开销和终端功耗明显上升。普通eMBB小区不建议全网改，只针对特定切片的DRB做配置覆盖。

3.3 切片NSSAI与5QI的联动配置

5G切片在网络侧按NSSAI区分，SST=1典型对应eMBB，SST=2对应URLLC，SST=3对应mMTC。切片负责的是"资源域"划分，QoS Flow负责的是"业务优先级"划分，两者是两层东西，很多同学把切片和QoS混在一起调，结果切片预留了资源，业务还是按默认QoS跑。

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，但目标资源被一条preEmptionVulnerability=not_preemptable的流占住了。gNB准入判决时发现高优先级流也抢不动资源，只能拒绝建立。

解决：核对ARP三要素——priorityLevel、preEmptionCapability、preEmptionVulnerability。把VIP流的ARP提到4以内，同时把低优先级承载标记为preemptable。别只调priorityLevel，这个参数是优化里最容易看漏的一半。

4.2 时延突然劣化：5QI没匹配到该有的PDB

现象：某行业客户远程控制业务平均时延从50ms涨到130ms，客户质疑5G不达标。

原因：核心网TFT规则里没匹配该业务的端口，流量全部落到默认5QI 9，PDB是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头里带了RQI=1，并且终端在收到后生成了反向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建立成功率低，重点查核心网策略；时延达标率低，重点查无线侧调度参数；异常释放比例高，重点查切换和DRB重映射。KPI只能告诉你问题在哪一层，定位到具体参数还得靠信令确认。

5.3 路测验证清单

参数改完别直接在后台看数据，做一轮路测，按业务类型逐个验证：

语音类：VoNR呼叫接通率和MOS分，确认5QI=1的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(f"QFI={qfi:>2} success={v['ok']:>4} fail={v['fail']:>4} rate={v['ok'] / total:.2%}")

逻辑说明：这段脚本把二维表重新聚合成QFI维度的成功率，输出示例类似QFI= 1 success= 998 fail= 2 rate=99.80%。如果某条QFI的失败集中在某个小区，去查那个小区的逻辑信道优先级和资源预留；如果全城市都失败，去查核心网模板里这条流对应的5QI和ARP配置。按这个方向查，比抓整个N2接口全量包要快得多。数据来源不一定是信令平台，现网OM的QoS Flow统计导出CSV后，简单清洗成"每行一个QFI状态记录"就能喂给脚本。

验证完毕后还有一件容易忽略的事：把改动前后的信令截图和KPI对比保存到工单里。QoS参数跨核心网、传输、基站三层，两个月后回头看，没人记得当时为什么把某条流的discardTimer从150ms改成80ms。我一直的习惯是每改一组参数就写一条"为什么改、改了什么、用哪个指标验证、观察多久"，这份干下来的经验比PPT上任何一页都值钱。希望帮到你。

本文还有配套的精品资源，点击获取