先用一个物流类比开场。你要发三批货：一批生鲜、一批文件、一批普通纸箱。
4G的做法像包车：生鲜得包一辆冷藏车，文件走一辆专车，纸箱再包一辆。每辆车从装货到卸货全程封闭，挂一块专属牌照，整套服务标准锁死在这辆车上。临时想加一种货？对不起，重新签合同、重新排车，手续慢、成本高。
5G的做法像贴面单的分拣：所有货都装同一班干线卡车，每件包裹贴一张电子面单——上面写着「生鲜、优先送」「纸箱、有空再送」。分拣中心扫面单决定先后顺序和运输方式，加一种货只需要换一张面单，卡车不用换。
这个差别，就是5G QoS体系改造的核心：4G用「承载」做QoS的单位，5G用「流」做QoS的单位。本文就来拆解这套新体系：5QI速查表、ARP双开关、反射QoS、SDAP新楼层——每一处设计背后，都对应着4G的一个痛点。
4G的QoS模型叫EPS承载（EPS Bearer）：手机到核心网网关之间的一条逻辑管道。开机先建一条默认承载，尽力而为地跑普通流量；需要特殊待遇的业务（比如VoLTE语音），再建一条专用承载，每条承载挂一套QoS参数。
这个模型在2010年前后够用，但三个裂缝越来越大：
第一，粒度太粗。 一条承载=一套QoS参数。同一类业务里再细分优先级，做不到；同一个应用的不同数据（控制信令要快、大文件要吞吐），只能拆成两条承载。
第二，改QoS要动控制面。 建/改专用承载需要核心网与手机之间来回跑NAS信令。面对物联网时代动辄百万级的连接、以及频繁变化业务特征的场景，这会演变成信令风暴——网络没被数据流量压垮，先被「申请资源」的信令压垮了。
第三，垂直行业的需求对不上。 工业现场要求同一条连接里，传感器心跳、控制指令、视频回传三种数据混合跑，且各自待遇天差地别。承载模型是「一条管道一套标准」，硬套上去非常僵硬。
5G把QoS拆成了三层结构：
flowchart TD
subgraph E["4G：一条承载管一类业务"]
A1["PDN连接"] --> A2["默认承载"]
A1 --> A3["专用承载<br/>语音"]
A1 --> A4["专用承载<br/>视频"]
A3 --> A5["一条承载<br/>一套参数"]
end
subgraph F["5G：一个会话挂多条流"]
B1["PDU会话"] --> B2["默认QoS流"]
B1 --> B3["语音流<br/>5QI=1"]
B1 --> B4["URLLC流<br/>5QI=82"]
B1 --> B5["大流量流<br/>5QI=9"]
end
最外层是PDU会话：手机和核心网用户面之间的一条IP通道，相当于那班干线卡车。每个会话必须有一条默认QoS流兜底。会话内部，按业务特征拆出多条QoS流，每条流有自己的QoS画像，用一个6比特的QFI（QoS Flow ID）标记——所以一个会话里的流数量上限是几十条的量级，足够用。
关键的设计决策在这里：QoS流是纯逻辑概念。它没有专属的物理通道，所有的流共享PDU会话的隧道，靠每个数据包头上那几个比特的QFI标签区分待遇。建一条新流，多数时候只是网络里的几条配置记录变了，不再需要端到端重铺管道。
数据包下行时的完整旅程是这样的：
flowchart TD
UPF["UPF<br/>给每个包贴QFI标签"] --> GNB["gNB<br/>按流做准入与调度"]
GNB --> SDAP["SDAP层<br/>QFI写进包头"]
SDAP --> DRB1["DRB1<br/>语音流"]
SDAP --> DRB2["DRB2<br/>默认流"]
DRB1 --> UE["手机<br/>按QFI分给应用"]
DRB2 --> UE
注意最后一段：到了空口，多条QoS流可以捆绑进同一条DRB（数据无线承载）传输，怎么捆绑由基站根据流特征决定。流是「待遇等级」，DRB才是「空口车道」，两者是多对一的关系——这也是后文常见误解的来源之一。
每条QoS流都需要一套完整的QoS参数：调度优先级、时延预算、丢包率……如果每条流都要逐项传输、逐项配置，信令和运维成本都会很高。
5G的设计非常聪明：把这些参数打包成一张标准速查表，每行给一个编号，这个编号就是5QI（5G QoS Identifier）。信令里只传一个整数，设备查表还原全部参数。标准的5QI从1编到255，挑出最有代表性的业务画像做了标准化。最常见的几行：
| 5QI | 资源类型 | 典型业务 | 优先级 | 时延预算PDB | 丢包率PER |
|---|---|---|---|---|---|
| 1 | GBR | 会话式语音（VoNR） | 20 | 100ms | 10⁻² |
| 2 | GBR | 会话式视频 | 40 | 150ms | 10⁻³ |
| 3 | GBR | 实时游戏 | 30 | 50ms | 10⁻³ |
| 65 | GBR | 关键任务对讲 | 7 | 75ms | 10⁻² |
| 82 | 延时关键GBR | 智能电网配电自动化 | 18 | 10ms | 10⁻⁴ |
| 5 | Non-GBR | IMS信令 | 10 | 100ms | 10⁻⁶ |
| 7 | Non-GBR | 语音/视频直播 | 70 | 100ms | 10⁻³ |
| 8 | Non-GBR | 普通上网业务 | 80 | 300ms | 10⁻⁶ |
| 9 | Non-GBR | 默认流（现网最常见） | 90 | 300ms | 10⁻⁶ |
一张速查表，至少带来三个好处：
省信令。 建立「语音级」的流，核心网只需下发5QI=1，不用搬一整套参数结构体。
保互通。 手机厂商、基站厂商、核心网厂商对「5QI=1」的理解天然一致——语音就是100ms预算、允许百分之一丢包。跨厂商组网不会出现「A厂理解的语音时延和B厂不一样」的尴尬。
减运维。 运营商的签约数据和设备配置里，一个数字替代一整页参数，配置出错的概率大幅下降。
当然，标准表格之外还留了口子：运营商可以自定义5QI取值，通过PLMN级预配置告知网络各节点，配合动态QoS参数使用——这主要服务于行业专网的特殊画像。
一条流的完整QoS画像，用公式概括就是：
$$\text{QoS参数集} = {\,\text{5QI},\ \text{ARP},\ \text{GFBR},\ \text{MFBR},\ \text{MDBV},\ \text{平均窗口}\,}$$
其中GBR流才需要带宽参数（保证比特率GFBR/最大比特率MFBR），延时关键GBR流才需要最大突发量MDBV。这里有个容易忽略的细节：带宽承诺不是瞬时值。GFBR/MFBR的测量基于「平均窗口」，网络看的是窗口期内的平均速率。为什么这样设计？因为包是突发的，要求每一微秒都达标在物理上无意义，窗口平均才是可执行的承诺。
另一个精妙细节是时延预算PDB的统计语义：PDB不是「每个包都必须达标」，而是以98%的置信度达标——允许2%的包超时。为什么这样设计？无线信道有深衰落，追求100%达标意味着为最坏情况留足冗余，绝大多数时间的容量都被浪费了。98%是工程上的甜点位。
还有一个反直觉的设计：语音流的丢包率敢放宽到10⁻²（允许丢1%）。直觉上语音不该丢包，但换一个视角：迟到的语音帧等于丢了的语音帧——对话是实时的，超时100ms的帧重传送达也已经没用了，播放窗口早就过去。与其把预算花在注定无效的重传上，不如放宽丢弃、把时延死死守住。时延优先于可靠性，这是实时业务的铁律，也被写进了速查表。
看速查表你会发现一个疑问：5QI里已经有「优先级」了，为什么还有一套独立的ARP（Allocation and Retention Priority，分配与保持优先级）？这不是重复设计吗？
还真不是，这两个优先级管的事完全不同：
| 维度 | 5QI优先级 | ARP优先级 |
|---|---|---|
| 取值范围 | 随5QI固定（数字越小越优先） | 1~15，数字越小越优先 |
| 管什么 | 包转发时排队的先后（数据面） | 建立时能否进门、拥塞时谁被挤走（控制面） |
| 生效时机 | 每时每刻，作用于每个包 | 建/改流的那一刻 |
| 类比 | 行驶中的路权 | 登机舱位 |
| 能否单独调整 | 换5QI才能变 | 可独立指配 |
一个典型场景说明为什么必须分开：某工厂部署了一条大带宽的备份传输链路，数据量大、传输时间长，但一旦真出事必须立刻建起来。这条流按业务特征会分到一个并不高的5QI优先级；但它的ARP可以设成最高档——准入时无人能挡，还能挤掉别人。反过来，一条语音流5QI优先级很高（转发时最优先），但可以是「可被抢占」的，等级更高的公安指挥流建起来时它可以被请下车。
ARP由三个字段组成：优先级（1~15），外加两个独立开关——抢占能力（我能不能抢别人）和抢占脆弱性（我肯不肯被抢）。为什么拆成两个开关而不是一个属性？设想只有一个「等级」字段：两个同级流相遇时，谁让谁？各按自己的理解行事就会出现互抢死锁。两个独立开关把「进攻」和「防守」解耦，网络可以明确编排「谁动谁不动」，策略空间完整且无歧义。
一条新流的落地过程，要过两道关卡：
flowchart TD
S["新业务流请求建立"] --> G1{"第一关 准入控制<br/>查ARP与资源余量"}
G1 -->|拒绝| X["建立失败或排队等待"]
G1 -->|通过| G2["第二关 每包调度<br/>按5QI优先级与时延预算排队"]
G2 --> R["空口稳定传输"]
第一关是控制面的准入决策，看ARP和剩余资源；第二关是数据面的每包调度，看5QI优先级和PDB。顺便把GBR和Non-GBR也放进这个框架里说清楚：GBR流过第一关时申请座位预留（带宽资源被记账占用），Non-GBR流只领一张站票，没有带宽承诺，还要受会话级总闸（AMBR）限速。座位预留的微观机制，上一篇《订座与让座》已经详细讲过，本文不重复。
还有一个工程问题：下行数据从核心网流向基站，QFI标签网络说了算；可上行呢？手机怎么知道某个上行的数据包该打什么QFI、走哪条流？
最直接的办法是给每条流下发显式的QoS规则——4G时代就是这么用TFT过滤器干的。但5G想再省一笔信令，于是有了反射QoS（Reflective QoS）：让手机照镜子自学。
sequenceDiagram
participant U as 手机UE
participant G as 基站gNB
participant C as UPF
C->>G: 下行包带QFI与RQA标记
G->>U: 空口转发包头含QFI
Note over U: 记录该流的包过滤器<br/>自动生成上行QoS规则
U->>G: 上行包按同样过滤器发送
G->>C: 映射回同一QoS流
网络在下行包上除了打QFI，还可以带上一个RQA标记。手机看到RQA，就把这个下行流的包过滤器（IP五元组特征）记下来，自动生成一条镜像的上行规则——之后凡是匹配这个特征的上行包，都按同样的QFI发送。全程不需要一条NAS信令。
为什么这样设计？对控制流和数据流高度对称的业务（工控主从通信、请求响应类应用、音视频对讲），上行画像基本是下行的镜像，让手机「抄作业」既准确又零成本。信令开销省下来，对海量连接场景就是真金白银。
前面所有的「待遇」最终都要落到空口执行。4G的协议栈里，PDCP层直接对接IP层；5G在两者之间新加了一层SDAP（服务数据适配协议），专职两件事：把QFI写进数据包头，以及决定QoS流到DRB的映射。
为什么非要加一层？因为4G的承载模型里，「QoS单位」和「空口管道」是一条承载一以贯之的，不需要中间翻译；5G把两者解耦之后，必然需要一个角色来做「流」与「车道」之间的映射表——这就是SDAP的存身之处。映射规则支持配置，也支持SDAP自带的反射映射机制让手机自学。
不只是空口，N3接口（基站到UPF）的GTP-U隧道里，QFI也通过扩展头随包携带。于是一个数据包从UPF到手机，QFI标签全程随身：核心网段在GTP-U扩展头里，空口段在SDAP包头里。任何一段丢了标签，这条流的待遇就会掉回默认，这也是排障时的重要观测点。
这套原理落到工程上，有几个高频出没的场景：
抓包看什么。 在N3口抓GTP-U报文，展开扩展头看QFI是否与规划的流一致；在空口信令里看QoS流的建立/修改消息，重点核对5QI和ARP字段；NAS层的QoS规则能确认手机是否正确收到了流的定义。
经典故障：VoNR语音MOS值差。 现网排查语音质量问题时，第一件事就是确认语音媒体包是否真的跑在5QI=1的流上。如果专载建立失败（常见原因：ARP抢占被拒、空口准入失败）而呼叫照常接通，媒体包会静默回落到5QI=9的默认流——电话能打通，但和普通上网流量挤在300ms预算的队伍里，语音质量自然拉胯。现象在空口，根因在QoS准入。
行业专网不通。 URLLC类业务调不通时，逐段核对5QI是否配置成了82~85这类延时关键档位、MDBV突发量参数两端是否一致、运营商自定义5QI时PLMN预配置是否下发到位。行业专网里「参数在核心网是对的、到了基站查表查不到」是高频坑。
五个常见误解，一次澄清：
Q: 5QI优先级和ARP到底谁说了算？ A: 分阶段。流建立那一刻，ARP是唯一裁判——能不能建起来、要不要挤掉别人，全看ARP和资源余量；一旦建起来进入传输，ARP就靠边站，每个包的排队先后由5QI优先级和PDB决定。一个是舱位，一个是路权。
Q: GBR业务是不是绝对不会卡顿？ A: 不是。GBR是准入时的资源预留承诺，给调度器兑现待遇的资格。深衰落、邻区干扰等物理层的现实，可能让任何一个包超时或丢失——所以语音GBR才敢定义1%的丢包容忍。GBR保证的是「下限资源存在」，不是「物理层零失败」。
Q: 一条PDU会话最多能有多少条QoS流？ A: QFI是6比特字段，取值0~63，所以一个会话内的流数量上限是64条。够用的原因在于：流是待遇等级而非业务通道，同类待遇的业务本就应合并成一条流。
Q: Non-GBR就是没有QoS吗？ A: 不是。Non-GBR流同样有5QI优先级、时延预算和丢包率目标，只是不做带宽预留，且受会话级AMBR限速。它和GBR的差别只在「有没有座位承诺」，待遇排序上照样有高低贵贱。
Q: 反射QoS和SDAP的反射映射是一回事吗？ A: 不是，是两处独立的「照镜子」。反射QoS发生在NAS层，手机自学的是上行QoS规则（包该打什么QFI）；SDAP反射映射发生在空口协议栈，手机自学的是流到DRB的映射（打好的包该走哪条车道）。两者都为了省信令，管的是不同环节。
本文由「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 等场景全覆盖。