你打开手机,同时进行视频通话、下载文件、浏览网页——三种业务,为什么视频通话不卡顿、下载飞快、网页也能正常打开?这背后不是"带宽够大就行",而是一套精密的流量分级治理系统在默默工作。
今天我们拆解5G网络中最核心的资源管理机制:QoS(服务质量)与网络切片(Network Slicing)。从为什么需要它、怎么分级、到现网怎么配置,一口气讲透。
想象一条10车道的高速公路,上面同时跑着:
| 车辆类型 | 类比业务 | 需求特征 |
|---|---|---|
| 救护车 | 远程手术/VoNR语音 | 延迟必须极低,绝对不能堵 |
| 公交车 | 视频会议 | 需要保证最低速度 |
| 私家车 | 网页浏览 | 尽力而为,能跑就行 |
| 货车 | 后台同步/软件更新 | 不急, cheapest delivery |
如果所有车都平等共享车道,救护车可能被货车堵住。QoS就是这套"交通规则":谁优先走、谁让路、谁保证最低速度。
5G网络面临的挑战比4G更复杂——它不再只服务手机用户,还要服务自动驾驶、工业机器人、智慧城市等截然不同的场景。一套交通规则不够用了,于是5G引入了网络切片——相当于为不同类型的车修专用车道,甚至在同一条高速公路上虚拟出多条"专用高速公路"。
4G LTE用EPS Bearer(演进分组系统承载)来管理QoS。每个承载绑定一组QoS参数,UE和PGW之间建立承载隧道。
问题在于:一个承载只能有一种QoS特征。如果你的手机同时跑语音(需要低延迟)和下载(需要大带宽),就必须建立多个承载。每建一个承载都需要信令交互,开销大、延迟高、不够灵活。
4G EPS Bearer模型(简化):
UE ───[Default Bearer (QCI=9)]─── eNodeB ─── SGW ─── PGW
│
[Dedicated Bearer (QCI=1)] ← 语音需要额外建立
5G把"承载"的概念拆成了更灵活的QoS Flow。核心区别在于:
| 对比维度 | 4G EPS Bearer | 5G QoS Flow |
|---|---|---|
| 粒度 | 承载级(较粗) | QoS Flow级(更细) |
| 一个会话内 | 一个承载=一种QoS | 一个PDU Session可含多个QoS Flow |
| 建立方式 | 每个承载需专用信令 | 新QoS Flow可复用已有DRB |
| 标识 | EPS Bearer ID | QFI(QoS Flow Identifier) |
| 空口映射 | 1:1映射到DRB | 多个QoS Flow可映射到同一DRB |
| 反射QoS | 不支持 | 支持(RQoS,减少信令) |
关键洞察:5G的设计哲学是"先建隧道,再贴标签"。一个PDU Session建好后,可以在这个隧道里标记不同的QoS Flow,不需要每次都重新建隧道。
graph TB
subgraph "4G LTE QoS模型"
UE4[UE] -->|Default Bearer<br/>QCI=9| eNB[eNodeB]
UE4 -->|Dedicated Bearer<br/>QCI=1 语音| eNB
UE4 -->|Dedicated Bearer<br/>QCI=4 视频| eNB
eNB --> SGW --> PGW
end
subgraph "5G NR QoS模型"
UE5[UE] -->|"PDU Session"| gNB[gNodeB]
gNB --> UPF
style gNB fill:#e1f5fe
subgraph "同一个PDU Session"
QF1["QoS Flow 1<br/>5QI=1 语音<br/>QFI=1"]
QF2["QoS Flow 2<br/>5QI=2 视频通话<br/>QFI=2"]
QF9["QoS Flow 3<br/>5QI=9 上网<br/>QFI=9"]
end
QF1 -->|"映射到"| DRB1[DRB 1]
QF2 -->|"映射到"| DRB1
QF9 -->|"映射到"| DRB2[DRB 2]
end
5G引入了一个聪明机制:反射QoS(Reflective QoS, RQoS)。
原理很简单——UE观察下行数据包的QFI标记,"反向推导"上行数据应该用哪个QoS Flow。这样,网络不需要为上行流量单独发送QoS规则信令,UE自己就能学会。
类比:就像你收到一个信封,上面写着"加急"标签。你回信时,自然也会用同样级别的快递。不需要对方专门打电话告诉你"回信也请用加急"。
5QI(5G QoS Identifier) 是一个标量值,相当于每个数据包的"服务等级身份证号"。网络看到5QI,就知道这个数据包需要什么样的延迟、丢包率、优先级处理。
每个5QI对应一组预定义的QoS特征参数:
| 参数 | 含义 | 取值范围 |
|---|---|---|
| Resource Type | 资源类型 | GBR / Non-GBR / Delay-Critical GBR |
| Priority Level | 调度优先级 | 1(最高)~ 127(最低) |
| PDB(Packet Delay Budget) | 分组延迟预算 | 1ms ~ 300ms |
| PER(Packet Error Rate) | 分组错误率 | 10⁻² ~ 10⁻⁶ |
| MDBV | 最大数据突发量 | 仅Delay-Critical GBR |
| Averaging Window | 平均窗口 | GBR流用于速率计算 |
这是理解5G QoS的关键概念:
GBR(保证比特速率)——"包你最低速度"
类比:你办了100M宽带,运营商承诺至少给你50M。即使网络拥堵,你的50M也必须保障。
Non-GBR(非保证比特速率)——"尽力而为"
类比:公共WiFi,人少时飞快,人多时变慢。没有任何速率承诺。
Delay-Critical GBR(延迟关键型GBR)——Rel-16新增的"极客模式"
类比:远程手术——既需要保证带宽,又需要极低延迟,数据突发量大但有上限。
| 5QI | 资源类型 | 优先级 | PDB | PER | 典型业务 |
|---|---|---|---|---|---|
| 1 | GBR | 20 | 100ms | 10⁻² | VoNR语音通话 |
| 2 | GBR | 40 | 150ms | 10⁻³ | 视频通话 |
| 3 | GBR | 30 | 50ms | 10⁻³ | 实时游戏 |
| 4 | GBR | 50 | 300ms | 10⁻⁶ | 视频流媒体 |
| 5 | Non-GBR | 10 | 100ms | 10⁻⁶ | IMS信令 |
| 9 | Non-GBR | 90 | 300ms | 10⁻⁶ | 默认上网流量 |
| 69 | Non-GBR | 5 | 5ms | 10⁻⁶ | AR/VR低延迟 |
| 80 | Non-GBR | 68 | 10ms | 10⁻⁶ | 低延迟游戏 |
| 84 | Non-GBR | 72 | 10ms | 10⁻⁶ | 大规模IoT |
| 10 | DC-GBR | 12 | 5ms | 10⁻⁵ | V2X消息 |
| 11 | DC-GBR | 10 | 10ms | 10⁻⁵ | 工业自动化 |
注意:5QI值和优先级不一定是线性关系。5QI=5的优先级(10)反而比5QI=1(20)更高——因为IMS信令必须在语音之前就建立好。
当网络资源不够用时,谁该让路?ARP(Allocation and Retention Priority,分配和保持优先级)就是裁判。它有三个维度:
| ARP参数 | 含义 | 取值 |
|---|---|---|
| Priority Level | 优先级 | 1(最高)~ 15(最低) |
| Pre-emption Capability | 抢占能力 | 能/不能抢占别人的资源 |
| Pre-emption Vulnerability | 被抢占易感性 | 能/不能被别人抢占 |
类比:ARP就像高铁的座位系统—— - Priority Level:你是商务座、一等座还是二等座 - Pre-emption Capability:你是否可以"升舱"(占用别人的座位) - Pre-emption Vulnerability:你的座位是否可能被别人占走
sequenceDiagram
participant UE1 as UE1 语音通话<br/>(ARP=1, 能抢占, 不被抢)
participant gNB as gNodeB
participant UE2 as UE2 上网流量<br/>(ARP=15, 不抢占, 能被抢)
Note over gNB: 无线资源即将用尽
UE1->>gNB: 请求建立QoS Flow<br/>(5QI=1, ARP Priority=1)
gNB->>gNB: 检查资源:不足!<br/>但UE1的ARP=1可抢占
gNB->>UE2: 释放UE2部分Non-GBR资源
Note over UE2: 上网速度变慢<br/>但连接不断
gNB->>UE1: QoS Flow建立成功<br/>资源从UE2处"抢"来
Note over UE1: 语音通话质量有保障
实战要点:在运营商网络中,语音业务通常配置ARP Priority=1,且"能抢占、不被抢"。普通上网业务ARP Priority=15,"不能抢占、能被抢"。这就是为什么即使网络很拥堵,你的电话依然能打通。
很多工程师容易混淆ARP和5QI。记住这个区分:
| 维度 | 5QI | ARP |
|---|---|---|
| 管什么 | 数据包的转发质量(延迟、丢包率) | 资源分配的优先级和抢占 |
| 什么时候生效 | 数据传输过程中 | 建立QoS Flow时、拥塞时 |
| 能改吗 | 建立后一般不变 | 可动态调整 |
| 比喻 | 快递的"加急/普通"标签 | 谁有权利占用快递车 |
QoS是"在同一张网络上优先处理某些流量",而网络切片更进一步——在一张物理网络基础设施上,虚拟出多张逻辑独立的网络,每张虚拟网络有自己独立的:
graph TB
subgraph "物理网络基础设施"
RAN[无线接入网<br/>gNodeB]
TN[传输网<br/>SPN/OTN]
CN[核心网<br/>NF Pool]
end
RAN -->|"资源切片"| S1 & S2 & S3
TN -->|"通道隔离"| S1 & S2 & S3
CN -->|"NF实例化"| S1 & S2 & S3
subgraph S1["切片1: eMBB(手机用户)"]
AMF1[AMF-1] --- SMF1[SMF-1] --- UPF1[UPF-1]
UPF1 --> Internet[Internet]
style S1 fill:#e8f5e9
end
subgraph S2["切片2: URLLC(工业控制)"]
AMF2[AMF-2] --- SMF2[SMF-2] --- UPF2[UPF-2<br/>边缘部署]
UPF2 --> Factory[工厂内网]
style S2 fill:#fff3e0
end
subgraph S3["切片3: mMTC(物联网)"]
AMF3[AMF-3] --- SMF3[SMF-3] --- UPF3[UPF-3]
UPF3 --> IoT[IoT平台]
style S3 fill:#e3f2fd
end
每个网络切片由S-NSSAI(Single Network Slice Selection Assistance Information)唯一标识。它包含两部分:
| 字段 | 含义 | 说明 |
|---|---|---|
| SST(Slice/Service Type) | 切片业务类型 | 标准化值:1=eMBB, 2=URLLC, 3=mMTC;运营商可自定义128~255 |
| SD(Slice Differentiator) | 切片区分符 | 可选字段,用于区分同一SST下的不同切片实例 |
实际案例:
S-NSSAI = {SST=1, SD=无} → 运营商默认eMBB切片(所有手机用户)
S-NSSAI = {SST=1, SD=0x010203} → 增强版eMBB切片(VIP用户,更高AMBR)
S-NSSAI = {SST=2, SD=无} → URLLC切片(工业客户专享)
S-NSSAI = {SST=3, SD=无} → mMTC切片(物联网设备)
S-NSSAI = {SST=128, SD=0xAABBCC} → 运营商自定义切片(如电力公司专网)
当UE开机附着网络时,切片选择怎么发生?
sequenceDiagram
participant UE as UE
participant AMF as AMF
participant NSSF as NSSF
participant UDM as UDM
participant SMF as SMF(切片专用)
UE->>AMF: Registration Request<br/>(Requested NSSAI: SST=2)
Note over UE: UE请求加入URLLC切片
AMF->>NSSF: NSSelection Get<br/>(Requested NSSAI)
Note over NSSF: 查询该UE被授权的切片
NSSF->>AMF: 返回Allowed NSSAI<br/>+ 目标AMF Set<br/>+ NSI ID
Note over NSSF: 返回允许的切片列表<br/>和对应的网络功能
alt 需要重定向到切片专用AMF
AMF->>UE: Registration Reject<br/>(重定向指示)
UE->>AMF: 向切片专用AMF重新注册
end
UE->>SMF: PDU Session Establishment<br/>(S-NSSAI: SST=2)
Note over SMF: SMF为URLLC切片专用实例
SMF->>UDM: 获取UE订阅的切片QoS策略
UDM->>SMF: 返回QoS Profile<br/>(默认5QI、ARP等)
SMF->>UE: PDU Session建立成功<br/>(分配QoS Flow)
很多初学者以为"有了切片就不需要QoS了"。这是一个重大误解。
正确理解:切片提供的是宏观隔离(网络级别的资源池),QoS提供的是微观调度(同一个资源池内的优先级控制)。两者是分层协作关系:
网络切片(宏观):
├── 切片A(eMBB):分配了总带宽的60%
│ ├── QoS Flow 1: 语音 (5QI=1, GBR) ← 微观调度
│ ├── QoS Flow 2: 视频 (5QI=2, GBR) ← 微观调度
│ └── QoS Flow 3: 上网 (5QI=9, Non-GBR) ← 微观调度
│
├── 切片B(URLLC):分配了总带宽的25%
│ ├── QoS Flow 1: 控制指令 (5QI=11, DC-GBR)
│ └── QoS Flow 2: 状态上报 (5QI=80, Non-GBR)
│
└── 切片C(mMTC):分配了总带宽的15%
└── QoS Flow 1: 数据上传 (5QI=84, Non-GBR)
sequenceDiagram
participant UE as UE
participant gNB as gNodeB
participant AMF as AMF
participant SMF as SMF
participant PCF as PCF
participant UPF as UPF
UE->>AMF: PDU Session Establishment Request
AMF->>SMF: Nsmf_PDUSession_CreateSMContext
SMF->>PCF: Npcf_SMPolicyControl_Create
Note over PCF: PCF根据签约信息和<br/>切片类型决定QoS策略
PCF->>SMF: 返回PCC Rules<br/>(5QI, ARP, GFBR, MFBR...)
SMF->>SMF: 根据PCC Rules生成QoS Profile
Note over SMF: 确定需要几个QoS Flow<br/>分配QFI
SMF->>UPF: N4 Session Establishment<br/>(PDR/FAR/QER规则)
Note over UPF: UPF配置包检测规则<br/>将上行/下行数据映射到QoS Flow
SMF->>AMF: Namf_Communication_N1N2MessageTransfer
Note over SMF: 包含N1 SM Container(给UE)<br/>和N2 SM Info(给gNB)
AMF->>gNB: N2 PDU Session Resource Setup Request
Note over gNB: N2 Info包含QoS Profile<br/>QFI, 5QI, ARP, GFBR...
gNB->>gNB: 接纳控制(GBR流)<br/>DRB映射<br/>无线资源预留
gNB->>UE: RRC Reconfiguration<br/>(DRB配置, QoS映射)
UE->>gNB: RRC Reconfiguration Complete
gNB->>AMF: N2 PDU Session Resource Setup Response
AMF->>SMF: 资源建立确认
Note over UE,UPF: ✅ QoS Flow建立完成<br/>数据传输开始
环节1:PCF决策
PCF(策略控制功能)是QoS的"大脑"。它根据以下信息决定QoS策略: - 用户签约数据(来自UDM) - 切片类型(S-NSSAI) - 应用需求(来自AF的应用层请求) - 运营商策略
环节2:SMF翻译
SMF把PCF的策略"翻译"成具体的技术参数: - PCC Rule → QoS Flow(分配QFI) - QoS参数下发到gNB(无线侧)和UPF(核心网侧) - 对GBR流执行双重接纳控制:无线侧检查空口资源,核心网侧检查传输资源
环节3:gNB执行
gNB收到QoS Profile后要做三件事: 1. 接纳控制:检查无线资源是否够用(特别是GBR流) 2. DRB映射:决定哪些QoS Flow映射到哪个DRB 3. 调度配置:根据5QI参数配置MAC层调度器
在现网调试中,QoS相关的关键信息在以下位置:
| 调试场景 | 查看什么 | 在哪里看 |
|---|---|---|
| 语音质量差 | 检查5QI=1的QoS Flow是否建立 | SMF日志:PDU Session建立消息 |
| 切片不通 | 检查UE的Allowed NSSAI | AMF日志:Registration Accept |
| GBR带宽不足 | 检查GFBR/MFBR配置和接纳控制结果 | gNB日志:Admission Control |
| 上行速率低 | 检查UE-AMBR和Session-AMBR | SMF/PCF日志:QoS策略 |
| 抢占异常 | 检查ARP参数配置 | PCF策略配置 |
陷阱1:AMBR配置过小
这是现网最常见的QoS问题。UE-AMBR限制了终端所有Non-GBR流量的总速率。如果UE-AMBR配置为100Mbps,即使空口能跑到1Gbps,终端也只能用到100M。
陷阱2:QoS Flow没建立,只有默认流
如果PCF策略配置错误或UDM签约数据缺失,可能导致语音业务只用默认的5QI=9(Non-GBR),而不是专用的5QI=1(GBR)。结果:通话质量差,但没有明显的错误日志。
陷阱3:切片选择失败但表现为注册失败
UE请求的切片不在运营商的Allowed NSSAI中时,AMF可能拒绝注册。但错误码可能只是笼统的"网络失败",需要到AMF日志中查看是否是NSSAI不匹配。
1. UE侧
✓ 检查PDU Session是否建立(S-NSSAI是否正确)
✓ 检查QoS Flow数量和QFI
✓ 检查IP地址分配
2. RAN侧
✓ DRB是否正确建立
✓ QoS Flow到DRB的映射关系
✓ GBR流的接纳控制结果
✓ MAC层调度统计(不同QCI的吞吐量)
3. Core侧
✓ SMF是否正确解析PCC Rules
✓ UPF的包检测规则(PDR)是否正确配置
✓ Session-AMBR限速是否生效
✓ QFI标记是否正确
4. 策略侧
✓ PCF是否正确下发策略
✓ UDM签约数据中QoS参数是否完整
✓ ARP配置是否符合业务需求
| 维度 | 4G LTE | 5G NR |
|---|---|---|
| QoS粒度 | EPS Bearer | QoS Flow |
| 标识 | QCI(4-255) | 5QI(1-255) |
| 会话模型 | PDN Connection | PDU Session |
| 资源类型 | GBR / Non-GBR | GBR / Non-GBR / Delay-Critical GBR |
| 反射QoS | 不支持 | 支持 |
| 网络切片 | 不支持(用APN区分) | 支持(S-NSSAI) |
| 策略控制 | PCRF → PCEF(PGW) | PCF → SMF → UPF(gNB) |
| 空口映射 | Bearer 1:1 → DRB | 多个QoS Flow → 1个DRB |
| 延迟最低 | QCI=1, 100ms | 5QI=14, 3ms |
| 新特性 | — | 反射QoS、Delay-Critical GBR、MDBV |
5G QoS和网络切片的设计哲学可以用一句话概括:精细化分级、分层次治理、灵活化配置。
这三者不是替代关系,而是分层协作:
第一层:网络切片 → 宏观资源隔离(谁分到多少资源池)
第二层:ARP → 资源竞争仲裁(拥塞时谁让路)
第三层:5QI → 数据包级转发质量(延迟、丢包率保障)
对于1-3年经验的工程师,理解这套分层机制的核心价值在于:当你在现网遇到QoS问题时,知道该在哪一层排查——是切片配置问题、ARP抢占问题,还是5QI参数配置问题。
Q1: 5QI和QCI可以一一对应吗?
A: 大部分常用值可以对应(如5QI=1对应QCI=1都是语音),但5G新增了很多4G没有的5QI值(如Delay-Critical GBR类型的10~22)。从4G向5G演进时,基本业务可以1:1映射,但URLLC类业务需要使用5G独有的5QI。
Q2: 一个PDU Session里最多能有多少个QoS Flow?
A: 标准没有严格限制QoS Flow数量,QFI在PDU Session范围内唯一标识(取值0~63)。但在实际部署中,受限于gNB的DRB数量(最大8个DRB)和调度复杂度,通常一个PDU Session内的QoS Flow不超过10个。
Q3: 网络切片和VPN有什么区别?
A: VPN是在传输层建立的安全隧道,只是"加密通道"。网络切片是从无线接入、传输网到核心网的端到端隔离,包含独立的网络功能实例、独立的资源配额、独立的管理面。VPN是"逻辑隔离",切片是"架构级隔离"。
Q4: GBR流的接纳控制失败怎么办?
A: 接纳控制失败时,SMF会拒绝该QoS Flow的建立,并通过PCF触发策略降级(如尝试Non-GBR的替代方案),或者通过ARP抢占低优先级流的资源。如果都失败,则向应用层返回建立失败。这就是为什么语音通话在网络极拥堵时可能无法拨出。
Q5: 反射QoS有什么风险?
A: 反射QoS依赖UE正确"学习"下行QFI标记。如果下行数据包被篡改或QFI标记错误,UE可能将上行数据映射到错误的QoS Flow。因此反射QoS通常只用于Non-GBR流量,GBR流量仍使用显式QoS规则信令。
本文由「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 等场景全覆盖。
