首页 › slicing-mec › 5G替代QoS档位通知控制拆解

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切片（如远程手术、柔性制造）容不得这种"闷头掉线"，它要的是两件事：

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

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是档位刻度。本文聚焦这套控制面闭环。

二、整体闭环架构

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层级如下：

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）。

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：

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档保得住"？依据来自两层测量：

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）抓包里按以下特征识别：

下发阶段：在 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，即说明该流启用了本机制。
上报阶段：出现 PDU SESSION RESOURCE NOTIFY（procedureCode = id-PDUSessionResourceNotify），其Notify Transfer内含 QoS Flow Notify List，重点关注 Notification Type 与 Alternative QoS Parameter Set Index。
N4侧：若开了QoS Monitoring，会在UPF看到 N4 Session Report（报文类型按PFCP），携带时延测量IE；SMF侧 N4 Session Establishment/Modification Response 中能看到SRR。
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。

参考来源

3GPP TS 23.501（System architecture for the 5G System） — 5.7.1.2a Alternative QoS Profile、5.7.2.4 Notification control、5.33.3.3 QoS monitoring
3GPP TS 38.413（NG-RAN; NGAP） — PDU SESSION RESOURCE NOTIFY、QoS Flow Notify Item、Alternative QoS Parameter Set Index
3GPP TS 23.502（Procedures for the 5G System） — 4.3.2.2 PDU Session Establishment、QoS Notification处理
5G NGAP PDU Session Resource Notify Message — 3glteinfo — NGAP消息与IE结构解析
5G QoS Notification Control for QoS fulfill/unfulfill — Derek Cheung, Medium — fulfill/unfulfill闭环流程
3GPP Release 16 5G NR Enhancements for URLLC — IEEE ComSoc TechBlog — 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学通信知识星球海报-扫码加入