<!-- title: 5G替代QoS档位通知控制拆解 -->
<!-- domain: slicing-mec -->

# 5G替代QoS档位与QoS通知控制机制全链拆解：URLLC切片如何实现"可感知、可降级、可恢复"的QoS闭环

## 一、为什么URLLC切片需要一套"降级通知"机制

在URLLC（超可靠低时延通信）切片里，运营商和行业客户对一条GBR（保证比特速率）QoS流往往提出**苛刻的硬指标**：例如工业遥测要求上行 GFBR=50 Mbps、分组时延预算 PDB=1 ms、误包率 PER=1e-5。这类指标写在SLA里，就是一份"承诺书"。

但无线信道是动态的——UE移到小区边缘、出现突发干扰、调度资源被抢占，NG-RAN在某一瞬间**物理上就无法兑现1 ms的PDB**。传统eMBB的做法是"尽力而为"：尽力调度，兑现不了就丢包，应用层自己感知卡顿。但URLLC切片（如远程手术、柔性制造）容不得这种"闷头掉线"，它要的是两件事：

1. **应用层必须第一时间知道**"当前网络到底还能保证到哪一档"，以便主动降速、切换备份链路或人工接管，而不是等业务已经崩了才发现；
2. **当无线条件恢复时，网络要能自动"回升"**到最高档，应用层也随之回到最优编码。

3GPP正是用三件套把这个"开环承诺"变成"闭环保障"：

- **替代QoS档位（Alternative QoS Profile，TS 23.501 5.7.1.2a）**——一条QoS流配多个"档位"，从严格到宽松；
- **QoS通知控制（Notification Control，TS 23.501 5.7.2.4）**——RAN把"当前能保证哪一档"沿 NGAP→SMF→PCF→AF 这条控制面链路实时上报；
- **QoS监控（QoS Monitoring，TS 23.501 5.33.3.3）**——RAN和UPF双侧测量真实时延，作为"档位切换"和"通知"的事实依据。

三者关系：QoS Monitoring是**传感器**，Notification Control是**反馈通道**，Alternative QoS Profile是**档位刻度**。本文聚焦这套控制面闭环。

## 二、整体闭环架构

```mermaid
flowchart TD
    AF["AF (应用服务器)\n订阅档位事件"] -->|PCC/事件订阅| PCF["PCF\n策略决策"]
    PCF -->|PCC Rule\n含Alt QoS Profile列表| SMF
    SMF -->|N4| UPF["UPF\nN3/N9时延测量\n(性能探针)"]
    SMF -->|N2 NGAP:\nQoS Profile+\nNotification Control+\nAlt QoS Set List| AMF
    AMF -->|N2 转发| RAN["NG-RAN/gNB\nUu时延测量\n档位裁决"]
    RAN -->|PDU SESSION RESOURCE NOTIFY\n当前可保证档位| AMF2["AMF"]
    AMF2 -->|Nsmf PDUSession UpdateSMContext| SMF
    SMF -->|Npcf SMPolicyControl Notify\nAlt QoS Profile Index| PCF
    PCF -->|Npcf PolicyAuthorization Notify\n当前保证档位| AF
    RAN -.测量.-> UE["UE (工业终端)"]
    UPF -.N3时延.-> RAN
    style RAN fill:#ffe0e0
    style AF fill:#e0ffe0
    style PCF fill:#fff7cc
```

## 三、机制一：替代QoS档位（Alternative QoS Profile）

### 3.1 概念与设计意图

TS 23.501 5.7.1.2a 定义：一条GBR QoS Flow除了**参考QoS Profile（reference profile）**外，可**可选地**携带一个或多个Alternative QoS Profile。每个档位用一组完整的5G QoS参数刻画，从最严格递进到最宽松。设计意图很明确——**把"二元的保/不保"细化为"多档分级"**，给应用层一个"梯子"而非"悬崖"。

以一条工业机器人的上行控制流为例：

| 档位 | 索引 | 5QI | 上行GFBR | 下行GFBR | PDB | PER | 业务可接受性 |
|------|------|-----|----------|----------|-----|-----|--------------|
| 参考档 | （无索引） | 84 | 10 Mbps | 10 Mbps | 1 ms | 1e-5 | 全速精细控制 |
| 替代档1 | 1 | 84 | 10 Mbps | 10 Mbps | 5 ms | 1e-4 | 控制周期拉长，仍可用 |
| 替代档2 | 2 | 84 | 5 Mbps | 5 Mbps | 10 ms | 1e-3 | 降速运行，需人工辅助 |
| 兜底 | —— | —— | —— | —— | —— | —— | 无法保证，需告警/接管 |

> 注：Rel-16/17规范文本中称"Alternative QoS Parameter Set"，到Rel-19/20统称为"Alternative QoS Profile"；NGAP（TS 38.413）层面IE仍叫 `Alternative QoS Parameter Set List`，本文两词混用，指同一概念。

### 3.2 档位的承载结构

档位信息随QoS Flow Profile下发到RAN，IE层级如下：

```mermaid
flowchart TD
    QFP["QoS Flow Level QoS Parameters (NGAP)"] --> QFI["QoS Flow Identifier (QFI)"]
    QFP --> FIVEQI["5QI"]
    QFP --> GFBR["GFBR UL/DL"]
    QFP --> MFBR["MFBR UL/DL"]
    QFP --> NC["Notification Control\n(notification requested)"]
    QFP --> ALT["Alternative QoS Parameter Set List"]
    ALT --> A1["Alt Set 1 (index=1)\n5QI/GFBR/MFBR/PDB/PER/ARP"]
    ALT --> A2["Alt Set 2 (index=2)\n...更宽松..."]
    ALT --> AN["Alt Set N (index=N)"]
    style ALT fill:#fff7cc
    style NC fill:#ffe0e0
```

关键点：**Notification Control指示位**必须设为"requested"，RAN才会在档位切换时上报；若仅配了Alt QoS Profile但没开QNC，RAN内部自行切换档位却不会通知核心网——这是常见配错点（见第六节）。

## 四、机制二：QoS通知控制（Notification Control）——核心信令流

这是整套闭环的"主轴"。下面这条时序图刻画了**从配档、下行下发、无线劣化上报、到AF收到档位变更**的完整链路（参考 TS 23.502 4.3.2.2 PDU会话建立与 TS 23.501 5.7.2.4）。

```mermaid
sequenceDiagram
    participant AF as AF
    participant PCF as PCF
    participant SMF as SMF
    participant AMF as AMF
    participant RAN as NG-RAN
    participant UE as UE

    Note over AF,PCF: ① 策略与档位下发
    AF->>PCF: Npcf_PolicyAuthorization_Create\n(业务QoS需求 + Alt QoS期望)
    PCF->>SMF: Npcf_SMPolicyControl_Update\n(PCC Rule: QNC=requested, Alt QoS Profile列表)
    SMF->>AMF: N1N2MessageTransfer\n(N2 SM: PDU Session Resource Setup)
    AMF->>RAN: NGAP PDU SESSION RESOURCE SETUP REQUEST\n(含QoS Flow Profile + QNC + Alt Set List)

    Note over RAN: ② RAN准入裁决
    RAN->>UE: RRC Reconfiguration (建立DRB, 映射QoS Flow)
    RAN-->>SMF: PDU SESSION RESOURCE SETUP RESPONSE\n(初始可保证参考档)

    Note over RAN,AF: ③ 无线劣化：降档通知
    RAN->>RAN: 调度判定: GFBR参考档无法满足,\n但Alt档1可保证
    RAN->>AMF: NGAP PDU SESSION RESOURCE NOTIFY\n(QoS Flow Notify: not fulfilled,\nAlternative QoS Parameter Set Index=1)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext\n(N2 Sm Info转发Notify)
    SMF->>PCF: Npcf_SMPolicyControl_UpdateNotify\n(QoS通知 + 当前保证档=1)
    PCF->>AF: Npcf_PolicyAuthorization_Notify\n(当前可保证: Alt档1 → 应用降速/切码)

    Note over RAN,AF: ④ 无线恢复：升档通知
    RAN->>AMF: NGAP PDU SESSION RESOURCE NOTIFY\n(fulfilled, 参考档恢复)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
    SMF->>PCF: Npcf_SMPolicyControl_UpdateNotify
    PCF->>AF: Npcf_PolicyAuthorization_Notify\n(回到参考档 → 应用升速)
```

### 4.1 关键IE逐条解析

**（1）下行：QoS Flow Setup Request List（TS 38.413）**

| IE | 含义 | 典型取值 |
|----|------|----------|
| QoS Flow Identifier | 流标识 | 1~63（与5QI解耦） |
| 5QI | 标准化/预配置QoS标识 | 84/85（URLLC GBR） |
| GFBR UL/DL | 保证比特速率 | 50 Mbps |
| MFBR UL/DL | 最大比特速率 | 100 Mbps |
| Notification Control | 是否请求通知 | "requested" |
| Alternative QoS Parameter Set List | 替代档集合 | [{index=1,...},{index=2,...}] |

**（2）上行：PDU SESSION RESOURCE NOTIFY 中的 QoS Flow Notify Item**

这条消息是RAN主动发给AMF的（TS 38.413），其Transfer容器里最关键的就是 QoS Flow Notify List：

```mermaid
flowchart TD
    MSG["NGAP: PDU SESSION RESOURCE NOTIFY\n(RAN→AMF)"] --> LST["PDUSessionResourceNotifyList"]
    LST --> ITEM["PDU Session Resource Notify Transfer"]
    ITEM --> QL["QoS Flow Notify List"]
    QL --> NF["QoS Flow Notify Item"]
    NF --> QFI["QoS Flow Identifier"]
    NF --> NT["Notification Type\n(fulfilled / not fulfilled)"]
    NF --> AI["Alternative QoS Parameter Set Index\n(1..N, 可选)"]
    ITEM --> FAIL["QoS Flow Failed to Setup/Modify List\n(可选)"]
    style NF fill:#ffe0e0
    style AI fill:#fff7cc
```

**Notification Type 与 Alt Index 的组合语义**是这套机制的"语义核心"，务必记住这张解码表：

| Notification Type | Alt QoS Parameter Set Index | 业务含义 | 应用层动作 |
|-------------------|------------------------------|----------|------------|
| fulfilled | 无（或=0） | **参考档**GFBR已能保证 | 升回最优编码/全速 |
| not fulfilled | = N (≥1) | 参考档不可保，但**第N档**可保 | 切到第N档对应策略 |
| not fulfilled | 无 | 所有档均无法保证 | 告警/接管/降级到尽力而为 |

> 这正是与"无替代档"模式（TS 23.501 5.7.2.4.1a）的本质区别：无Alt档时RAN只能报二元状态（fulfilled/not fulfilled），应用层不知道"劣化到什么程度"；有Alt档时（5.7.2.4.1b）应用层拿到**精确的档位索引**，可差异化适配。

### 4.2 切换场景的连续性（TS 23.501 5.7.2.4.2）

UE在Xn/N2切换时，源gNB会把"当前已保证的档位"作为上下文传给目标gNB（在Handover Preparation/HO Request的QoS Flow上下文里携带当前Applicable QoS Profile）。目标gNB据此**优先尝试维持同档或更高档**，避免切换瞬间"跳崖"。若目标侧资源更差，目标gNB会在切换完成后立即发NOTIFY上报更低档位。

## 五、机制三：QoS监控——档位裁决的"事实依据"

Notification Control是"结果上报"，但RAN凭什么判定"参考档保不住、第1档保得住"？依据来自两层测量：

```mermaid
sequenceDiagram
    participant UE as UE
    participant RAN as NG-RAN (gNB)
    participant UPF as UPF
    participant SMF as SMF

    Note over UE,RAN: Uu段时延（RAN测量）
    UE->>RAN: 数据包(携带/可推算发送时间戳)
    RAN->>RAN: 测量 UE↔gNB(Uu) 单向/往返时延

    Note over RAN,UPF: N3段时延（RAN+UPF协同）
    RAN->>UPF: GTP-U(打gNB发送时间戳)
    UPF->>UPF: 计算 N3上行时延 = UPF接收 - gNB发送
    UPF->>RAN: GTP-U(打UPF发送时间戳, 下行)
    RAN->>RAN: 计算 N3下行时延 = gNB接收 - UPF发送

    Note over UPF,SMF: UPF经N4 Session Report上报(SRR配置)
    UPF->>SMF: N4 Session Report\n(N3/N6时延测量结果, 周期/事件触发)

    Note over RAN,SMF: RAN经NGAP上报
    RAN->>SMF: (经AMF) NGAP QoS监控结果\n(Uu + N3上行时延)
    SMF->>SMF: 汇总RAN+UPF测量 → 推导端到端时延分布\n→ 喂给PCF/NWDAF做策略/分析
```

要点说明：

- **三段测量**：UE↔gNB（Uu）、gNB↔UPF（N3）、UPF↔DN（N6/N9）。RAN负责Uu段（可用MAC/RLC时间戳或专用测量）；N3段依赖gNB与UPF在GTP-U包上打**时间戳**，UPF据此算单向时延。往返时延可由两端时间戳闭环推导，规避严格时钟同步要求（TS 23.501 5.33.3.3）。
- **UPF侧由SRR驱动**：SMF通过N4下发的**Session Reporting Rule（SRR）**配置UPF测量周期、上报频率（周期性/事件触发）、门限和最短等待时间；UPF既可经N4 Session Report回送SMF，也可在SMF授权下**直送**NWDAF/DCCF/AF（Nupf_EventExposure）。
- **RAN侧NGAP上报**：RAN按配置周期性或超门限事件性地上报QoS监控结果，SMF汇总两侧测量得到端到端时延画像，既支撑"档位裁决"，也驱动PCF动态调档、NWDAF做体验分析。
- **与Notification Control的分工**：QoS Monitoring产出"客观测量数据"，Notification Control产出"档位变更通知"，前者是后者的输入之一；二者可独立开关，但URLLC切片通常同时开启以形成完整闭环。

## 六、抓包识别与故障排查

### 6.1 抓包怎么认这个流程

在N2（NGAP）抓包里按以下特征识别：

1. **下发阶段**：在 `PDU SESSION RESOURCE SETUP REQUEST` 的 PDU Session Resource Setup Request Transfer → QoS Flow Setup Request List 中，看到某QoS Flow同时含 `Notification Control`（值=通知请求）与 `Alternative QoS Parameter Set List`，即说明该流启用了本机制。
2. **上报阶段**：出现 `PDU SESSION RESOURCE NOTIFY`（procedureCode = id-PDUSessionResourceNotify），其Notify Transfer内含 QoS Flow Notify List，重点关注 `Notification Type` 与 `Alternative QoS Parameter Set Index`。
3. **N4侧**：若开了QoS Monitoring，会在UPF看到 `N4 Session Report`（报文类型按PFCP），携带时延测量IE；SMF侧 `N4 Session Establishment/Modification Response` 中能看到SRR。
4. **Npcf侧**：PCF收到 `Npcf_SMPolicyControl_UpdateNotify` 携带 QoS Notification，并向AF发 `Npcf_PolicyAuthorization_Notify`。

### 6.2 常见故障点与排错思路

| 现象 | 可能原因 | 排查方向 |
|------|----------|----------|
| 配了Alt QoS Profile但AF收不到档位变更 | `Notification Control`未置"requested" | 查PCC Rule / NGAP QoS Profile中QNC指示位 |
| RAN一直不报not fulfilled | RAN未启用URLLC QoS监控，或门限/周期未配 | 查RAN License、QoS Monitoring配置（SRR/NGAP监控请求） |
| AF收到档位但应用未适配 | AF未订阅QoS通知事件，或未处理Alt Index语义 | 查AF→PCF的PolicyAuthorization事件订阅与处理逻辑 |
| 切换后档位丢失/跳崖 | 源gNB未在HO上下文携带当前Applicable QoS Profile | 查Xn/N2 HO的QoS Flow上下文是否含档位信息（5.7.2.4.2） |
| N3时延测量为空/异常 | gNB与UPF时间戳能力未对齐，或时钟未同步 | 查GTP-U时间戳支持、PTP/时钟同步部署 |

## 七、与其他QoS保障方案的对比

| 维度 | 替代QoS档位+QNC（本文） | URLLC双连接冗余传输 | SSC三模式PSA重选 | 传统eMBB尽力而为 |
|------|------------------------|---------------------|------------------|------------------|
| 目标 | 在资源不足时**分级降级并通知** | 用双N3/N19路径**抗丢包** | 改变UPF锚点降端到端时延 | 不承诺 |
| 触发 | 无线资源/时延不达标 | 始终开启（端到端冗余） | UE移动/MEC需求 | —— |
| 反馈对象 | AF（应用层感知档位） | 无（对应用透明） | UE（SSC模式） | 无 |
| 适用 | 工业控制、远程驾驶 | 工业AR、电力保护 | 边缘计算本地分流 | 普通上网 |
| 代价 | 控制面信令开销 | 双倍用户面资源 | 切锚点会话中断感 | 无 |

可见，**双连接冗余是"用冗余换可靠"（用户面），替代档位是"用感知换可控"（控制面）**，二者常组合部署于URLLC切片。
## 九、常见问题

**Q1：Notification Control和Alternative QoS Profile必须一起用吗？**
A：不必。Notification Control可独立用于"无替代档"场景（5.7.2.4.1a），RAN只报二元fulfilled/not fulfilled；只有要精确告知"劣化到哪一档"时，才需叠加Alternative QoS Profile（5.7.2.4.1b）。URLLC切片推荐叠加使用。

**Q2：RAN报"not fulfilled + Alt Index=2"，AF该做什么？**
A：说明参考档和第1档都保不住了，仅第2档（更宽松的PDB/PER/GFBR）可保证。AF应按预定义的第2档策略降级——如拉长控制周期、降低采样率、启用本地缓存或人工接管——并继续监听后续"fulfilled"回升通知。

**Q3：QoS Monitoring测到的时延，会直接决定档位吗？**
A：不一定直接决定。RAN内部档位裁决综合自身调度状态与测量数据；QoS Monitoring的测量结果主要供SMF/PCF/NWDAF做策略与分析，是"事实依据"之一。闭环是否自动化取决于PCF/AF是否订阅并联动。

**Q4：切换时档位会断吗？**
A：规范要求源gNB把"当前可保证档位"作为QoS Flow上下文传给目标gNB（5.7.2.4.2），目标侧尽量维持。但若目标侧资源更差，仍可能立即降档并上报——这就是"切换后跳崖"现象，需结合QoS Monitoring日志定位。

**Q5：为什么我抓到Alt QoS Profile配置却从不上报？**
A：最常见是Notification Control指示位没置"requested"，或RAN侧QoS Monitoring未启用导致无判决依据。先查PCC Rule/NGAP的QNC位，再查RAN测量配置与License。

---

## 参考来源

1. [3GPP TS 23.501（System architecture for the 5G System）](https://www.3gpp.org/dynareport/23501.htm) — 5.7.1.2a Alternative QoS Profile、5.7.2.4 Notification control、5.33.3.3 QoS monitoring
2. [3GPP TS 38.413（NG-RAN; NGAP）](https://www.3gpp.org/dynareport/38413.htm) — PDU SESSION RESOURCE NOTIFY、QoS Flow Notify Item、Alternative QoS Parameter Set Index
3. [3GPP TS 23.502（Procedures for the 5G System）](https://www.3gpp.org/dynareport/23502.htm) — 4.3.2.2 PDU Session Establishment、QoS Notification处理
4. [5G NGAP PDU Session Resource Notify Message — 3glteinfo](https://www.3glteinfo.com/messages/5g/ngap/pdu-session-resource-notify/) — NGAP消息与IE结构解析
5. [5G QoS Notification Control for QoS fulfill/unfulfill — Derek Cheung, Medium](https://derekcheung.medium.com/5g-core-part-6-qos-notification-control-be7604b5e2eb) — fulfill/unfulfill闭环流程
6. [3GPP Release 16 5G NR Enhancements for URLLC — IEEE ComSoc TechBlog](https://techblog.comsoc.org/2023/08/19/3gpp-release-16-5g-nr-enhancements-for-urllc-in-the-ran-urllc-in-the-5g-core-network/) — QoS monitoring/冗余传输增强背景

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)