# PDU会话修改三触发源与QoS Flow动态调整信令全链路拆解 ## 一、引言：为什么PDU Session Modification是5G核心网最频繁的信令流程 在5G系统中，PDU Session Establishment建立了一条从UE到DN的数据通道，但这条通道的QoS参数并非一成不变。当用户从浏览网页切换到视频通话、当网络策略发生变化、当无线信道质量恶化时，都需要通过**PDU Session Modification**流程动态调整QoS Flow的参数、添加新的QoS Flow、或删除不再需要的QoS Flow。 3GPP TS 23.502 Section 4.3.3定义了PDU Session Modification的完整信令流程。与4G LTE的Dedicated Bearer Establishment/Modification相比，5G的PDU Session Modification在架构上有本质差异：**QoS Flow是5G新引入的概念，它不与DRB一一绑定，而是由(R)AN自主决定如何将QoS Flow映射到DRB**。这一设计使得PDU Session Modification的信令交互更加灵活，但也带来了更复杂的状态同步问题。 本文将深入拆解PDU Session Modification的三种触发源（UE发起、网络/PCF发起、AN发起），逐步解析每条信令消息中的关键IE，画出完整的时序图，并分析不同触发源之间的设计权衡。 ## 二、PDU Session Modification的三种触发源 PDU Session Modification有三种基本触发场景，定义在TS 23.502 Section 4.3.3中： ```mermaid flowchart TD A[PDU Session Modification] --> B[UE-Initiated
TS 23.502 §4.3.3.2] A --> C[Network-Initiated
TS 23.502 §4.3.3.2] A --> D[AN-Initiated
TS 23.502 §4.3.3.3] B --> B1[请求新Packet Filter] B --> B2[修改现有QoS参数] B --> B3[删除Packet Filter] C --> C1[PCF策略变更] C --> C2[SMF本地决策] C --> C3[AF请求触发] D --> D1[AN资源释放] D --> D2[AN QoS调整] ``` ### 2.1 三种触发源的对比 | 维度 | UE-Initiated | Network(PCF/SMF)-Initiated | AN-Initiated | |------|-------------|--------------------------|-------------| | **触发者** | UE通过NAS SM信令 | PCF通过N7接口或SMF自身 | (R)AN通过N2接口 | | **典型场景** | UE发起视频通话、请求新的包过滤器 | 策略变更、计费事件、AF请求 | 无线资源释放、QoS Flow失败 | | **NAS方向** | UE→SMF（请求），SMF→UE（命令） | SMF→UE（命令，UE无请求） | 不涉及UE NAS（纯N2） | | **PCF交互** | SMF向PCF请求策略授权 | PCF主动推送或SMF查询 | SMF不向PCF发送策略更新 | | **N4交互** | 始终涉及 | 始终涉及 | 视情况而定 | | **规范章节** | §4.3.3.2 Steps 1-16 | §4.3.3.2（PCF-initiated部分） | §4.3.3.3 | | **QoS Flow操作** | 添加/修改/删除均可 | 添加/修改/删除均可 | 通常仅修改或释放 | ### 2.2 设计意图 三种触发源的设计体现了5G架构的**分布式控制**理念： - **UE-Initiated**：允许终端根据应用层需求主动请求QoS变更，适合OTT应用场景（如视频通话应用请求更低的延迟） - **Network-Initiated**：运营商保持对网络资源的最终控制权，PCF可以基于运营商策略、AF请求、或计费事件强制调整QoS - **AN-Initiated**：尊重(R)AN对无线资源的自治权——当(R)AN发现无法维持某个QoS Flow的QoS要求时，可以主动通知SMF，而不需要等待核心网指示 ## 三、UE-Initiated PDU Session Modification完整信令流 这是最常见的场景。TS 23.502 Section 4.3.3.2定义了完整的UE发起修改流程。 ```mermaid sequenceDiagram participant UE participant RAN as (R)AN participant AMF participant SMF participant PCF participant UPF participant UDM Note over UE,UDM: Step 1-4: UE发起修改请求 UE->>AMF: NAS Transport
PDU Session Modification Request Note right of UE: 携带: PDU Session ID,
Procedure Transaction ID,
QoS rules (建议的),
Packet Filters AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
N1 SM container + PDU Session ID Note right of AMF: 携带: N1 SM Container,
PDU Session ID,
SUPI Note over SMF,UDM: Step 5-6: SMF策略授权（条件步骤） SMF->>UDM: Nudm_SDM_Get
获取签约数据（如需要） alt SMF已与PCF建立N7会话 SMF->>PCF: Npcf_SMPolicyControl_Update
报告UE请求 Note right of SMF: 携带: Policy Control
Request Triggers,
UE Request的QoS参数 PCF-->>SMF: 200 OK
PCC Rules + QoS决策 Note left of PCF: 携带: 新/修改/删除的
PCC Rules,
Session Rules,
Policy Control
Request Triggers end Note over SMF,UPF: Step 7: N4 Session Modification SMF->>UPF: N4 Session Modification Request Note right of SMF: 携带: FAR, QER, URR,
PDR (新/修改/删除) UPF-->>SMF: N4 Session Modification Response Note over SMF,UE: Step 8-11: 下发修改命令 SMF->>AMF: N1N2MessageTransfer
N1: PDU Session Modification Command
N2: SM Information Note right of SMF: N1: QoS Rules, QoS Flow
参数, Packet Filters
N2: QFI, QoS Profile,
Tunnel Info AMF->>RAN: N2 PDU Session Resource
Setup/Modify Request RAN->>UE: RRC Reconfiguration
DRB映射更新 Note right of RAN: QoS Flow→DRB映射 Note over UE,UPF: Step 12-16: 完成确认 UE->>RAN: RRC Reconfiguration Complete RAN-->>AMF: N2 PDU Session Resource
Setup/Modify Response Note left of RAN: 携带: AN Tunnel Info,
接受的QoS Flow列表 AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
N2 SM Info + N1 SM Container UE->>AMF: NAS Transport
PDU Session Modification Complete ACK AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
N1 SM Container (ACK) ``` ### 3.1 Step 1：UE发送PDU Session Modification Request UE通过UL NAS Transport消息封装PDU Session Modification Request。该NAS消息定义在TS 24.501 Section 8.3.14。 **关键IE解析：** | IE名称 | 描述 | 来源章节 | |--------|------|---------| | **PDU Session ID** | 标识要修改的PDU Session（1-255） | TS 24.501 §9.10.5.6 | | **Procedure Transaction Identity** | 关联请求和响应消息 | TS 24.501 §9.10.5.18 | | **5GSM Capability** | UE支持的5GSM能力（如反射QoS） | TS 24.501 §9.11.3.1 | | **QoS Rules** | UE建议的QoS规则（包含Packet Filter） | TS 24.501 §9.11.4.12 | | **Extended Protocol Configuration Options** | 附加参数（如请求类型、IP地址等） | TS 24.501 §9.11.4.2 | **QoS Rules的内部结构**（TS 24.501 Section 9.11.4.12）： ``` QoS Rule := QoS Rule Identifier (1 octet) Rule Operation Code (2 bits): 00 = Create new QoS rule 01 = Delete existing QoS rule 10 = Modify existing QoS rule 11 = Create new QoS rule and replace DQR bit (1 bit): 1 = Default QoS Rule Number of Packet Filters (6 bits) Packet Filter List: Packet Filter Identifier Packet Filter Direction (2 bits): 00 = DL, 01 = UL, 10 = Bidirectional Packet Filter Components: IPv4/IPv6 remote address + mask Protocol Number (TCP/UDP/ICMP...) Local/Remote port range Security Parameter Index (IPsec) Type of Service/Traffic Class Flow Label (IPv6) QoS Rule Precedence (1 octet) QFI (6 bits) — 关联到具体QoS Flow ``` **设计意图**：UE通过QoS Rule中的Packet Filter告诉网络"我希望哪些流量走哪个QoS Flow"。但最终是否授权，取决于PCF的策略决策。 ### 3.2 Step 2-4：AMF转发至SMF AMF收到UL NAS Transport后，通过`Nsmf_PDUSession_UpdateSMContext`服务操作将请求转发给SMF。AMF在这里是**纯转发角色**——它不解析NAS SM消息的内容，只根据PDU Session ID查找对应的SMF。 AMF发送的`Nsmf_PDUSession_UpdateSMContext Request`（定义在TS 29.502 Section 5.2.2.3.2）包含： | IE名称 | 类型 | 说明 | |--------|------|------| | **n1SmMsg** | RefToBinaryData | 包含PDU Session Modification Request的NAS容器 | | **pduSessionId** | integer | PDU Session标识 | | **supi** | Supi | 用户永久标识 | | **servingNfId** | NfInstanceId | AMF的NF Instance ID | | **anIpAddr** | string | AN的IP地址（某些场景） | ### 3.3 Step 5-6：SMF与PCF的策略交互 SMF收到UE的修改请求后，需要向PCF请求策略授权（如果N7会话已建立）。这是整个流程中**最关键的决策点**。 SMF通过`Npcf_SMPolicyControl_Update`（TS 29.512 Section 4.2.4）向PCF报告： ```json { "policyControlRequestTriggers": ["UE_REQUEST"], "uePendingPolicyUpdate": true, "qosInformation": { "5qi": 8, "maxbrUl": "100 Mbps", "maxbrDl": "200 Mbps" }, "qosMonData": { "reqQosMonParams": ["DOWNLINK"], "repFreqs": ["EVENT_TRIGGERED"] } } ``` PCF根据运营商策略和签约数据做出决策，返回： ```json { "pccRules": [{ "pccRuleId": "pcc-rule-1", "refQosData": ["qos1"], "flowInfos": [{ "flowDescription": "permit out ip from any to assigned 10.1.1.2", "packFiltId": "pf-1" }], "precedence": 100 }], "qosDecs": [{ "qosId": "qos1", "5qi": 8, "maxbrUl": "50 Mbps", "maxbrDl": "100 Mbps", "arp": {"priorityLevel": 5, "preemptCap": "NOT_PREEMPT", "preemptVuln": "NOT_PREEMPTABLE"} }], "policyCtrlReqTriggers": ["PLMN_CHANGE", "RES_MO_RE", "UE_IP_CH"] } ``` **关键博弈点**：UE请求的QoS参数（如100Mbps上行）和PCF授权的参数（如50Mbps上行）可能不同。**PCF的决策是最终决定**，SMF必须按照PCF授权的参数执行。 ### 3.4 Step 7：N4 Session Modification SMF根据PCF的PCC Rule生成N4规则，通过PFCP Session Modification Request下发给UPF。N4规则涉及四类规则的操作： ```mermaid flowchart LR subgraph PCC Rule到N4规则的映射 A[PCC Rule] --> B[PDR
Packet Detection Rule] A --> C[FAR
Forwarding Action Rule] A --> D[QER
QoS Enforcement Rule] A --> E[URR
Usage Reporting Rule] end B --> B1[Source Interface: CORE
F-TEID: N3隧道
PDI: SDF Filter] C --> C1[Action: FORWARD
Destination Interface:
ACCESS or CORE] D --> D1[QFI: 8
Gate Status: OPEN
MBR: 50Mbps UL
GBR: 10Mbps UL] E --> E1[Measurement Method:
VOLUME
Reporting Triggers] ``` | N4规则类型 | 操作 | 关键参数 | |-----------|------|---------| | **PDR（新增）** | Create | SDF Filter、F-TEID、Source Interface | | **PDR（修改）** | Update | 激活/去激活、修改SDF Filter | | **PDR（删除）** | Delete | PDR ID | | **FAR（新增/修改）** | Create/Update | Forward Action、Destination Interface、Outer Header Creation | | **QER（新增/修改）** | Create/Update | QFI、Gate Status、MBR/GBR、Packet Rate | | **URR（新增/修改）** | Create/Update | Measurement Method、Volume/Time Threshold | ### 3.5 Step 8-11：下发修改命令到UE和(R)AN SMF通过`Namf_Communication_N1N2MessageTransfer`（TS 29.518 Section 5.2.2.3.2）将修改命令同时下发给UE和(R)AN： **N1 SM Container**（给UE的PDU Session Modification Command，TS 24.501 Section 8.3.15）： | IE | 说明 | |----|------| | **5GSM Cause** | 修改结果（成功/失败/部分成功） | | **QoS Rules** | 网络授权的最终QoS规则（可能与UE请求不同） | | **QoS Flow Descriptions** | QoS Flow级别的参数（5QI、ARP、GFBR、MFBR） | | **Session-AMBR** | 更新的聚合最大比特率 | | **Extended Protocol Configuration Options** | 附加参数 | **N2 SM Information**（给(R)AN的，TS 38.413 Section 9.3.2.2）： | IE | 说明 | |----|------| | **QoS Flow Setup/Modify List** | 要添加/修改的QoS Flow列表 | | **QoS Flow Identifier (QFI)** | 每个QoS Flow的标识 | | **QoS Flow Level QoS Parameters** | 5QI、ARP、GFBR、MFBR | | **UL/DL QoS Flow Mapping Indication** | QoS Flow到DRB的映射指导 | | **S-NSSAI** | 网络切片标识 | | **CN Tunnel Info** | UPF的N3隧道端点信息 | **设计意图**：N1和N2信息通过同一条`N1N2MessageTransfer`下发，确保UE和(R)AN的配置**原子性同步**——要么同时生效，要么都不生效。 ### 3.6 Step 12-16：完成确认 (R)AN收到N2信息后，执行RRC Reconfiguration将新的QoS Flow映射到DRB。UE确认后，RAN通过N2 Response返回结果。最终UE发送PDU Session Modification Complete ACK确认。 **AN Tunnel Info**是N2 Response中的关键参数——它包含了(R)AN侧的N3隧道端点地址和TEID。如果UPF需要知道新的下行隧道信息（例如，UPF重选场景），SMF会通过N4 Session Modification更新UPF。 ## 四、Network-Initiated PDU Session Modification 网络侧发起的修改主要由PCF或SMF触发。TS 23.502 Section 4.3.3.2的Step 1a-1b描述了PCF发起的场景。 ```mermaid sequenceDiagram participant AF participant PCF participant SMF participant AMF participant RAN as (R)AN participant UE participant UPF Note over AF,UPF: PCF/SMF-Initiated PDU Session Modification alt AF触发 AF->>PCF: Npcf_PolicyAuthorization_Update
请求新的QoS资源 Note right of AF: 携带: Media Component,
Flow Description, QoS Reference end PCF->>SMF: Npcf_SMPolicyControl_UpdateNotify
策略更新通知 Note left of PCF: 携带: 新/修改/删除的
PCC Rules,
QoS Decisions SMF-->>PCF: 200 OK (N7响应)
确认接受策略 Note over SMF: SMF根据PCC Rules
生成N4规则和QoS Flow描述 SMF->>UPF: N4 Session Modification Request UPF-->>SMF: N4 Session Modification Response SMF->>AMF: Namf_Communication_N1N2MessageTransfer
N1: Modification Command
N2: SM Information AMF->>RAN: N2 PDU Session Resource Modify Request Note right of AMF: 如果UE在CM-IDLE状态:
先触发Service Request/Paging RAN->>UE: RRC Reconfiguration UE->>RAN: RRC Reconfiguration Complete RAN-->>AMF: N2 PDU Session Resource Modify Response UE->>AMF: NAS: PDU Session Modification Complete ACK AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Note over SMF: Step: 如果需要更新UPF
下行隧道信息 SMF->>UPF: N4 Session Modification
(更新DL FAR的隧道信息) ``` ### 4.1 PCF发起修改的触发条件 PCF可以在以下场景主动触发修改（TS 29.512 Section 4.2.4.2）： | 触发条件 | 典型场景 | 关键IE | |---------|---------|--------| | **AF Request** | IMS视频通话请求QoS升级 | Media Component Descriptor、Flow Description | | **签约变更** | 用户套餐升级/降级 | Subscription数据变更通知 | | **时间策略** | 按时段应用不同策略 | Validity Time | | **计费条件** | 使用量达到阈值 | Volume/Time Threshold | | **位置策略** | UE移动到特定区域 | User Location Change | ### 4.2 CM-IDLE状态下的特殊处理 当PCF/SMF触发修改时，UE可能处于CM-IDLE状态（没有NAS信令连接）。这种情况下： 1. SMF通过`N1N2MessageTransfer`将消息发给AMF 2. **AMF发现UE处于CM-IDLE**，触发Paging流程 3. UE响应寻呼，执行Service Request建立信令连接 4. AMF再下发PDU Session Modification Command 这是PDU Session Modification和Service Request流程的**交织点**——两个流程必须正确衔接。 ### 4.3 Policy Control Request Triggers SMF可以在初始策略建立时订阅一系列事件触发器（TS 29.512 Section 6.1.6.3.10），当这些触发条件满足时，SMF会主动向PCF报告并请求策略更新： | Trigger | 说明 | 方向 | |---------|------|------| | **PLMN_CHANGE** | UE漫游到不同PLMN | SMF→PCF | | **RES_MO_RE** | 资源修改请求（UE发起） | SMF→PCF | | **AC_TY_CH** | 接入类型变更 | SMF→PCF | | **UE_IP_CH** | UE IP地址变更 | SMF→PCF | | **AN_CH_INFO** | 接入网信息变更 | SMF→PCF | | **US_RE** | 使用量报告 | SMF→PCF | ## 五、AN-Initiated PDU Session Modification 这是最特殊的触发源——由(R)AN主动发起，定义在TS 23.502 Section 4.3.3.3。 ```mermaid sequenceDiagram participant RAN as (R)AN participant AMF participant SMF participant PCF participant UPF Note over RAN,UPF: AN-Initiated PDU Session Modification
(TS 23.502 §4.3.3.3) Note over RAN: 触发条件:
1. QoS Flow失败通知
2. AN资源释放
3. GBR QoS Flow通知 RAN->>AMF: N2 PDU Session Resource
Modify Indication
或 N2 Resource Release Note right of RAN: 携带: PDU Session ID,
QoS Flow List,
Cause Value AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
N2 SM Information Note over SMF: SMF处理但不向PCF
发送策略更新 SMF->>UPF: N4 Session Modification
(可选，取决于场景) UPF-->>SMF: N4 Response SMF->>AMF: Nsmf_PDUSession_UpdateSMContext Response
N2 SM Information (ACK) AMF->>RAN: N2 PDU Session Resource
Modify Acknowledge ``` **AN-Initiated的特殊性**： 1. **没有N1 NAS消息**——AN发起的修改不涉及UE的NAS信令 2. **不触发PCF策略更新**——SMF不会因为AN的资源释放而重新向PCF请求策略 3. **Indication vs Request**——AN使用N2 Indication（而非Request），表明这是一个**通知**而非请求 4. **SMF可以决定后续动作**——如果AN释放了某个GBR QoS Flow的资源，SMF可能选择暂时保留QoS Flow（等UE回到更好覆盖区域后再恢复），也可能选择删除该QoS Flow ## 六、QoS Flow生命周期状态机 一个QoS Flow在PDU Session内的生命周期如下： ```mermaid stateDiagram-v2 [*] --> NotExist: PDU Session建立时
创建Default QoS Flow NotExist --> Active: PDU Session Modification
(Add QoS Flow) Active --> Modified: PDU Session Modification
(Modify QoS参数) Modified --> Active: 修改完成 Active --> Inactive: AN资源释放
(AN-Initiated) Inactive --> Active: 网络侧重新激活
(PCF/SMF-Initiated) Active --> NotExist: PDU Session Modification
(Remove QoS Flow) Modified --> NotExist: 删除 Inactive --> NotExist: SMF决定永久释放 state Active { [*] --> GBR_Flow: 5QI=1-79 [*] --> NonGBR_Flow: 5QI=80-255 GBR_Flow: 维持GFBR/MFBR NonGBR_Flow: Best Effort } ``` **关键状态说明**： - **Active**：QoS Flow已在UE、(R)AN、UPF三端都配置完成，用户面正常工作 - **Inactive**：QoS Flow在SMF/UPF侧保留，但(R)AN侧资源已释放。这种状态在AN-Initiated释放后出现 - **Modified**：临时状态，表示正在修改QoS参数 **与4G EPS Bearer的核心区别**：在4G中，Dedicated Bearer的去激活意味着整个Bearer被删除。但在5G中，QoS Flow可以进入Inactive状态而不被删除——这为**快速恢复**提供了可能。 ## 七、PDU Session Modification中的QoS Flow操作矩阵 | 操作 | UE-Initiated | PCF-Initiated | AN-Initiated | NAS消息 | N2消息 | N4消息 | |------|-------------|--------------|-------------|---------|--------|--------| | **添加QoS Flow** | 支持 | 支持 | 不支持 | Modification Command含新QoS Rule | QoS Flow Setup List | Create PDR/FAR/QER | | **修改QoS Flow参数** | 支持 | 支持 | 有限支持 | Modification Command含修改的QoS Flow Description | QoS Flow Modify List | Update QER | | **删除QoS Flow** | 支持（删除Packet Filter） | 支持 | 支持（资源释放） | Modification Command移除QoS Rule | QoS Flow Release List | Delete PDR/FAR/QER | | **修改Session AMBR** | 不支持（仅网络） | 支持 | 不支持 | Modification Command含Session-AMBR | 不涉及特定QoS Flow | Update QER | | **修改用户面隧道** | 间接（SSC模式2/3） | 间接 | 不涉及 | 可能涉及 | N2 Tunnel Info Update | Update FAR DL | ## 八、实战：抓包识别与故障排查 ### 8.1 Wireshark过滤规则 ``` # 捕获NAS PDU Session Modification nas-5gs.message_type == 0xC1 || nas-5gs.message_type == 0xC2 || nas-5gs.message_type == 0xC3 # PDU Session Modification Request = 0xC1 (193) # PDU Session Modification Command = 0xC2 (194) # PDU Session Modification Complete = 0xC3 (195) # 捕获N4 PFCP Session Modification pfcp.message_type == 52 # PFCP Session Modification Request pfcp.message_type == 53 # PFCP Session Modification Response # 捕获N7 Policy Update http2.header.value contains "npcf-smpolicycontrol" && http2.header.value contains "update" ``` ### 8.2 常见故障点 | 故障现象 | 可能原因 | 排查思路 | |---------|---------|---------| | **Modification Request被拒绝（5GSM Cause #43**） | PCF不授权请求的QoS | 检查N7接口的PCC Rule，确认签约数据是否支持请求的5QI/MBR | | **QoS Flow添加后无数据** | N4 PDR/FAR配置错误 | 在UPF侧检查PDR匹配规则是否正确，FAR的转发目标是否正确 | | **RRC Reconfiguration失败** | (R)AN无足够无线资源 | 检查N2 Response中是否有Rejected QoS Flow，查看AN侧资源状态 | | **Modification Command不下发** | UE处于CM-IDLE且Paging失败 | 检查AMF是否发送Paging，UE是否响应 | | **N4 Modification超时** | UPF处理能力不足 | 检查UPF的PFCP Session数量，是否有过载告警 | | **5GSM Cause #50** | PDU Session不存在 | 检查PDU Session ID是否正确，Session是否已被隐式去激活 | ## 九、与4G EPS Dedicated Bearer流程的对比 | 维度 | 4G Dedicated Bearer | 5G PDU Session Modification | |------|-------------------|-----------------------------| | **QoS粒度** | Bearer级别（TFT+QCI） | QoS Flow级别（Packet Filter+5QI） | | **默认承载** | Default Bearer始终存在 | Default QoS Flow始终存在 | | **专用承载建立** | 独立的Dedicated Bearer Establishment流程 | 嵌入PDU Session Modification流程 | | **RAN映射** | Bearer=DRB（一一映射） | QoS Flow→DRB（多对一映射，RAN自主决定） | | **PCF交互** | 通过Gx接口（Diameter） | 通过N7接口（SBI/HTTP） | | **UP规则下发** | 通过Gx→PCRF→PGW→SGW | 通过N7→SMF→UPF（PFCP） | | **协议栈** | Diameter + GTPv2 + PFCP | HTTP/2 + PFCP | **核心差异**：4G中每个Dedicated Bearer的建立都是独立流程，而5G中所有QoS Flow操作都统一在PDU Session Modification这一个流程中完成。这大大简化了信令交互——一次Modification可以同时添加多个QoS Flow、修改多个QoS Flow、删除多个QoS Flow。 ## 十、常见问题 **Q1: UE-Initiated和Network-Initiated的Modification可以同时进行吗？** A: 不可以。如果SMF正在处理一个Network-Initiated的Modification，又收到UE发起的Modification Request，SMF会通过5GSM Cause #39（Message not compatible with the protocol state）拒绝UE的请求。UE需要等待当前修改完成后重试。这是TS 24.501 Section 6.4.3定义的状态机行为——5GSM实体在PDU-SM-MODIFY-PENDING状态下不接受新的修改请求。 **Q2: Default QoS Flow可以被删除吗？** A: 不可以。Default QoS Flow是PDU Session的"骨架"，在PDU Session生命周期内始终存在。它的参数可以被修改（如5QI从9改为8），但QoS Flow本身不能被删除。如果Default QoS Flow的资源被释放，整个PDU Session将被去激活。这与4G中Default Bearer不能被单独去激活的逻辑一致。 **Q3: AN-Initiated修改为什么不需要PCF授权？** A: 因为AN-Initiated修改通常是由无线资源不足触发的——(R)AN无法维持某个GBR QoS Flow的QoS保证。这是一个**事实**而非**决策**：PCF的策略已经无法改变无线信道的物理约束。SMF可以选择保留该QoS Flow（等待无线条件恢复后重新激活），但不会要求PCF重新评估策略。不过，如果AN的资源释放导致Session AMBR等策略参数受到影响，SMF可能异步向PCF报告。 **Q4: Reflective QoS（反射QoS）与PDU Session Modification的关系是什么？** A: Reflective QoS（TS 23.501 Section 5.7.4）允许UE从下行数据包中推导上行QoS规则，而无需通过PDU Session Modification显式下发QoS Rule。UPF在下行数据包中标记QFI和RQI（Reflective QoS Indicator），UE收到后自动在本地生成对应的UL QoS Rule。这减少了信令开销，但初始的下行QoS Flow配置仍然需要通过PDU Session Modification完成。 **Q5: PDU Session Modification中的Partial Success是什么？** A: 当SMF请求同时添加多个QoS Flow，但(R)AN只能满足其中部分QoS Flow的资源要求时，(R)AN会在N2 Response中分别列出Accepted和Rejected的QoS Flow。SMF根据这个结果更新UPF的N4规则（只为被接受的QoS Flow创建规则），并在PDU Session Modification Command中告知UE哪些QoS Rule生效。这是5G相比4G的一个重要改进——4G的Dedicated Bearer建立失败会导致整个流程失败。 ## 参考来源 1. [3GPP TS 23.502 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — Section 4.3.3 PDU Session Modification procedures 2. [3GPP TS 24.501](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3178) — NAS Signalling for Session Management (Section 6.4.3, 8.3.14, 8.3.15) 3. [3GPP TS 29.512](https://itecspec.com/3gpp/29.512/s/4.2.4) — Npcf_SMPolicyControl Update Service Operation (Section 4.2.4) 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) — Wireshark抓包分析与SBI交互详解 5. [Session Modification — free5GC SMF DeepWiki](https://deepwiki.com/free5gc/smf/3.2-session-modification) — 开源5GC实现中的Session Modification代码分析 --- > 本文由「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 等场景全覆盖。