在 5G 的 QoS 模型里，有一条延续自 LTE 的隐含假设：核心网（N3/N9）段的传输时延可以忽略，QoS 保障的重心在接入网。规范用一个叫 PDB（Packet Delay Budget，包时延预算） 的参数来约束 5QI 的端到端时延，但对 GBR 承载，这个 PDB 在工程实现上几乎全部"压"给了 NG-RAN 去保证（通过调度、HARQ、复制传输等）。运营商真正能观测到的，往往只有 RAN 侧上报的无线 KPI，而 UE 到 UPF 之间那条端到端链路的真实时延，长期处于"不可测、不可控"的状态。
这对 eMBB 业务无所谓——丢一两个包、抖动几十毫秒用户无感。但对 URLLC 切片（工业自动化、远程控制、车联网、远程手术）而言，这就是致命的：URLLC 承诺的是 1ms~10ms 量级的端到端时延和 1E-5~1E-6 的可靠性，SLA 写得清清楚楚，网络却无法在用户面实时回答"这条流的端到端时延现在到底是多少毫秒"。一旦某个传输节点拥塞、某段光纤绕路、某个 UPF 重选导致时延劣化，AF（应用功能）和运营商根本无从及时感知，更谈不上动态补偿。
QoS Monitoring（QoS 监控） 机制就是为填补这个盲区而设计的。它在 Rel-16 作为 URLLC 的基础能力被引入（TS 23.501 §5.33、TS 23.502 §4.4.7），在 Rel-17 进一步增强（新增周期性上报、与 TSC 时间同步深度耦合、支持动态 PDB 划分），到 Rel-18/Rel-19 已成为网络切片 SLA 可观测性、URLLC 链路质量保障的"标配探针"。本文聚焦这一机制在具体 TS 章节中的定义与信令实现。
在 TS 23.501 §5.7.4 中，QoS Monitoring 被定义为一个 可选的 QoS 参数，挂在 QoS Flow 的 QoS Profile 上。当 PCF 决定对某个 QoS Flow（通常是 URLLC 的 GBR Flow，对应 5QI 82/83/84/85/86 等）启用监控时，会下发一组 QoS Monitoring Parameter（QMP），关键 IE 如下表。
表 1：QoS Monitoring Parameter（QMP）关键 IE 说明
| IE 名称 | 规范来源 | 作用 | 典型取值 |
|---|---|---|---|
| QoS Monitoring 启用指示 | TS 23.501 §5.7.4 | 标记该 QoS Flow 是否启用监控 | Boolean |
| Reporting Frequency | TS 23.501 §5.33.3 | 上报模式：事件触发 / 周期性 / 事件+周期 | Event / Periodic |
| Reporting Periodicity | TS 23.501 §5.33.3 | 周期上报间隔 | 100ms~10s |
| Packet Delay Reporting Threshold | TS 23.501 §5.33.3 | 事件触发的时延门限，超过即报 | 例如 10ms |
| Minimum Requested Packet Delay | TS 23.501 §5.33.3 | 期望下限，用于 SLA 红线 | 例如 1ms |
| Maximum Requested Packet Delay | TS 23.501 §5.33.3 | 期望上限，超限触发告警/QoS 调整 | 例如 10ms |
| QFI（被监控的 QoS Flow） | TS 29.244 / TS 38.413 | 标识具体监控对象 | 1~63 |
这是整个机制最精巧的设计。TS 23.501 §5.33.3 把端到端链路 拆成两段 分别测量，再在 SMF 处合成：
表 2：三类测量点的责任分工
| 测量点 | 测量方 | 测量手段 | 上报给谁 |
|---|---|---|---|
| Uu DL（RAN→UE） | NG-RAN | RLC/MAC 层收发时刻差 | SMF（N2） |
| Uu UL（UE→RAN） | NG-RAN | RLC/MAC 层收发时刻差 | SMF（N2） |
| N3 DL（UPF→RAN） | NG-RAN | UPF 在 GTP-U 打时间戳，RAN 收到后算差 | SMF（N2） |
| N3 UL（RAN→UPF） | UPF | RAN 在 GTP-U 打时间戳，UPF 收到后算差 | SMF（N4） |
注意这个"对称打戳"的分工：下行方向 UPF 打戳、RAN 算；上行方向 RAN 打戳、UPF 算。谁接收谁计算，这样每个测量方都用本地时钟读"接收时刻"，避免时钟漂移影响（前提是 RAN 与 UPF 之间有 PTP/1588 或 802.1AS 时间同步，这也是 QoS Monitoring 常与 TSC 时间敏感通信打包部署的根本原因）。
下面是 QoS Monitoring 的完整生命周期信令流（基于 TS 23.502 §4.4.7 与 TS 29.244 N4 / TS 38.413 N2）：
sequenceDiagram
participant PCF
participant SMF
participant UPF
participant NGRAN as NG-RAN
participant UE
Note over PCF,UE: 阶段1：策略下发与配置
PCF->>SMF: Npcf_SMPolicyControl<br/>(含 QoS Monitoring Parameter)
SMF->>UPF: N4 PFCP Session Est/Mod<br/>(QoS Monitoring Control + 报告触发)
SMF->>NGRAN: N2 PDU Session Est/Mod<br/>(QFI + QoS Monitoring Config IE)
Note over UPF,NGRAN: 用户面建立，启用包时延测量
Note over UE,UPF: 阶段2：下行(DL)测量
UPF->>NGRAN: DL GTP-U (插入时间戳 T1)
Note over NGRAN: 测量 N3 DL = (Rx - T1)
NGRAN->>UE: Uu DL
Note over NGRAN: 测量 Uu DL
Note over UE,UPF: 阶段3：上行(UL)测量
UE->>NGRAN: Uu UL
Note over NGRAN: 测量 Uu UL
NGRAN->>UPF: UL GTP-U (插入时间戳 T2)
Note over UPF: 测量 N3 UL = (Rx - T2)
Note over PCF,UPF: 阶段4：上报与合成
NGRAN-->>SMF: N2 QoS Monitoring Report<br/>(Uu DL, Uu UL, N3 DL)
UPF-->>SMF: N4 QoS Monitoring Report<br/>(N3 UL)
Note over SMF: 合成 E2E:<br/>DL_E2E = N3_DL + Uu_DL<br/>UL_E2E = Uu_UL + N3_UL
SMF-->>PCF: Npcf_SMPolicyControl Notify<br/>(超阈值/周期结果)
PCF-->>PCF: 经 NEF 通知 AF / 触发 QoS 调整
① N4 侧（TS 29.244，PFCP）：SMF 通过 PFCP Session Establishment/Modification Request 携带：
- QoS Monitoring Control Information（新建 IE）：包含 Reporting Frequency、Reporting Threshold、Reporting Periodicity，绑定到具体 QFI 的 PDR/QER。
- QoS Report Trigger：置位"Report upon packet delay measurement"，UPF 据此在上行 N3 测量完成后主动回 PFCP Session Report Request。
② N2 侧（TS 38.413，NGAP）：SMF 经 AMF 在 PDU Session Resource Setup/Modify Request 的 QoS Flow Level QoS Parameters 中携带：
- QoS Monitoring Parameter IE：包含 req. QoS Monitoring Packet Delay Reports（要求 RAN 上报 Uu/N3 时延）、reporting Periodicity、Packet Delay Reporting Threshold。
- NG-RAN 据此在 PDU Session Resource Modify Response 或独立的 PDU Session Resource Notify 中回 QoS Monitoring Report（含 DL/UL Uu 与 DL N3 时延值）。
③ GTP-U 时间戳（TS 29.281 扩展）：UPF/RAN 在 GTP-U 扩展头中插入 Timestamp。下行由 UPF 在出口打 T1，上行由 RAN 在出口打 T2。这是 N3 段测量的物理载体。
把测量点画成图，端到端时延的拼装关系一目了然：
graph TD
subgraph 端到端时延测量拓扑
UE(("UE"))
RAN(("NG-RAN"))
UPF(("UPF"))
UE <-. "Uu UL 时延<br/>RAN测量" .-> RAN
RAN <-. "N3 UL 时延<br/>RAN打戳/UPF算" .-> UPF
UPF <-. "N3 DL 时延<br/>UPF打戳/RAN算" .-> RAN
RAN <-. "Uu DL 时延<br/>RAN测量" .-> UE
end
UPF -.N4上报N3UL.-> SMF1(("SMF"))
RAN -.N2上报UuDL/UuUL/N3DL.-> SMF1
SMF1 --> R["E2E_DL = N3_DL + Uu_DL<br/>E2E_UL = Uu_UL + N3_UL"]
SMF 是这套机制的"合成中枢"——它不直接测量任何时延，但掌握 N2 与 N4 两个上报源的全部数据，因此能算出唯一可信的端到端结果。
QoS Monitoring 的上报不是无脑全量上报，而是受 Reporting Frequency 控制。Rel-16 起初只支持事件触发，Rel-17 扩展了周期性上报与二者组合。其判定逻辑可抽象为下面的状态流：
flowchart TD
A[QoS Monitoring 启动] --> B{Reporting Frequency 模式}
B -->|Periodic 周期| C[每 T 周期上报一次]
B -->|Event 事件| D[持续测量包时延]
B -->|Event + Periodic| E[双轨并行]
D --> F{测量值 超过 报告阈值?}
F -->|是| G[立即上报 + 开启后续窗口]
F -->|否| D
E --> H[周期到 AND/超阈值 触发]
C --> I[SMF 合成 E2E 时延]
G --> I
H --> I
I --> J{E2E 超过 Max Requested Delay?}
J -->|是| K[告警: 触发 QoS 升级/SLA 违约<br/>经 NEF 通知 AF]
J -->|否| L[记录, 维持当前 QoS Flow 配置]
K --> M[PCF 可下发动态 PDB 重划分]
设计意图很明确：事件触发用于"出事了立刻喊"的低频高敏感性场景（省信令），周期触发用于"持续体检、趋势分析"的常态监控（支撑 SLA 日报与 AI 预测）。两级门限（Reporting Threshold 是上报门限、Maximum Requested Packet Delay 是 SLA 红线）把"要不要上报"和"要不要告警/调整"解耦，避免信令风暴。
表 3：QoS Monitoring 与传统 QoS 保障机制对比
| 维度 | 传统 5QI/PDB 保障 | QoS Monitoring |
|---|---|---|
| 可观测性 | 仅 RAN 无线 KPI，端到端不可见 | UE↔UPF 端到端实时可测 |
| 时延控制重心 | 全压在 NG-RAN | 可按 N3/Uu 段拆分，动态划分 PDB |
| 反馈机制 | 开环（配置即固定） | 闭环（测量→上报→PCF 调整） |
| 时钟同步要求 | 无 | RAN 与 UPF 需 PTP/802.1AS |
| 信令开销 | 无额外开销 | N2/N4 周期或事件上报开销 |
| 典型应用 | eMBB | URLLC 切片 SLA、TSC 工业控制 |
为什么这样设计？三点深层动因：
打破"接入网背锅"的 QoS 模型。传统 PDB 是个"黑盒预算"，RAN 要保证整个 PDB，但它无法控制核心网传输段。QoS Monitoring 让时延可归因——是 Uu 段（无线问题，调调度参数）还是 N3 段（传输问题，换路由/换 UPF），一目了然，运维能精确定位根因。
支撑"动态 PDB 划分（Dynamic PDB Partitioning）"。Rel-17 引入后，SMF/PCF 可以根据实测的 N3 段时延，动态地把总 PDB 在 Uu 与 N3 之间重新分配。例如某次 N3 实测只占 2ms，剩余预算可放松给 Uu（提升覆盖边缘用户的可靠性），反之则收紧。这是闭环 QoS 的精髓，arXiv 综述（2508.20205）把它列为 URLLC 走向 6G 的关键技术之一。
为网络切片 SLA 提供"硬证据"。切片租户（垂直行业）签 SLA 要的是"可验证、可追溯"的时延承诺。QoS Monitoring 的周期上报数据直接进 TS 28.552 定义的性能测量体系，经 NWDAF/MnF 汇总成 SLA 报告。没有它，切片就是"卖了不负责"。
Rel-18/19 的增强方向：把 QoS Monitoring 数据喂给 NWDAF（网络数据分析功能）做时延预测与异常检测；与 Multi-Connectivity/冗余传输联动，当某条路径时延劣化时自动切换主备路径；在 NTN（非地面网络）场景下补偿卫星传播时延的长 RTT 特性。
Q1：QoS Monitoring 和传统的 5G QoS（5QI/PDB）保障是什么关系？ A：传统 5QI/PDB 是"事前承诺 + 事后统计"的开环模型，PDB 几乎全压在 RAN。QoS Monitoring 是"实时测量 + 闭环反馈"的补充层，把端到端时延切成 Uu/N3 两段可测、可归因、可动态调整，专门服务于 URLLC/TSC 切片这类对 SLA 敏感的业务。可以理解为：5QI 管"该不该保证"，QoS Monitoring 管"实际保证了没有"。
Q2：为什么 N3 段下行由 RAN 算、上行由 UPF 算，而不是统一由一方算？ A：因为时延测量需要"发送时刻"和"接收时刻"。为了消除两端时钟偏差的影响，标准让接收方用本地时钟读接收时刻，发送方只负责打时间戳。所以下行 UPF 发（打戳）→ RAN 收（计算）；上行 RAN 发（打戳）→ UPF 收（计算）。这种"谁接收谁算"的对称设计，使测量误差只取决于时钟同步精度，而不积累。
Q3：QoS Monitoring 必须依赖时钟同步吗？没有 PTP 能不能用？ A：严格来说，N3 段的 GTP-U 时间戳测量强依赖 RAN 与 UPF 之间的时间同步（PTP/IEEE 1588/802.1AS）。没有同步，打的时间戳对不齐，算出的时延无意义甚至为负。Uu 段不需要跨节点同步（RAN 内部 MAC/RLC 自洽），所以即使没部署 PTP，Uu 段仍可监控，但端到端合成不可用。这也是 QoS Monitoring 常与 TSC 时间敏感通信打包部署的原因。
Q4：QoS Monitoring 会带来多少信令开销？怎么控制？ A：开销主要在 N2/N4 的上报消息。周期模式下，假设每个被监控 QoS Flow 每 500ms 上报一次，每条报文几百字节，对单个 PDU Session 影响有限，但在大规模 URLLC 部署下会累积。控制手段：优先用事件触发模式（Rel-16 默认），只在超阈值时上报；合理设置 Reporting Threshold 避免抖动导致的频繁触发；对 eMBB 切片不启用，仅对 URLLC/TSC 切片启用。
Q5：Rel-17 的"周期性上报"相比 Rel-16 的"事件触发"解决了什么问题？ A：事件触发只能告诉你"超限了"，但无法回答"平时是多少、趋势如何"，对 SLA 报表和预测性维护是盲的。周期上报提供连续的时延时间序列，支撑 NWDAF 做时延预测、异常检测、以及动态 PDB 在 Uu/N3 间的实时重划分——这是把 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 等场景全覆盖。