首页 › protocols › PDU会话修改双触发信令拆解

5G PDU 会话修改（PDU Session Modification）双触发信令全链拆解

聚焦 TS 23.502 §4.3.3、TS 24.501 §6.4.2/§9.11.4、TS 38.413 与 TS 29.244，从 UE 触发与网络触发两条主干，逐 IE 解构 5G 系统中"不重建会话、仅调整 QoS 流"的核心机制。

一、机制定位：为什么需要"会话修改"而不是"重建"

PDU 会话一旦建立，UE 与 DN 之间的 N6 隧道、QoS 流、计费规则就长期存在。但业务是动态的：视频从低清切到 4K、VoNR 切到普通网页、AF 通过 NEF 下发了新的 QoS 保障请求、PCF 时段策略变化、或者 NG-RAN 反馈某个 GBR 流的 GFBR 已无法保证——这些场景下重建 PDU 会话代价极高：要重做 NAS 鉴权链路上下文、重建 N4、重选 PSA、丢包窗口大。

3GPP 因此在 TS 23.502 §4.3.3 定义了 PDU Session Modification 过程，其本质是：保留原 PDU Session ID 与用户面隧道，仅对 QoS 流集合（QoS Flow）、QoS 规则（QoS Rule）、会话聚合速率（Session-AMBR）、默认 QoS、以及 RAN 侧无线承载（DRB/SPS/CG）做增量式增删改。

该过程可由两个主体发起，形成"双触发"格局：

UE 触发（UE-initiated，§4.3.3.2 步骤 1）：UE 主动发 PDU SESSION MODIFICATION REQUEST；
网络触发（network-initiated，§4.3.3.2 步骤 4a/4b）：由 SMF 主动发 PDU SESSION MODIFICATION COMMAND，背后触发源可能是 PCF、(R)AN、UDM、AF/NEF，或 SMF 自身（如反射 QoS 变化）。

理解"双触发"的关键，是抓住一个共同终点：两条链路最终都收敛到 PDU Session Modification Command（TS 24.501）这一条 NAS 消息，并由它驱动 N4 与 N2 的资源调整。

二、UE 触发 PDU 会话修改：完整信令时序

典型场景：UE 内部某 APP 提出新的 QoS 需求（如拉起一路专用 GBR 流），或希望删除某个不再使用的 QoS 流。

sequenceDiagram
    autonumber
    participant UE
    participant (R)AN as gNB
    participant AMF
    participant SMF
    participant UPF
    participant PCF

    UE->>SMF: UL NAS TRANSPORT(PDU Session Modification Request)
    Note over UE,SMF: 经AMF透传，含PDU Session ID、<br/>Requested QoS Rules/QoS Flow Descriptions
    SMF->>PCF: Npcf_SMPolicyControl_Update（请求授权QoS）
    PCF-->>SMF: Policy Decision（Authorized QoS、计费/监控规则）
    SMF->>UPF: N4 Session Modification Request<br/>(PDR/QER/FAR 增删改)
    UPF-->>SMF: N4 Session Modification Response
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N1=PDU Session Modification Command, N2=PSA Resource Modify)
    AMF->>gNB: NGAP PDU Session Resource Modify Request
    AMF->>UE: DL NAS TRANSPORT(PDU Session Modification Command)
    Note over UE,gNB: RRC Reconfiguration（DRB/SPS/CG联动）
    gNB-->>AMF: PDU Session Resource Modify Response
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Response（含N2 SM resp）
    UE->>SMF: UL NAS TRANSPORT(PDU Session Modification Complete)

关键 IE 逐消息解析：

第 1 步 PDU SESSION MODIFICATION REQUEST（TS 24.501 §9.11.3.4）携带的 N1 SM 容器中，核心是两类 IE：

Requested QoS rules（§9.11.4.12）：UE 用 operation code 声明要"创建/修改/删除"哪条 QoS 规则，并附带新的包过滤器（Packet Filter，五元组 + 方向）。
Requested QoS flow descriptions（§9.11.4.13）：UE 直接给出该 QoS 流的 5QI、GFBR、MFBR、ARP 等参数期望值（仅 GBR 流场景）。

UE 发出该请求后，按 TS 24.501 §6.1.3.1 启动 T3581（默认 16s） 作为守护定时器；若超时未收到 PDU Session Modification Command/Reject，UE 重传最多 4 次后失败。

第 3 步是"授权裁决"环节。SMF 不会无条件接受 UE 的请求，必须经 PCF 决策：PCF 比对签约（UDM 下发）、AF/NEF 的策略、本地运营商策略，返回 Authorized QoS。这是 5G 与 EPS 的一个本质差异——QoS 决策权集中到 PCF，SMF 只是执行者。

第 4 步 N4 会话修改由 SMF 向 UPF 下发 PFCP Session Modification Request（TS 29.244），用 IE group 对 PDR/QER/FAR/URR 做增量改写。详见第四节。

第 5 步是双触发链路的汇流点：无论谁发起，最终向 UE 下发的都是 PDU Session Modification Command。SMF 通过 Namf_Communication_N1N2MessageTransfer 一次性把 N1（给 UE）与 N2（给 gNB）打包递给 AMF，体现了 5GC SBI 的"N1N2 消息合一传输"设计。

第 9 步 UE 必须回 PDU Session Modification Complete（或 Reject）。在 Complete 中可携带 QoS rules with operation reject / QoS flow descriptions with operation reject / QoS rule missing 等 IE，用以反馈"哪些规则无法执行"，供 SMF 做 ROLLBACK 决策。

三、网络触发 PDU 会话修改：触发源全景与时序

网络触发更复杂，因为触发源有多个。按 TS 23.502 §4.3.3.2 步骤 4a，典型触发包括：

触发源	触发事件	典型业务后果
PCF	AF/NEF 下发新策略、时段策略切换、订阅变更	新增专用 GBR 流或下调 Session-AMBR
(R)AN	Notification Control：GBR 流 GFBR 无法保证	下调 5QI 或释放该流
UDM	订阅数据变更（UDM→SMF 通过 UDM_SDM_Notification）	修改 Authorized Session-AMBR/默认 5QI
SMF 自身	反射 QoS 状态变化、SLA 变化	更新 QER 的 gating/rate

sequenceDiagram
    autonumber
    participant PCF
    participant SMF
    participant AMF
    participant gNB
    participant UE
    participant UPF

    Note over PCF,SMF: 触发源：PCF策略变更 / RAN Notification / UDM订阅变更
    PCF->>SMF: Npcf_SMPolicyControl_UpdateNotify（SMPolicyUpdate）
    SMF->>UPF: N4 Session Modification Request
    UPF-->>SMF: N4 Session Modification Response
    alt UE 处于 CM-IDLE
        SMF->>AMF: 触发网络发起的业务请求（ Paging）
        AMF->>gNB: Paging
        gNB->>UE: Paging（拉起空口）
        UE-->>AMF: Service Request
    end
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N1=Mod Command + N2=Resource Modify)
    AMF->>gNB: NGAP PDU Session Resource Modify Request
    AMF->>UE: DL NAS TRANSPORT(PDU Session Modification Command)
    gNB-->>AMF: PDU Session Resource Modify Response
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Response
    UE->>SMF: UL NAS TRANSPORT(PDU Session Modification Complete)

设计意图解读：

CM-IDLE 兜底：网络触发时 UE 可能正空闲。SMF 通过 Namf_Communication_N1N2MessageTransfer 携带的 ueAccAssistData/触发条件，让 AMF 先发 Paging 拉起空口（即网络触发的 Service Request，TS 23.502 §4.2.3.3）。这是 5G "控制面按需唤醒"思想在会话修改里的体现——N1/N2 消息只在 UE 到达 CM-CONNECTED 后才真正下发，避免消息在 AMF 缓存堆积。
N1 与 N2 的耦合：当修改涉及需要无线承载的 GBR 流时，N2 SM 信息（PDU Session Resource Modify Request Transfer，TS 38.413 §9.3.4.4）与 N1 必须同批送达，确保 UE 收到新 QoS Rule 时，gNB 侧 DRB/SPS/CG 也已就绪，否则会出现"UE 已按新 QFI 打包但空口无承载"的丢包窗口。

四、QoS Rule 与 QoS Flow Description：增量操作的核心数据结构

PDU 会话修改能"只动局部、不拆会话"，根本在于 NAS 层定义了带 operation code 的增量 IE。两类 IE 的结构如下：

graph TD
    subgraph QoS Rule IE
        A["DQR bit（是否默认规则）"]
        B["QoS Rule Identifier"]
        C["Operation Code"]
        D["Packet Filters（含方向、五元组）"]
        E["QoS Rule Precedence"]
        F["QFI"]
        A --> B --> C --> D --> E --> F
    end
    subgraph Operation Code 取值
        C1["1=Create 新规则"]
        C2["2=Delete 规则"]
        C3["3=Modify并替换全部过滤器"]
        C4["4=Modify不动过滤器"]
        C5["5=Modify追加过滤器"]
        C6["6=Modify删除部分过滤器"]
    end
    C -.-> C1 & C2 & C3 & C4 & C5 & C6

graph LR
    subgraph QoS Flow Description IE
        Q1["QoS op code<br/>1=create/2=delete/3=modify"] --> Q2["QFI"]
        Q2 --> Q3["E flag: 是否含GFBR/MFBR"]
        Q3 --> Q4["参数列表:<br/>5QI / GFBR-UL / GFBR-DL<br/>MFBR-UL / MFBR-DL / Averaging Window"]
    end

两类 IE 的分工（高频考点）：

维度	QoS Rule	QoS Flow Description
作用对象	UE 侧（N1，TS 24.501）	RAN/UPF 侧（N2/N4，经 SMF 转换）
核心内容	包过滤器 ↔ QFI 的映射 + 规则优先级	QFI ↔ 5QI/GFBR/MFBR/ARP
谁用	UE 做上行分类（UL CL）	gNB 做空口调度、UPF 做门控/限速
操作码粒度	6 种（含过滤器级增删）	3 种（create/delete/modify）

排错要点：抓包里若看到 UE 上行报文被错误映射到 default QoS flow，往往是某条 QoS Rule 的包过滤器与 Mod Command 中的不同步——检查 UE 是否回 Complete 且无 QoS rule missing。

五、N4（PFCP）会话修改：UPF 侧的增量改写

SMF 在 PDU Session Modification Command 下发前后，必须先通过 N4 把用户面规则同步给 UPF（TS 29.244）。N4 Session Modification 用 IE group 增删改以下规则：

PDR（Packet Detection Rule）：新增/修改/删除包检测规则，含 SDF 模板（用于把下行业务流识别到对应 QFI）。
QER（QoS Enforcement Rule）：承载 QFI、gate status（开/关）、Session-AMBR 与 per-flow MBR 的执行单元——Session-AMBR 的限速就是在 QER 上生效的。
FAR（Forwarding Action Rule）：转发动作（含 N3/N9 TEID、N6 接口）。
URR（Usage Reporting Rule）：计费/用量测量。

会话修改若仅改 Session-AMBR，SMF 只动 QER 的 MBR 字段即可；若新增专用 GBR 流，则需 Create 一组新 PDR+QER+FAR。这条 N4 信令是会话修改在数据面的真正落地，也是运营商做限速、QoS 保障时排错的第一现场。

六、Rel-17/18 增强：Alternative QoS Set 与 Notification Control

这是会话修改在 URLLC/低时延场景下的关键演进，也是面试中区分"知道流程"与"懂演进"的分水岭。

当某个 GBR 流的 QoS 期望（GFBR）无法稳定保证时，传统做法只有"保证/不保证"二态。Rel-17 引入 Alternative QoS Set（AQS）/ Alternative QoS Profile（TS 23.501 §5.7.2.1、TS 23.502 §4.3.3.1）：SMF 在 QoS Flow 描述中携带一组递降的可选 QoS 参数集，(R)AN/UE 可在集合间动态切换并上报。

stateDiagram-v2
    [*] --> QoS_Guaranteed: GFBR可保证
    QoS_Guaranteed --> QoS_NotGuaranteed: RAN检测GFBR无法保证（Notification）
    QoS_NotGuaranteed --> AltQoS_Active: UE/RAN切换到Alternative QoS Set
    AltQoS_Active --> QoS_Guaranteed: 恢复满足GFBR
    QoS_NotGuaranteed --> Network_Modify: SMF收到通知→PCF裁决
    Network_Modify --> [*]: 触发network-initiated会话修改（降5QI或删流）

Notification Control 联动：若 SMF 在 QoS Flow Profile 里设置了 "Notification Control" 标志，当 gNB 判定该 GBR 流的 GFBR 无法保证时，通过 N2 上报 NG-RAN Notification（TS 38.413），经 AMF 透传到 SMF，再由 Npcf_SMPolicyControl_Notify 通知 PCF。这条通知正是上文"网络触发"的重要来源之一——它把"空口质量退化"实时反馈到策略层，闭环驱动一次 network-initiated 会话修改。

Rel-18 进一步在该框架上细化了多 AQS 的时序与计费影响，使会话修改成为时延敏感业务"自愈"的核心手段。

七、实战连接：抓包识别与故障排查

如何用 Wireshark/TShark 识别这条流程（结合 pcap-analyzer 思路）：

NAS-5GS 层：过滤 nas-5gs.mm.message_type == 0x41（UL NAS TRANSPORT 携带 PDU session modification request，msg type 65）与 0xd1（PDU session modification command，msg type 209）。展开 nas-5gs.sm.pdu_session_modification_request，重点看 qos_rules 与 qos_flow_descriptions 子树。
NGAP 层：过滤 ngap.procedureCode == 37（PDU Session Resource Modify），看 PDU Session Resource Modify List，核对 QosFlowAddOrModifyRequestList 中的 QFI 与 5QI。
PFCP（N4）层：过滤 pfcp.msg_type == 0x35（Session Modification Request），检查 create_qer/update_qer 的 MBR 字段是否与 Session-AMBR 一致。

常见故障点：

现象：UE 收到 Mod Command，但很快回 Reject。根因多为 PCF 授权的 QoS 与 UE 请求差距过大，或 UE 能力不支持该 5QI（如不支持某 GBR 5QI 的 SPS）。
现象：Mod Command 下发后空口无 DRB 联动，业务仍走 default flow。根因：N2 SM 信息与 N1 解耦丢失，或 AMF 未把 N2 转发到 gNB。重点查 Namf_Communication_N1N2MessageTransfer 的 n2InfoContainer 是否存在。
现象：T3581 超时。根因：PCF/UDM 响应慢或 SMF 到 UPF 的 N4 失败。查 SMF 日志的 N4 Session Modification Response 错误码。
现象：网络触发但 UE 长时间无响应。根因：UE 处 CM-IDLE 且 Paging 未成功，需检查 AMF 是否触发 Service Request 及空口覆盖。

常见问题

Q1: UE 触发与网络触发的 PDU 会话修改，最本质区别是什么？ A: 触发方向与起始消息不同：UE 触发由 UE 发 Modification Request、UE 侧守 T3581；网络触发由 SMF 发 Modification Command，且必须处理 UE 的 CM-IDLE 唤醒（Paging/Service Request）。但二者最终都收敛到同一条 PDU Session Modification Command 驱动 N4/N2 改写。

Q2: QoS Rule 和 QoS Flow Description 有什么区别？为什么 NAS 里两者都要带？ A: QoS Rule 服务于 UE 的上行分类（包过滤器→QFI），QoS Flow Description 服务于 RAN/UPF 的调度与限速（QFI→5QI/GFBR/MFBR）。NAS 同时携带二者，是为了让 UE、gNB、UPF 三方在同一时刻对"某 QFI 的 QoS 参数"达成一致，避免 UE 按 GFBR 发包而空口按更低速率调度。

Q3: 修改 Session-AMBR 会不会影响已经在传的业务？ A: 会。Session-AMBR 在 UPF 的 QER 上即时生效，超速率的包会被丢弃或标记。所以运营商调整套餐限速时，常见现象是"流媒体瞬时卡顿"，正是会话修改在数据面落地的直接表现。

Q4: Notification Control 触发的会话修改，和 SSC 模式 3 锚点重定位是一回事吗？ A: 不是。Notification Control 是对同一 PDU 会话内某 QoS 流的参数调整（降 5QI 或删流），不换锚点；SSC 模式 3 重定位是更换 UPF PSA，会重建用户面隧道。两者都会用到会话/资源修改类信令，但语义和影响面完全不同。

Q5: 会话修改失败会回退吗？ A: 取决于失败点。若 PCF 拒绝，SMF 直接回 UE Reject，UPF 不动；若 N4 已改但 UE 回 Reject，SMF 需做 ROLLBACK，再次发 N4 Session Modification 恢复原 QER/PDR。这也是为什么 N4 Session Modification 在生产网常出现"成对出现"——一条下发、一条回退。

参考来源

3GPP TS 23.502 V18.10.0 — §4.3.3 PDU Session Modification — UE/network requested 流程主定义（含 4.3.3.2 LBO、4.3.3.3 HR roaming）
3GPP TS 24.501 — §6.4.2 UE-requested PDU session modification / §9.11.4.12 QoS Rule / §9.11.4.13 QoS flow description — NAS IE 与 T3581 定义
TS 23.502 §4.3.3 — iTecSpec 条目索引 — 章节结构速查
Cisco UCC 5G SMF Configuration and Administration Guide — Network-initiated Session Modification Procedures — 厂商触发源抽象与排队实现
3glteinfo — 5G PDU Session Modification Procedure Call Flow — 端到端 call flow 与消息 IE 释义

本文由「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学通信知识星球海报-扫码加入