<!-- title: 5G PDU会话修改信令拆解 -->
<!-- domain: protocols -->

# 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↔SMF | TS 24.501 | §6.4.2/6.4.3、§9.11.4（IE） | N1 SM容器消息定义与编码 |
| 流程级 | TS 23.502 | §4.3.3.2（UE发起）、§4.3.3.3（网络发起） | 端到端信令流程编排 |
| QoS模型 | TS 23.501 | §5.7.2、§5.7.5 | QoS Flow级参数、Reflective QoS |
| AMF↔RAN | TS 38.413 | §8.2.3、§8.2.4、§9.3.x | N2 SM信息（PDU Session Resource Modify） |
| SMF↔UPF | TS 29.244 | PFCP Session Modification | N4 QER/PDR/FAR联动 |
| SMF↔PCF | TS 29.512 | SM Policy Update | 策略授权与计费键变更 |
| AMF↔SMF | TS 29.502 | Nsmf_PDUSession_UpdateSMContext | N1透传与N2中转 |

理解这条链路的关键，是抓住 **"三个执行面"**：①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的完整时序：

```mermaid
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本身的参数）。二者结构如下：

```mermaid
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参数说明：

| IE | 含义 | 典型取值/用途 |
|----|------|---------------|
| 5GSM cause | 失败原因（仅Reject） | #37 QoS not accepted、#26 Insufficient resources、#31 Request rejected unspecified |
| Session-AMBR | 会话级聚合最大比特率 | 上下行各4字节，限速所有Non-GBR Flow |
| RQ timer value | 反射QoS计时器T3583取值 | 控制UE反射推导的存活时间 |
| Always-on PDU session indication | 是否always-on | 改变CM-IDLE下的会话保留策略 |
| QoS rules | 包过滤器规则集 | 决定UE上行QoS标记与过滤 |
| QoS flow descriptions | QoS Flow参数集 | 决定每条Flow的5QI/GFBR/MFBR |
| QoS Flow Level QoS Parameters | （经N2透传） | 含ARP、GFBR、MFBR、Notification Control、RQA |

**为什么分成两层？** 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** 双消息对：

```mermaid
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
```

三种发起方式的对比：

| 维度 | UE发起(§4.3.3.2) | PCF/AF发起(§4.3.3.3) | RAN发起(NGAP Indication) |
|------|------------------|----------------------|--------------------------|
| 触发源 | UE应用层 | PCF策略变更/AF请求 | gNB无线资源 |
| 首条NAS | Request(UE→网) | Command(网→UE，非请求) | 无（先走N2） |
| NGAP消息 | Modify Request | Modify Request | Modify Indication→Confirm |
| PCF交互 | SMF上报Update | PCF主动Update Notify | 一般不再改Policy |
| 计时器 | UE侧T3582 | 网络侧T3582 | 无 |

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

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

```mermaid
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)](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — §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)](https://www.etsi.org/deliver/etsi_ts/138400_138499/138413/19.00.00_60/ts_138413v190000p.pdf) — §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)](https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/17.07.01_60/ts_124501v170701p.pdf) — §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](https://derekcheung.medium.com/5g-core-part-4-dedicated-qos-flow-and-pdu-session-modification-eba4a14d62d4) — Network-initiated Dedicated QoS Flow 抓包分析
5. [5G QoS Flow Modification Procedure Call Flow — 3glteinfo](https://www.3glteinfo.com/call-flows/5g/qos-flow-modification/) 与 [PDU Session Modification Command (NAS) — 3glteinfo](https://www.3glteinfo.com/messages/5g/nas/pdu-session-modification-command/) — 消息级IE与计时器行为
6. [Cisco UCC 5G SMF Admin Guide — Network-initiated / AN-initiated Session Modification Procedures](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/smf/2025-03/config-and-admin/ucc-5g-smf-config-and-admin-guide-release-2025-03/m_network-initiated-session-modification-procedures.pdf) — 厂商侧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 等场景全覆盖。

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