# 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 流。 ```mermaid 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、
Requested QoS Rules/QoS Flow Descriptions SMF->>PCF: Npcf_SMPolicyControl_Update（请求授权QoS） PCF-->>SMF: Policy Decision（Authorized QoS、计费/监控规则） SMF->>UPF: N4 Session Modification Request
(PDR/QER/FAR 增删改) UPF-->>SMF: N4 Session Modification Response SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(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 | ```mermaid 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
(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) ``` **设计意图解读：** 1. **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 缓存堆积。 2. **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 的结构如下： ```mermaid 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 ``` ```mermaid graph LR subgraph QoS Flow Description IE Q1["QoS op code
1=create/2=delete/3=modify"] --> Q2["QFI"] Q2 --> Q3["E flag: 是否含GFBR/MFBR"] Q3 --> Q4["参数列表:
5QI / GFBR-UL / GFBR-DL
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 可在集合间动态切换并上报。 ```mermaid 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 思路）： 1. **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` 子树。 2. **NGAP 层**：过滤 `ngap.procedureCode == 37`（PDU Session Resource Modify），看 `PDU Session Resource Modify List`，核对 `QosFlowAddOrModifyRequestList` 中的 QFI 与 5QI。 3. **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 在生产网常出现"成对出现"——一条下发、一条回退。 ## 参考来源 1. [3GPP TS 23.502 V18.10.0 — §4.3.3 PDU Session Modification](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — UE/network requested 流程主定义（含 4.3.3.2 LBO、4.3.3.3 HR roaming） 2. [3GPP TS 24.501 — §6.4.2 UE-requested PDU session modification](https://itecspec.com/3gpp/24.501/s/6.4.2) / §9.11.4.12 QoS Rule / §9.11.4.13 QoS flow description — NAS IE 与 T3581 定义 3. [TS 23.502 §4.3.3 — iTecSpec 条目索引](https://itecspec.com/3gpp/23.502/s/4.3.3) — 章节结构速查 4. [Cisco UCC 5G SMF Configuration and Administration Guide — Network-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.html) — 厂商触发源抽象与排队实现 5. [3glteinfo — 5G PDU Session Modification Procedure Call Flow](https://www.3glteinfo.com/call-flows/5g/pdu-session-modification/) — 端到端 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 等场景全覆盖。