# 5G URLLC 端到端 QoS 监控机制拆解：把 UPF 和 NG-RAN 变成"分布式时延探针" ## 一、问题起点：URLLC 切片 QoS 保障的"盲区" 在 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 章节中的定义与信令实现。 --- ## 二、核心概念：QoS Monitoring Parameter 与三类测量点 ### 2.1 QoS Monitoring Parameter（QMP） 在 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 | ### 2.2 三类测量点（Measurement Points） 这是整个机制最精巧的设计。TS 23.501 §5.33.3 把端到端链路 **拆成两段** 分别测量，再在 SMF 处**合成**： - **Uu 段**：UE ↔ NG-RAN 的无线段时延，由 **NG-RAN 自主测量**（利用 MAC/RLC 层的收发时刻，TS 38.314 定义了相关 Layer 2 测量量）。 - **N3 段**：NG-RAN ↔ UPF 的传输段时延，由 **NG-RAN 与 UPF 协同测量**（借助 GTP-U 扩展头中的时间戳，要求两端时钟同步）。 - **端到端**：UE ↔ UPF，由 SMF 把上述两段相加得到，分上行（UL）和下行（DL）。 **表 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）： ```mermaid sequenceDiagram participant PCF participant SMF participant UPF participant NGRAN as NG-RAN participant UE Note over PCF,UE: 阶段1：策略下发与配置 PCF->>SMF: Npcf_SMPolicyControl
(含 QoS Monitoring Parameter) SMF->>UPF: N4 PFCP Session Est/Mod
(QoS Monitoring Control + 报告触发) SMF->>NGRAN: N2 PDU Session Est/Mod
(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
(Uu DL, Uu UL, N3 DL) UPF-->>SMF: N4 QoS Monitoring Report
(N3 UL) Note over SMF: 合成 E2E:
DL_E2E = N3_DL + Uu_DL
UL_E2E = Uu_UL + N3_UL SMF-->>PCF: Npcf_SMPolicyControl Notify
(超阈值/周期结果) PCF-->>PCF: 经 NEF 通知 AF / 触发 QoS 调整 ``` ### 3.1 关键 IE 逐条解析 **① 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 段测量的物理载体。 ### 3.2 端到端时延的"拼图" 把测量点画成图，端到端时延的拼装关系一目了然： ```mermaid graph TD subgraph 端到端时延测量拓扑 UE(("UE")) RAN(("NG-RAN")) UPF(("UPF")) UE <-. "Uu UL 时延
RAN测量" .-> RAN RAN <-. "N3 UL 时延
RAN打戳/UPF算" .-> UPF UPF <-. "N3 DL 时延
UPF打戳/RAN算" .-> RAN RAN <-. "Uu DL 时延
RAN测量" .-> UE end UPF -.N4上报N3UL.-> SMF1(("SMF")) RAN -.N2上报UuDL/UuUL/N3DL.-> SMF1 SMF1 --> R["E2E_DL = N3_DL + Uu_DL
E2E_UL = Uu_UL + N3_UL"] ``` SMF 是这套机制的"合成中枢"——它不直接测量任何时延，但掌握 N2 与 N4 两个上报源的全部数据，因此能算出唯一可信的端到端结果。 --- ## 四、报告触发：周期、事件与"两级门限" QoS Monitoring 的上报不是无脑全量上报，而是受 `Reporting Frequency` 控制。Rel-16 起初只支持**事件触发**，Rel-17 扩展了**周期性**上报与二者组合。其判定逻辑可抽象为下面的状态流： ```mermaid 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 违约
经 NEF 通知 AF] J -->|否| L[记录, 维持当前 QoS Flow 配置] K --> M[PCF 可下发动态 PDB 重划分] ``` 设计意图很明确：**事件触发**用于"出事了立刻喊"的低频高敏感性场景（省信令），**周期触发**用于"持续体检、趋势分析"的常态监控（支撑 SLA 日报与 AI 预测）。两级门限（`Reporting Threshold` 是上报门限、`Maximum Requested Packet Delay` 是 SLA 红线）把"要不要上报"和"要不要告警/调整"解耦，避免信令风暴。 --- ## 五、设计意图与 Rel-17/18 演进 **表 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 工业控制 | 为什么这样设计？三点深层动因： 1. **打破"接入网背锅"的 QoS 模型**。传统 PDB 是个"黑盒预算"，RAN 要保证整个 PDB，但它无法控制核心网传输段。QoS Monitoring 让时延**可归因**——是 Uu 段（无线问题，调调度参数）还是 N3 段（传输问题，换路由/换 UPF），一目了然，运维能精确定位根因。 2. **支撑"动态 PDB 划分（Dynamic PDB Partitioning）"**。Rel-17 引入后，SMF/PCF 可以根据实测的 N3 段时延，**动态地**把总 PDB 在 Uu 与 N3 之间重新分配。例如某次 N3 实测只占 2ms，剩余预算可放松给 Uu（提升覆盖边缘用户的可靠性），反之则收紧。这是闭环 QoS 的精髓，arXiv 综述（2508.20205）把它列为 URLLC 走向 6G 的关键技术之一。 3. **为网络切片 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 从"被动保障"推向"主动自适应"的关键一步。 --- ## 参考来源 1. [3GPP TS 23.501 V18.x — §5.33 Support for URLLC, §5.7.4 QoS parameters, QoS Monitoring Parameter 定义](https://www.3gpp.org/dynareport?spec=23501.htm) — QoS 监控的架构与参数定义源头 2. [3GPP TS 23.502 V18.x — §4.4.7 QoS monitoring procedure](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3145) — QoS 监控信令流程规范 3. [ShareTechnNote — 5G URLLC 可靠性与低时延机制](https://www.sharetechnote.com/html/5G/5G_URLLC.html) — URLLC 时延来源与可靠性增强（PDCP duplication 等）解读 4. [ETSI TS 138 314 V18.0.0 — NR Layer 2 measurements](https://www.etsi.org/deliver/etsi_ts/138300_138399/138314/18.00.00_60/ts_138314v180000p.pdf) — RAN 侧包时延测量量定义 5. [arXiv:2508.20205 — A Comprehensive Survey of 5G URLLC and Challenges in the 6G Era](https://arxiv.org/html/2508.20205v1) — URLLC 动态 PDB 划分与 QoS 监控的学术综述 6. [3GPP 官方 — Ultra Reliable and Low Latency Communications](https://www.3gpp.org/technologies/urlcc-2022) — URLLC 冗余传输路径（双 N3/N9 隧道）与 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 等场景全覆盖。