5G PDU会话修改信令全链拆解：从QoS Flow增删改到NGAP/N4联动

一、为什么需要"修改"而不是"重建"

5G核心网在PDU会话建立（TS 23.502 §4.3.2）之后，会话所承载的QoS流（QoS Flow）并不是一成不变的。一份会话建立报文只下发了"默认QoS规则（Default QoS Rule）"对应的一条非GBR QoS Flow，而真正业务起来后，大量动态需求会通过 PDU Session Modification 过程（TS 23.502 §4.3.3）在线调整，典型场景包括：

• 专用QoS Flow建立：IMS VoNR拨通后，SMF为语音媒体建立一条5QI=1的GBR QoS Flow，并在挂机时删除该Flow；
• QoS参数调谐：视频通话从窄带升级到宽带，GFBR/MFBR上调；
• Session-AMBR调整：套餐限速、共享流量触顶时AMBR下调；
• Reflective QoS（反射QoS）激活：通过下行报文RQI让UE反射式推导上行QoS规则，节省信令；
• Always-on PDU Session指示更新：决定UE进入CM-IDLE时是否保留会话；
• ATSSS、冗余传输、QNC（QoS Notification Control）状态变化等。

修改过程区别于重建的关键设计意图是最小化信令、保持会话标识（PDU Session ID）与IP前缀不变，避免上层TCP连接断流。这正是工程上抓包定位QoS问题时最常遇到的流程之一。

二、协议坐标：一次修改牵动的规范矩阵

一次PDU会话修改横跨NAS、SBI、NGAP、PFCP四类协议栈，对应规范如下表：

理解这条链路的关键，是抓住 "三个执行面"：①UE侧5GSM/NAS的QoS规则与QoS Flow描述；②RAN侧的DRB与QoS Flow映射；③UPF侧的QER（QoS执行规则）与PDR匹配。三个面的状态必须最终一致，否则会出现"信令成功但业务不通"。

三、UE请求的PDU会话修改流程（TS 23.502 §4.3.3.2）

UE主动发起是修改流程中最完整的形态，下图给出从N1到N2、N4的完整时序：

sequenceDiagram
    autonumber
    participant UE
    participant gNB as NG-RAN(gNB)
    participant AMF
    participant SMF
    participant PCF
    participant UPF
    UE->>SMF: PDU Session Modification Request<br/>(UL NAS TRANSPORT→UpdateSMContext)<br/>含新QoS规则/QoS Flow描述/包过滤器
    SMF->>PCF: Npcf_SMPolicyControl_Update<br/>(请求授权QoS、PCC规则)
    PCF-->>SMF: 授权QoS(5QI/GFBR/MFBR/ARP)
    SMF->>UPF: N4 PFCP Session Modification Request<br/>(新建/改QER、PDR、FAR)
    UPF-->>SMF: N4 Modification Response
    SMF->>AMF: Namf_N1N2MessageTransfer<br/>N1: PDU Session Modification Command<br/>N2: PDU Session Resource Modify Request Transfer
    AMF->>gNB: N2 PDU Session Resource Modify Request<br/>(QoS Flow Add/Modify/Release List)
    AMF->>UE: DL NAS TRANSPORT<br/>(PDU Session Modification Command)
    gNB->>UE: RRC Reconfiguration<br/>(建立/修改DRB、QoS Flow→DRB映射)
    UE-->>gNB: RRC Reconfiguration Complete
    gNB-->>AMF: N2 PDU Session Resource Modify Response
    AMF->>SMF: UpdateSMContext(N2响应结果)
    UE->>SMF: PDU Session Modification Complete<br/>(确认收到，关闭T3582)

逐条消息中的关键IE解析：

1. PDU Session Modification Request（UE→SMF，承载于上行NAS TRANSPORT，再由AMF通过 Nsmf_PDUSession_UpdateSMContext 转发）。核心IE：PDU Session ID、Procedure transaction identity、QoS rules（含Rule operation code=Create/Modify/Delete）、QoS flow descriptions（含Operation code与5QI/GFBR/MFBR）、可选MA PDU session等。当UE想新建一条视频专用Flow时，会带一条Create new QoS rule+Create new QoS flow description。
2. SM Policy Update（SMF↔PCF）：SMF携带业务信息请求授权，PCF返回PCC规则与授权的QoS参数（5QI、ARP、GFBR、MFBR、Session-AMBR、QNC指示）。若PCF发现与签约不符，可直接下发5GSM cause（如#37 QoS not accepted）。
3. N4 PFCP Session Modification（SMF→UPF）：SMF更新 QER（新的GFBR/MFBR、QFI）、PDR（新增包过滤器）、FAR（转发动作）。UPF按新QER执行令牌桶限速。
4. PDU Session Modification Command（网络→UE，DL NAS TRANSPORT）。这是修改流程的"心脏消息"，下文第四节详述其IE。
5. N2 PDU Session Resource Modify Request（AMF→gNB，承载 PDU Session Resource Modify Request Transfer，TS 38.413 §9.3）：含 QoS Flow Add/Modify/Release List，每条带 QoS Flow Level QoS Parameters（5QI、ARP、GFBR、MFBR、Notification Control、Reflective QoS Attribute等）。
6. RRC Reconfiguration（gNB→UE）：在空口落地——建立新DRB或将新QoS Flow映射到已有DRB（QoS Flow到DRB映射是RAN自主决策）。
7. PDU Session Modification Complete（UE→SMF）：当Command中要求确认（acknowledged）时必须回送，否则SMF侧T3582超时会重传Command。

设计意图上，步骤4的N1（给UE）与步骤5的N2（给RAN）在同一次N1N2MessageTransfer中下发，保证UE空口规则与RAN侧DRB同时生效，避免上下行QoS策略错配。

四、QoS规则与QoS Flow描述的编码机制（TS 24.501 §9.11.4）

修改流程的精髓在于"如何在一条NAS消息里同时表达 增/改/删"。这由两类核心IE协作完成——QoS rules（面向UE的包过滤器到QoS Flow的绑定）与 QoS flow descriptions（面向QoS Flow本身的参数）。二者结构如下：

flowchart LR
    subgraph QR["QoS Rule（UE执行）"]
        QRI["QoS Rule Identifier"]
        OPC["Rule Operation Code<br/>001=Create/010=Delete<br/>011=增改删过滤器<br/>100=替换全部过滤器<br/>101=仅改其他属性"]
        DQR["DQR位(默认QoS规则)"]
        NF["包过滤器个数+过滤器列表<br/>(方向/协议/五元组)"]
        QRP["QoS Rule Precedence(优先级)"]
        QFI1["QFI(绑定到哪条QoS Flow)"]
    end
    subgraph QFD["QoS Flow Description（QoS Flow本身）"]
        QFI2["QFI(6bit)"]
        OPC2["Operation Code<br/>001=Create/010=Delete/011=Modify"]
        FQI["5QI(或Non-5G)"]
        GFBR["GFBR UL/DL"]
        MFBR["MFBR UL/DL"]
        AW["Averaging Window"]
    end
    QFI1 -.绑定同一Flow.-> QFI2
    style QR fill:#eef,stroke:#447
    style QFD fill:#efe,stroke:#474

PDU Session Modification Command 消息的关键IE参数说明：

为什么分成两层？ QoS Rule解决"哪些业务包走这条Flow"（匹配+标记），QoS Flow Description解决"这条Flow的QoS待遇是多少"（资源）。这种解耦让SMF可以单独下发"只改参数不动过滤器"（Operation code=101）的轻量修改，大幅减少空口信令开销。

五、网络与RAN发起的修改（TS 23.502 §4.3.3.3）

更常见的情况是网络侧主动发起——例如PCF收到AF通过NEF下发的带宽调整请求，或RAN因无线资源恶化无法保证GBR。后者使用NGAP独有的 Modify Indication/Confirm 双消息对：

sequenceDiagram
    autonumber
    participant gNB as NG-RAN
    participant AMF
    participant SMF
    participant UE
    Note over gNB: 无线资源不足，无法保证某GBR QoS Flow
    gNB->>AMF: PDU Session Resource Modify INDICATION<br/>(Failed QoS Flow List,原参数)
    AMF->>SMF: UpdateSMContext(转发Indication内容)
    Note over SMF: 决策:降QoS 或 释放该Flow
    SMF->>AMF: N1N2MessageTransfer<br/>N1: PDU Session Modification Command(改参数/删Flow)<br/>N2: PDU Session Resource Modify Confirm Transfer
    AMF->>gNB: PDU Session Resource MODIFY CONFIRM
    AMF->>UE: DL NAS TRANSPORT(Command)
    UE->>SMF: PDU Session Modification Complete

三种发起方式的对比：

六、Reflective QoS的状态机与RQ计时器

当SMF在Modification Command中下发 Reflective QoS Attribute(RQA) 并配置 RQ timer value(T3583) 时，UE侧每条QoS Flow会运行一个独立的反射QoS状态机（TS 23.501 §5.7.5）：

stateDiagram-v2
    [*] --> RQ_Inactive
    RQ_Inactive --> RQ_Active: 收到下行包且RQI=1<br/>(启动/重启T3583,推导UL QoS规则)
    RQ_Active --> RQ_Active: 后续RQI=1的DL包<br/>(重启T3583)
    RQ_Active --> RQ_Inactive: T3583超时<br/>(丢弃UL QoS规则)
    RQ_Active --> RQ_Inactive: SMF下发删除QoS Flow
    RQ_Active --> [*]: PDU会话释放

这个机制的设计意图是用数据面代替控制面：UPF在下行报文DSCP中打上RQI（TS 29.244），UE据此自动推导上行QoS规则，无需对每个上行业务单独发Modification Request，是高并发会话下信令优化的关键利器。

七、抓包识别与排错实战

如何在抓包中识别一次修改流程：

1. Wireshark过滤：nas-5gs && nas_5gs.mm.message_type == 0x41（DL NAS TRANSPORT）展开 nas_5gs.sm.pdu_session_identity 与 nas_5gs.sm.message_type==0xca（PDU Session Modification Command）；
2. 关联N2：过滤 ngap && ngap.procedure_code == 37（PDU Session Resource Modify）确认空口落地；
3. 关联N4：过滤 pfcp && pfcp.msg_type == 52（Session Modification Request）查看QER/PDR变更；
4. 关联PCF：SBI层面 http2.header.user_agent 或 http2.headers.path contains "/npcf-smpolicycontrol"。

常见故障点：

• UE发了Request，SMF没回Command：检查AMF是否通过 UpdateSMContext 正确转发N1；若UE侧T3582超时4次（默认约30s）会本地放弃；
• Command成功但业务不通：大概率是N4 QER未生效或包过滤器与业务实际五元组不匹配——看UPF日志的PDR匹配计数；
• gNB回Indication（失败）：RAN侧无线资源无法保证GBR，SMF需降配或释放Flow；若SMF未正确响应会触发QNC通知PCF；
• 5GSM cause #37 QoS not accepted：PCF授权QoS与UE请求不一致，多为5QI/GFBR签约值问题；
• Complete丢失：网络侧T3582超时会重传Command（最多4次），仍无响应则放弃并可能触发释放。

常见问题

Q1: PDU会话修改与重建（先释放再建立）的区别？ A: 修改保持PDU Session ID与IP前缀不变，上层TCP连接不断流，信令仅涉及增量QoS Flow；重建会更换会话标识和IP，导致业务重连，开销大得多。规范要求优先用修改满足动态QoS需求。

Q2: QoS Rule的Operation code=011和100有什么区别？ A: 011（Modify existing and add/replace/delete packet filters）是在保留原有过滤器基础上增删改部分过滤器；100（Modify and replace all packet filters）是整体替换该规则下的全部过滤器。前者增量、省信令，后者用于全量重配置。

Q3: 为什么UE发起的修改也要去问PCF？ A: UE请求的QoS可能超出签约或运营商策略授权范围，SMF必须经 Npcf_SMPolicyControl_Update 获得授权QoS后才能下发，防止UE越权占用资源。这是5G相比EPS的策略增强点。

Q4: RAN发起的Modify Indication与Notification是一回事吗？ A: 不是。Modify Indication（§8.2.4）用于RAN主动请求改QoS资源（如GBR无法满足），是双向协商；PDU Session Resource Notify（§8.2.x）用于通知QNC（QoS Notification Control）事件——GBR Flow不再/重新满足，是单向事件上报，触发PCF向AF通知。

Q5: Reflective QoS激活后UE侧T3583一直重启，会不会无限占用？ A: 不会。只要下行持续有RQI=1报文，T3583就持续重启、反射QoS保持有效；一旦该业务停止下发、T3583超时（默认60s量级），UE自动丢弃推导出的上行QoS规则，回退到默认QoS。

参考来源

1. 3GPP TS 23.502 V18.10.0 — Procedures for the 5G System (5GS) — §4.3.3 PDU Session Modification（UE发起§4.3.3.2 / 网络发起§4.3.3.3）
2. 3GPP TS 38.413 V19.0.0 — NG Application Protocol (NGAP) — §8.2.3 PDU Session Resource Modify、§8.2.4 Modify Indication、§9.3 PDU Session Resource Modify Request/Confirm Transfer
3. 3GPP TS 24.501 — NAS protocol for 5GS (Stage 3) — §6.4.2 UE-requested PDU session modification、§9.11.4 QoS rules / QoS flow descriptions 编码
4. 5G Dedicated QoS Flow & PDU Session Modification Wireshark — Derek Cheung, Medium — Network-initiated Dedicated QoS Flow 抓包分析
5. 5G QoS Flow Modification Procedure Call Flow — 3glteinfo 与 PDU Session Modification Command (NAS) — 3glteinfo — 消息级IE与计时器行为
6. Cisco UCC 5G SMF Admin Guide — Network-initiated / AN-initiated Session Modification Procedures — 厂商侧PCF交互与AN发起处理差异

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